dsh-code-lens

Observability for DeepSeek Harness code-mode sub-dispatches — the tool calls a run_code program makes that the model never sees.

The gap this fills

In code mode the model writes a TypeScript program that orchestrates tool calls. The program receives every result in full. The model receives none of them — only whatever the program finally returns. Both dispatch boundaries are still recorded on the session log.

That produces a three-way split with no equivalent outside code mode:

	program	model	session log
sub-call arguments	✅	❌	✅
sub-call results	✅	❌	✅

dsh is the only harness that draws this distinction, because it is the only one where a tool call can happen inside a program the model wrote. The data is recorded and nothing surfaces it. This plugin does.

What it gives you

A codeLens session projection — whole-session totals, readable from the UI without touching the log:

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

hiddenBytes is the payload the program consumed and the log preserved while the model saw none of it.

A code_lens tool — lets the model audit its own program after the fact:

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

Install

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

Development, without packaging — note the file:// URL (a bare G:/... path is parsed as a URL scheme on Windows):

# scratch/cordis.yml
- insert:
    - id: code-lens
      name: 'file:///G:/dsh-plugins/dsh-code-lens/index.js'

dsh --profile web --patch ./scratch/cordis.yml

Design notes

• Zero dependencies. The projection registry's runtime contract is structural — it calls schema.parse(value) and nothing else — so the view validator is hand-written rather than pinning a zod copy that could drift from the host's.