Introduction

In DeepSeek Harness code mode, the model writes TypeScript programs to orchestrate tool calls. These programs receive the parameters and results of all sub-calls, while the model itself can only see the content ultimately returned by the program. Although the Session Log records all data, there is an observational gap among these three: the model cannot perceive the tool calls triggered by its internal program.

The dsh-code-lens plugin is specifically designed to fill this gap. It provides two capabilities: first, generating a full-session projection view through codeLens, and second, providing the code_lens tool for the model to audit its own program after the fact.

Plugin Positioning

  • Name: dsh-code-lens
  • Maintainer: lisycotana
  • Category: Workflow
  • License: MIT
  • Core Value: Observing sub-calls that are triggered by run_code programs in DeepSeek Harness code mode and are invisible to the model.

Core Features

1. codeLens Session Projection

The plugin provides session-level aggregate data at the UI layer. The view displays statistics for the entire session, without requiring direct manipulation of log files.

{ "programs": 1, "dispatches": 2, "settled": 2, "errors": 1, "dispatchMs": 340, "hiddenBytes": 1027 }

In this JSON, hiddenBytes represents the number of payload bytes that were consumed by the program but never exposed in the model context.

2. code_lens Tool

This is an audit tool that allows viewing internal call details of a program after the session ends.

run_code call_abc: 2 sub-calls, 1 errors, 340ms, 1027B hidden from context
  call_abc:code:1  bash  ok     140ms  3B
  call_abc:code:2  read  error  190ms  1024B

Installation and Enablement

Install it through the official plugin catalog:

dsh plugin --profile web add dsh-code-lens

After installation, start the Harness with the specified profile:

dsh --profile web

Typical Usage

Session Projection Example

After a code-mode session ends, review the codeLens view in the UI. If the session contains a run_code program that read 8 files, the output may look like this:

{ "programs": 1, "dispatches": 9, "settled": 8, "errors": 0, "dispatchMs": 23, "hiddenBytes": 1312 }

Tool Audit Example

By invoking the code_lens tool during the session (or reviewing the logs), you can see the specific sub-call details:

run_code call_00_lMDLou1XAHEXiQYgKbUR9330: 9 sub-calls, 0 errors, 23ms, 1312B hidden from context
  call_00_lMDLou1XAHEXiQYgKbUR9330:code:1  read  ok  6ms  164B
  ...
  call_00_lMDLou1XAHEXiQYgKbUR9330:code:9  code_lens  unsettled  —  0B

Note the unsettled status on the last line. This is a normal observation for a sub-call that has not yet settled.

Technical Design and Considerations

Dependencies and Runtime Behavior

  • Zero Dependencies: The plugin does not depend on any external libraries. It uses hand-written validators instead of libraries such as zod, ensuring version decoupling from the host environment.
  • Read-Only, No Writes: The plugin listens to session/event, but it runs within the event publishing window and does not attempt to append data, preventing reentrancy errors.
  • Optional Registries: sessionProjections and tools are obtained via ctx.inject, so the plugin can still be loaded in Headless mode without a UI.

Data Logic

  • Missing Sub-Call Numbers: If a sub-call is queued but ultimately does not settle, neither a start event nor an end event is emitted in the log. Therefore, non-contiguous numbering (for example, gaps) is normal and does not indicate missing data.
  • Pairing Rules: Sub-calls are paired by subCallId. Duration values are sourced from the time field in the event envelope, not from a duration field carried by the event itself.

Notes for Plugin Authors

When registering a tool, ctx.tools.register() expects a Wire Schema (a complete JSON Schema object). If a shorthand object (the argument of defineTool) is passed directly to register(), it results in type: null and is rejected:

INVALID_REQUEST: Invalid schema for function 'x':
schema must be a JSON Schema of 'type: "object"', got 'type: null'.

This plugin explicitly defines the object root structure and validates parameters by itself to maintain zero external dependencies.

Use Cases

This plugin is suitable for developers using DeepSeek Harness in code mode who need to:
1. Monitor tool calls triggered inside programs written by the model.
2. Analyze data that is “hidden” from the model context (hiddenBytes).
3. Audit sub-call chains within a session in a headless, no-UI environment.

Conclusion

dsh-code-lens is a supplemental observability tool in the DSH ecosystem for code mode. Through projection views and the code_lens tool, it reconstructs execution details that are outside the model’s perspective.