Turn fails with "Cannot read properties of undefined (reading prepare)" on tool dispatch (0.1.1-rc.2)

[wumaohua233]

Environment

• @deepseek-ai/dsh@0.1.1-rc.2 (npm global, latest rc)
• macOS 26.5.2 arm64, Node v24.5.0
• Running via dsh web

Symptom

A turn dies immediately when the model emits a tool call. The web UI shows "本轮运行失败 / Cannot read properties of undefined (reading 'prepare')" with code UNKNOWN. The tool never executes.

The session log (session.jsonl.zstd) shows the failure happens within ~3ms of registering the call, with no tool/result ever recorded:

{"type":"tool/call","data":{"turn":11,"step":1,"name":"bash",...}}
{"type":"step/end","data":{"turn":11,"step":1}}
{"type":"turn/end","data":{"turn":11,"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}}

Suspected cause

In @deepseek-ai/dsh-agent-loop/lib/index.js (runGroup → startCall):

const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec);

TOOL_RUNTIME_SCHEDULER is a module-local Symbol("@deepseek-ai/dsh-tools.scheduler") defined in @deepseek-ai/dsh-tools, and the scheduler is attached to the ToolRuntime service instance under that symbol key. The error text (reading 'prepare', not reading 'Symbol(...)') means ctx.tools exists but the symbol slot is undefined — i.e. the symbol identity seen by dsh-agent-loop no longer matches the one used to build the live ToolRuntime. This smells like a duplicate/reloaded module instance (e.g. after a cordis HMR plugin reload in the long-running dsh web process), which would invalidate every Symbol()-keyed cross-package lookup.

Reproducibility

Observed in 7 different sessions between 2026-08-20 and 2026-08-26. In each session the crash happens at the first tool call the model makes (turn 1 for fresh sessions, mid-session otherwise); before the crash those sessions only contain plain-text turns. Restarting the dsh web process makes tool calls work again, suggesting the bad state is process-level, not session-level.

Related secondary issue

When the user attaches an image in the web UI, the model (DeepSeek, text-only) receives only a textual reference (Image sha256:...; 884x650px) with no image content. The model's own reasoning in the log shows it cannot see the image ("we cannot see actual image... I don't have vision"), and it resorts to running find / -type f -iname '*.png' ... across the whole filesystem to locate the file — which is how we hit the crash above. Consider either blocking image attachments for non-vision models or surfacing a clear capability notice.

Happy to provide the raw session jsonl if useful.

[nokkies]

This is a duplicate copy of @deepseek-ai/dsh-tools somewhere under your profile's node_modules — diagnosed in detail on #4640.

The short version: the agent loop looks the scheduler up on the ToolRuntime by a symbol key, and that key is currently a module-local Symbol(). Two copies of the package mint two non-equal symbols, so the lookup returns undefined and every tool call in that profile dies at .prepare. Nothing fails at load, and the message names neither the tool nor the duplicated package, which is why it reads like the harness or the provider broke.

Two things worth knowing while a fix lands:

Finding it. Look for more than one @deepseek-ai/dsh-tools under the profile — including an orphan left by a package the profile no longer references, which is enough on its own.

Your session is probably not recoverable. The failing turn appends tool_calls that never receive results, so the provider refuses the next request with "An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'". Start a new conversation rather than retrying in the damaged one.

The fix is to key on the global symbol registry (Symbol.for) so a second copy computes the same key; details and suggested tests are on #4640.

[weijiafu14]

@nokkies has your primary crash. I want to pick up the secondary issue nobody has answered, because on your own evidence it is not secondary — it is what produced the crash.

Your two problems are one causal chain. The model could not see the image, so it went looking for it with find / -type f -iname '*.png', and that is the tool call that hit the duplicate-symbol bug. Fix the capability notice and this particular turn never reaches the broken lookup. That is worth saying out loud, because "add a capability notice" reads like polish next to a crash, and here it is the trigger.

It is also the same failure shape as the crash you reported, one layer up: in both cases the system already held the information the user needed and did not put it in front of them. The symbol lookup returns undefined and nothing says which package was duplicated; the route is text-only and nothing says the image was dropped. Your report is unusually good precisely because you reconstructed both from a jsonl.

One concrete thing to check, because what you saw does not match what this version line is supposed to do. On the 0.1.1 line the host's own dispatch resolves the modality mismatch and replaces the image block with an explicit [image omitted …] text notice — we assert exactly that in a contract test against an installed 0.1.1 host, capability-detected off LlmAdapter.prototype.prepareCall. You are on 0.1.1-rc.2 and the model instead received Image sha256:…; 884x650px, which is not that notice. So either your route is not declared text-only — DSH believes that model accepts image input and therefore has no mismatch to resolve — or the attachment reached the request by a different path. Worth checking the declared input modalities on that provider route in your settings before this gets filed as "the notice is missing"; if the route claims image input, no notice can fire and the fix is in the route declaration, not in the notice.

If what you actually want is for a text-only model to answer questions about pasted images, there is a working path today that does not involve DSH changing anything: a vision-companion plugin sends the image to a vision model you configure and injects the analysis into the turn, so the text model answers about the picture. I maintain the compatibility engine that path runs on, so treat this as an interested party's answer — it is verified end to end on a real DSH loop, CLI and web, but it is a parallel path, not a repair: DSH's own attachment handling and the missing notice are untouched, and your request that the host either block the attachment or say something is still the right ask on this thread.