Plugin-origin tool calls hang indefinitely while built-in tools work

[PensiveFei]

Environment

• DSH: @deepseek-ai/dsh@0.1.0-rc.7 (installed via npx), Node v24.19.0
• OS: Windows
• Plugin: dsh-secure-audit (reproduced on v0.1.0 and v0.2.2)

Steps to reproduce

From a run_code program, call any plugin-registered tool, e.g.:

await tools.security_scan_text({ text: "hello", maskText: true });
await tools.security_redact_text({ text: "hello" });
await tools.security_redact_json({ json: "{\"a\":1}" });

Expected

The call settles within the tool declared timeoutMs (8000 ms) - either a result or a timeout error, like every built-in tool.

Actual

The call never settles. The run_code execution is interrupted with no result recorded. This happens for every plugin-origin tool, on both plugin versions, while all built-in tools (pwsh, read, write, edit, glob, grep, web_search, skill) work normally in the same session.

Observations

• The plugin defineTool declares timeoutMs 8000, and its execute is fast by design (rule-scan budget 100 ms; 96/96 local tests pass; execution returns in milliseconds when run directly against the plugin modules).
• The harness never surfaces a timeout error either - so the timeout does not appear to be enforced on the plugin-tool bridge.
• Related contract issue (now fixed in the plugin): a runtime skill registered as { name, description, content } made the skill loader throw "loaded skill security-review source must be a string" because the loader requires a source field. Adding source fixed skill loading, but plugin tool execution still hangs - suggesting the plugin to host bridge itself, not the plugin logic.

Additional check

Diffed the published npm tarballs: dsh-tools, dsh-code-runtime-worker-thread, dsh-skill, dsh-session, dsh-web-app lib code is unchanged or only unrelated changes between 0.1.0-rc.7 and 0.1.1-rc.2, so this is still present in the latest published version. Happy to provide more detail or run diagnostics.

[Jstn-1g]

I reproduced the hang against current master (b150a551b8d465e31e418e1b2eaf5e79bbb7d28e) and published a source-pinned core fix:

• Branch: https://github.com/Jstn-1g/deepseek-harness/tree/reference/discussion-4551-renderer-content-validation
• Exact commit: Jstn-1g@3d4bd7c

Root cause: output.render is only JSON-snapshotted today. A JSON-lossless string passes that boundary, then Code Mode calls array methods during commit and throws before the binding is settled.

The patch validates the merge-extensible minimum at the renderer boundary: an array of plain JSON records with string type tags. Invalid output becomes the existing ToolOutputError / INVALID_TOOL_OUTPUT failure class before Code Mode commit. The Code Mode regression proves the binding rejects promptly and emits the paired dispatch start/settle events rather than hanging.

Verification:

• focused tools + Code Mode tests: 231 passed
• root and package typechecks/build: passed
• lint: passed
• documentation gates: 28/28
• duplication scan: zero clones
• pre-commit and pre-push hooks: passed

Deliberate scope: this does not close the block vocabulary or validate tag-specific payload fields; it only enforces the minimum container/shape contract needed to keep the execution bridge live.

[PensiveFei]

Thanks for reproducing this on master and shipping a source-pinned fix — that's exactly the kind of analysis that makes a vague "it hangs" report actionable.

I confirmed the root cause on the plugin side: all four output.render implementations in dsh-secure-audit return a string (lines.join('\n')) instead of the ContentBlock[] the contract requires. So the hang is my plugin's fault, and your renderer-boundary validation is the right hardening — a wrong render shape should surface as INVALID_TOOL_OUTPUT at the same boundary where a throwing render already does, instead of escaping into the Code Mode commit path. I'll be tracking reference/discussion-4551-renderer-content-validation once it lands upstream.

One note that may interest you: my plugin's own smoke test asserted typeof rendered === 'string', which is why 96/96 tests passed while real sessions hung. The test itself had pinned the buggy shape. I'll fix both sides (renderers + test) and verify against the rc.7 environment from the original report before releasing a patch.

Thanks again for the quick turnaround.

