Bash execution failed from duplicate dsh-tools module instances

[jiridanek]

Summary

The Web runtime failed during bash execution with:

Cannot read properties of undefined (reading prepare)

Root cause

agent-loop and the profile-loaded ToolRuntime resolved @deepseek-ai/dsh-tools through different module URLs in the same Node process. Each module instance created its own TOOL_RUNTIME_SCHEDULER symbol with Symbol(...). The symbols had the same description but different identity, so ctx.tools[TOOL_RUNTIME_SCHEDULER] returned undefined.

Printf diagnostics showed a real ToolRuntime containing Symbol(@deepseek-ai/dsh-tools.scheduler), while the lookup from agent-loop still failed.

Fix

The scheduler key now uses:

Symbol.for("@deepseek-ai/dsh-tools.scheduler")

This preserves symbol identity across duplicate module instances. The temporary diagnostics were removed.

Validation

• Bash integration tests: 4 passed
• Host library build: passed
• Live Web bash execution: passed

This is a runtime module-resolution duplication issue, not a pnpm version duplication issue.

[argszero]

Your diagnosis and your patch are both correct. Three things I can add: the four reports in this cluster are one mechanism, the root cause is a single default flip that was already partially reverted, and Symbol.for is sufficient — but for a reason that is worth checking rather than assuming.

1. This is one mechanism across four reports

	report	environment
#7106	BluzeOcean	fresh tree + fresh ~/.dsh/ + new key
#7107	gerry47231905	Linux x64, official profile, no third-party plugins
#7108	mcus890	Windows 11, Node 22.20 (plus a "same on mac" confirmation)
#7117	this one	Web runtime

Identical signature in all four: the first tool call fails with Cannot read properties of undefined (reading 'prepare'), and — the part that makes it unmistakable — no tool/result event is recorded, so every later request in that session then fails with DeepSeek Messages tool calls need immediate results (INVALID_REQUEST). 0.1.5-rc.2 is unaffected. Reproducible with zero third-party plugins, so no plugin inventory is involved.

2. Root cause: one line, and its desktop half was already reverted

apps/cli/src/profile-boot.ts:263 at HEAD:

const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'

9ddef327a4 ("feat: resolution mode link to runtime", 2026-09-17 20:08, contained only in tag dsh-v0.1.6-alpha.2) changed that ?? 'link' into ?? 'runtime'. A source launch (pnpm dsh web = node --import tsx/esm apps/cli/src/bin.ts) therefore boots its profile rows through the runtime resolution generation.

The same commit also flipped a second carrier, and that half was undone 39 minutes later by the same author:

d9a55c7c0d  "fix: revert desktop"   apps/desktop-host/src/index.ts:21
-    resolutionMode: 'runtime',
+    resolutionMode: process.argv[5] === 'runtime' ? 'runtime' : 'link',

Both commits are in dsh-v0.1.6-alpha.2. So at HEAD the desktop carrier defaults to link again, while the CLI carrier — the one every report here uses — is still flipped. That revert is the strongest available evidence that the default was recognised as wrong; the CLI half is simply the part that was left standing.

3. Why the flip splits module identity

profile-boot.ts:312 registers PluginPackages with { generation, behavior: 'enforce' } for every mode other than link, so Loader-mounted profile rows resolve @deepseek-ai/dsh-tools through the generation. Meanwhile agent-loop's static import of the same package was linked natively, before the client-side ESM bootstrap ran. The design note (.agents/notes/implemented/architecture/2026-09-09-profile-resolution-generations.md) states the constraint in its own words: "The ESM bootstrap cannot affect static dependencies linked before its execution."

Two URLs ⇒ two module instances. The crash site is packages/core/agent-loop/src/tool-calls.ts:

:170   const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)
:153   ... ctx.tools[TOOL_RUNTIME_SCHEDULER].finalize(slot.exec, slot.result)
:154   ... ctx.tools[TOOL_RUNTIME_SCHEDULER].finish(slot.exec, slot.result)

TOOL_RUNTIME_SCHEDULER is packages/core/tools/src/index.ts:463, Symbol('@deepseek-ai/dsh-tools.scheduler') — evaluated once per module instance. The key held by agent-loop's copy does not exist on the ToolRuntime published by the other, so the property read is undefined and .prepare throws before any tool body runs. That is exactly why no tool/result is logged.

4. Your patch is sufficient — and here is why that is a finding, not a guess

Symbol.for only makes the key equal. If this package kept module-scope state, the second instance would still read its own empty copy and the bug would only be half-fixed. It does not:

• TOOL_RUNTIME_SCHEDULER is the only module-level exported value in the package whose identity matters. The others are string literals compared by value (TOOL_ABORTED :466, TOOL_ABORTED_BEFORE_DISPATCH :469, RUN_CODE_NAME in ptc.ts:23).
• The only module-level collections are three immutable constants (json-schema.ts:76 CONSTRAINT_KEYWORDS, :86 ANNOTATION_KEYWORDS, py-types.ts:121 RESERVED) — never mutated. There is no module-level let, no module-scope Map/WeakMap, and no cache.
• All runtime state is instance-held: index.ts:806-812 (deferredContexts, concludingExecutions, cancellationStates, contentFinalizers) and :1793 (canonicalResults), and the scheduler cell is readonly [TOOL_RUNTIME_SCHEDULER] = { prepare: exec => this.prepareScheduledExecution(exec), … } — an arrow closure bound to this. Sharing the key therefore lands on the same instance and the same state.
• The one other symbol, createExecutionToken()'s Symbol('dsh.tool.execution') (:1876), is a same-process correlation token used only inside the package and never crosses the boundary.

I verified the two halves independently: a two-file micro-repro with the same-description Symbol() reproduces the undefined cross-plane lookup and the throw, and the same repro with Symbol.for resolves. export const B: unique symbol = Symbol.for('x') also typechecks under tsc --strict, so the annotation needs no change.

5. What the symbol fix does not restore

It removes the symptom without restoring the invariant the note states — "Restart preserves one package identity per process" (its Alternatives section: "A resolution-table swap cannot invalidate every live module instance or object reference"). Two instances remain, so once the two planes hold different versions the failure mode changes from a loud crash to a silent mismatch. That is reachable here: #7108's repro builds lib/ first, so a source-plane versus built-plane pairing is exactly the shape to worry about.

Which argues for treating the default (or the isolation-healing path that link mode used to run) as the primary fix, with Symbol.for as defence in depth rather than the whole answer. Both are worth having — they fail differently and neither subsumes the other.

[innovationpuls-creator]

Worth adding since not everyone can patch: you don't need a fix to get tool calls working on the shipped 0.1.6-alpha.2. Run the built entry point instead of the tsx one, node apps/cli/lib/bin.js web, and they work.

Same machine, ESM resolve hook on both launches: under pnpm dsh web, @deepseek-ai/dsh-tools resolves to lib/index.js once and to src/index.ts the rest of the time; under lib/bin.js, all nine resolutions land on lib/index.js and src/index.ts never appears. tool/call and tool/result pair up there.

补一句：不是所有人都能改代码打补丁，而在原样的 0.1.6-alpha.2 上不一定要打补丁才能让工具调用跑起来。换成构建产物入口 node apps/cli/lib/bin.js web 就行。

同一台机器上用 ESM resolve 钩子看两种启动：pnpm dsh web 下 dsh-tools 有一次解析到 lib/index.js、其余到 src/index.ts；lib/bin.js 下九次全落在 lib/index.js，src/index.ts 一次都没出现。这个入口下 tool/call 和 tool/result 成对。