Tools fail to execute on a source build of dsh 0.1.6-alpha.2 (Cannot read properties of undefined (reading 'prepare')), and switching versions without a clean rebuild breaks the typert/tool layer

[fatihtoprakk]

Environment

• dsh: 0.1.6-alpha.2 (tag dsh-v0.1.6-alpha.2, commit ddefc45fbc); control: 0.1.5-rc.2 (tag dsh-v0.1.5-rc.2, commit fb2c4b9e69)
• Node v26.8.2 (also seen v25.9.0), pnpm 11.7.0
• macOS arm64 (darwin)
• Launch: from a source checkout — pnpm install && pnpm run clean && pnpm run build, then
  pnpm dsh --profile headless "..." / pnpm dsh web
• Provider: opencode-go / opencode-go-extra via @deepseek-ai/dsh-llm-pi-ai (also reproduces with the default profile model)

Summary

Two distinct problems present as "tools don't work":

1. 0.1.6-alpha.2 tool execution fails even on a clean build. The model emits a tool_call, then the run dies with
   Cannot read properties of undefined (reading 'prepare'). 0.1.5-rc.2 with the same setup works.
2. Switching versions without a clean rebuild leaves mismatched generated artifacts and breaks plugin/tool loading with
   typert-loader errors.

Problem 1 — 0.1.6-alpha.2 tool execution

Steps

git checkout dsh-v0.1.6-alpha.2
pnpm install
pnpm run clean
pnpm run build
node --import tsx/esm apps/cli/src/bin.ts --profile headless --json "Use the bash tool to run exactly: echo dbg-ok"

Actual

{"type":"tool_call","callId":"chatcmpl-tool-...","tool":"bash","input":{"command":"echo dbg-ok",...}}
{"type":"status","phase":"step_end","turn":1,"step":1,"usage":{...}}
{"type":"status","phase":"turn_end","turn":1,"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}
{"type":"final","text":""}

stderr: dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')

Expected

The bash tool executes and its result returns to the model.

Notes

• The tool definition reaches the model (it appears in the request tools array and the model calls it), so registration/schema assembly works; the failure is at dispatch/prepare time.
• Relevant path: packages/core/agent-loop/src/tool-calls.ts, startCall() → ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec). ctx.tools[TOOL_RUNTIME_SCHEDULER] appears to be undefined, i.e. the ToolRuntime scheduler symbol face is not reachable on the service instance.
• TOOL_RUNTIME_SCHEDULER is a unique symbol defined in @deepseek-ai/dsh-tools. I verified that resolution from the repo root, packages/core/agent-loop/lib, apps/cli/src, and ~/.dsh/profiles/web all point to the same packages/core/tools/lib/index.js, so this does not look like a duplicated-module symbol mismatch in this tree.
• The area saw recent refactors (refactor(ptc): align runtime packages and services with PTC naming, code-runtime work), so this may be a scheduler-wiring regression.

Control (works)

git checkout dsh-v0.1.5-rc.2
pnpm run clean && pnpm run build
# same headless command → prints "restored-tool-ok", exit 0

Problem 2 — stale generated artifacts across version switches

Switching from a built 0.1.6-alpha.2 tree to 0.1.5-rc.2 source without pnpm run clean && pnpm run build makes boot fail:

typert-loader: @deepseek-ai/dsh-llm invocation "@deepseek-ai/dsh-llm#llm/discoverModels" parameter codec is not backed by a zod v4 schema
...
typert-loader: 5 typert contributor(s) failed to register

The generated lib/typert.*.js manifests carry the older { mode, typeSymbol, create } codec, while the checked-out loader requires { mode, typeSymbol, schema } (zod v4). A clean rebuild regenerates them consistently (schema: for 0.1.5-rc.2, create: for 0.1.6-alpha.2).

Workaround

• Run a clean rebuild after every checkout/update: pnpm run clean && pnpm install && pnpm run build.
• Do not switch versions while a server is running — stop it first, otherwise you get EADDRINUSE on 127.0.0.1:3080 and lib/ deleted under a live process.
• Until the 0.1.6-alpha.2 issue is fixed, run dsh-v0.1.5-rc.2.

Questions

• Is the 0.1.6-alpha.2 prepare failure a known regression? Is a fix in progress, or is there a wiring/ctx.get('tools') workaround?
• Should source-launch docs require a clean rebuild after version changes, or is there a supported way to avoid stale lib/ artifacts?