[tancheng33]

Independent confirmation of @Jstn-1g's root cause, plus a check you can run today without waiting for a core fix.

Where the shape is lost

Reading packages/core/tools/src/index.ts (I have the 0.1.0-rc.5 line checked out locally, and the mechanism matches what @Jstn-1g describes on master), createSuccessResult does this:

const detached = snapshotToolValue(tool.name, candidate)
const violations = validateJsonSchemaValue(tool.output.schema, detached, 'value')
if (violations.length > 0) throw new ToolOutputError(tool.name, violations)   // value IS schema-validated
const value = deepFreeze(detached)

let rendered: ContentBlock[]
try {
  rendered = tool.output.render(exec.arguments, value)
} catch (error: unknown) {
  throw projectionError(tool.name, 'render', error)                   // a THROWING render settles cleanly
}
const content = snapshotProjection(tool.name, 'render', rendered)     // <-- only checks lossless JSON

snapshotProjection calls snapshotJsonValue and fails only when the result is not lossless JSON. ContentBlock[] is a TypeScript type and nothing else — there is no runtime shape check anywhere on this path. So a render that returns a bare string, or an object, or an array of records without a string type, sails straight through, and content ends up holding something that is not a content-block array. The throw happens later, in a consumer that assumes an array, outside the try that would have turned it into INVALID_TOOL_OUTPUT.

That explains each of your observations:

• built-in tools work — they all return proper block arrays
• every plugin tool hangs — one wrong render shape in your plugin affects all of them
• no timeout is surfaced — your execute already resolved; the failure is downstream of it, during result construction, so it is not the tool timing out
• fast execute, still hangs — consistent with the above; execution time was never the issue

The check

Look at what output.render returns for your three tools. It must be an array of plain JSON records each carrying a string type:

// hangs — JSON-lossless, wrong shape, passes snapshotProjection
render: (_args, value) => value.summary

// also hangs
render: (_args, value) => ({ type: 'text', text: value.summary })

// correct
render: (_args, value) => [{ type: 'text', text: value.summary }]

Returning the string directly is the easy mistake to make, because output.schema validation passes (that gate is on value, not on the render result) and TypeScript only complains if the declaration is actually typed.

For a working reference, self_reflect in dsh-yogacara renders as:

output: {
  schema: { /* ... */ },
  render: (_args, value) => [{
    type: 'text',
    text: value.lines.length === 0 ? 'You look, and nothing much is stirring.' : value.lines.join('\\n'),
  }],
}

Four plugin-registered tools, called from Code Mode, no hang.

On the core fix

Validating the container shape at the renderer boundary is the right call — a wrong render should fail as INVALID_TOOL_OUTPUT at the same boundary where a throwing render already does, rather than escaping into a consumer. Worth noting the asymmetry as motivation: today a render that throws is handled cleanly and a render that returns garbage is not, which is the wrong way round for the failure that is easier to write by accident.

[PensiveFei]

Thanks for the independent confirmation and for spelling out the exact mechanism — the createSuccessResult walkthrough (schema-validated value, lossless-only snapshotProjection, throw escaping the try) matched what I found in the published package, and your "check you can run today" pointed me straight at it.

It was a direct hit: all four output.render implementations in dsh-secure-audit return lines.join('\n') — a bare string, the exact "JSON-lossless, wrong shape" case from your example. Built-in tools work because they return proper block arrays; every plugin tool hung for the same reason.

One thing your framework helped me notice: the plugin's own smoke test asserts assert.equal(typeof rendered, 'string') (tests/index.smoke.test.js:108), so the 96 tests were green while the renderer was feeding the wrong shape to the bridge the whole time. I'll fix the renderers to return [{ type: 'text', text: ... }], correct the test to assert the array-of-typed-blocks contract, and verify against rc.7 before cutting a patch release.

Also agreed on your asymmetry point — a throwing render settling cleanly while a garbage-shaped one hangs is the wrong way round, and @Jstn-1g's boundary validation addresses exactly that. Thanks again for the thorough write-up.