[RupertCui]

我也是同样的问题，整个都重装了都没用

[fatihtoprakk]

@RupertCui Thanks for confirming — appreciate the report!

Just to check, are you also hitting Cannot read properties of undefined (reading 'prepare') on dsh-v0.1.6-alpha.2 after a source build?

A plain reinstall (pnpm install) alone won't fix it — this version requires a clean rebuild to regenerate the artifacts:

git checkout dsh-v0.1.6-alpha.2
pnpm run clean
pnpm install
pnpm run build
node --import tsx/esm apps/cli/src/bin.ts --profile headless --json "Use the bash tool to run exactly: echo dbg-ok"
If it still reproduces after that, could you share:
1. node -v / pnpm -v / git rev-parse HEAD
2. The full log around the tool_call -> prepare error
3. How you launched it — pnpm dsh or pnpm dsh web?
As a temporary workaround, switching back to dsh-v0.1.5-rc.2 with the same pnpm run clean && pnpm run build works fine for tool execution — I've documented both issues in the main post and this looks like a regression in 0.1.6-alpha.2.
Let me know if the clean rebuild still fails on your side — that would confirm we're seeing the same root cause and help narrow it down.

[kristhianmanue1]

Root cause found + one-line fix.

Under the source launch, @deepseek-ai/dsh-tools loads through two module planes: the agent-loop resolves TOOL_RUNTIME_SCHEDULER via tsconfig paths into src, while the mounted ToolRuntime plugin comes from lib. Each plane evaluates Symbol('@deepseek-ai/dsh-tools.scheduler') once, so the two importers hold two distinct identities. The loop indexes the service with its own symbol, misses the scheduler face keyed by the other, and reads undefined — hence Cannot read properties of undefined (reading 'prepare') on every tool_call.

Verified on ddefc45fbc: import(src).TOOL_RUNTIME_SCHEDULER === import(lib).TOOL_RUNTIME_SCHEDULER → false. Changing it to Symbol.for('@deepseek-ai/dsh-tools.scheduler') in packages/core/tools/src/index.ts pins one identity across planes; after pnpm run clean && pnpm install && pnpm run build, tool dispatch works and results return to the model.

Patch applied and running on my fork: kristhianmanue1/deepseek-harness branch fix/tool-scheduler-symbol-identity.

[zhangJc-public]

看来和我遇到的是同一个问题。

[RupertCui]

node=v24.19.0 pnpm=11.17.0 npx @deepseek-ai/dsh web 一键安装和源码安装都使用过，为了解决这个问题，两种方式都完全卸载并清理过，但是无论如何重装，清理，都不能解决这个问题。 Rupert ***@***.***

[fsrmqi]

同样的问题，

[HaipingShi]

Independent verification of the Symbol.for fix, plus a fork that has been running it since Sept 20.

Confirming @kristhianmanue1's root cause: under a source launch over a built tree, @deepseek-ai/dsh-tools loads through both the src plane (agent-loop via tsconfig paths under tsx) and the lib plane (the profile-resolved plugin), and a module-local Symbol() gives the two planes different identities for TOOL_RUNTIME_SCHEDULER. We applied the same one-line fix and verified:

1. Dual-plane identity check in one process: import('@deepseek-ai/dsh-tools').TOOL_RUNTIME_SCHEDULER === import('…/packages/core/tools/lib/index.js').TOOL_RUNTIME_SCHEDULER → false before the fix, true after changing to Symbol.for('@deepseek-ai/dsh-tools.scheduler') in packages/core/tools/src/index.ts.
2. pnpm dsh --profile headless "…" dispatches tools normally after the change; before, every tool call died with Cannot read properties of undefined (reading 'prepare') once a built lib/ tree was present.
3. A regression test asserting the registry-key identity now guards the line (tools.spec.ts on our fork).

Fix commit (also carries install-anchor realpath canonicalization for module-fallback declarers): HaipingShi@74c4baf83d — happy to rebase just the one-liner into a clean patch if that is easier to take.

Checked today on dsh-v0.1.7-rc.2: upstream/master packages/core/tools/src/index.ts still has the module-local Symbol(...), so source launches on 0.1.7-rc.2 still hit this.

One caveat for readers of this thread: the fix stops new crashes but does not repair sessions already poisoned by an orphaned tool/call (the crash lands between the committed tool/call and the missing tool/result); those still need the synthetic-result mitigation described in #7129.