Crashed tool call leaves dangling tool_calls in session history (session permanently bricked) — triggered by profile node_modules shadowing of in-box dsh-tools

[ysmole]

Crashed tool call leaves dangling tool_calls in session history (session permanently bricked) — triggered by profile node_modules shadowing of in-box dsh-tools

---

Environment

• dsh CLI: @deepseek-ai/dsh@0.1.1-rc.2 (all @deepseek-ai/* runtime packages at 0.1.1-rc.2), run via npx
• OS: macOS 15 (darwin), Node v24.13.0
• Setup: web profile with out-of-tree plugins installed into ~/.dsh/profiles/web/node_modules/ (mounted via ~/.dsh/cordis.patch.yml), including one plugin whose peerDependencies declared "@deepseek-ai/dsh-host-webserver": "^0.1.0-rc.6"

Summary

Two distinct robustness gaps that compound into a total outage:

1. Module shadowing breaks every tool call. An out-of-tree plugin's peer dependency range caused npm to install @deepseek-ai/dsh-host-webserver@0.1.0-rc.7 (and its transitive @deepseek-ai/dsh-tools@0.1.0-rc.7) into ~/.dsh/profiles/web/node_modules/. This shadows the in-box runtime that healProfilesModuleFallback provides via symlinks in ~/.dsh/profiles/node_modules. The cordis plugin tree then loads a second dsh-tools module instance (rc.7) as the tools service, while dsh-agent-loop (resolved through the fallback symlink to the CLI installation) reads the registry slot with rc.2's TOOL_RUNTIME_SCHEDULER Symbol. Two module instances → two Symbols → ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined → every tool call crashes before dispatch:

   Error: Cannot read properties of undefined (reading 'prepare')
   

   at packages/core/agent-loop (dsh-agent-loop/lib/index.js:193):

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

2. The crash permanently bricks the session. When prepare throws, the agent loop records a turn/end error event but never appends a role: "tool" result for the already-recorded tool/call. The dangling tool_call stays in the session history forever, so every subsequent turn in that session fails at the provider with:

   An assistant message with 'tool_calls' must be followed by tool messages
   responding to each 'tool_call_id'. (insufficient tool messages following
   tool_calls message)  [400 INVALID_REQUEST]
   

   The session can never recover — even after the runtime bug is fixed — because each new turn replays the poisoned history.

Reproduction

1. npx @deepseek-ai/dsh web with a web profile that has out-of-tree plugins under ~/.dsh/profiles/web/node_modules/.
2. Ensure one plugin's peerDependencies contains an old @deepseek-ai/* range (e.g. "@deepseek-ai/dsh-host-webserver": "^0.1.0-rc.6"), then run npm install in the profile directory. npm installs 0.1.0-rc.7 (latest matching the range) of that package — and its dependency closure including dsh-tools@0.1.0-rc.7 — into ~/.dsh/profiles/web/node_modules/.
3. Restart dsh. Boot succeeds (no warnings); the model even receives tool schemas.
4. In a session, send anything that triggers a tool call, e.g. run shell command: ls /tmp.
5. Observe: tool/call is recorded, then 4 ms later the turn ends with Cannot read properties of undefined (reading 'prepare'); no tool/result is ever written.
6. Send any follow-up message in the same session → 400 insufficient tool messages following tool_calls message. Repeat forever; the session is dead.

Evidence

Session log (~/.dsh/sessions/<workdir>/session-*/session.jsonl), abridged:

{"type":"tool/call","seq":72,"data":{"callId":"call_00_AI7i3sODDzH2y2BvWeDA7782","name":"bash","arguments":"{\"command\": \"ls /tmp\"}"}}
{"type":"step/end","seq":73,"data":{"turn":1,"step":1}}
{"type":"turn/end","seq":74,"data":{"turn":1,"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}}
... 8 minutes later, same session ...
{"type":"turn/end","seq":82,"data":{"turn":2,"reason":{"kind":"error","error":{"message":"An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. (insufficient tool messages following tool_calls message)","code":"INVALID_REQUEST"}}}}

Module resolution that produces the Symbol fork (Node's parent-directory walk from the profile):

~/.dsh/profiles/web/node_modules/@deepseek-ai/dsh-tools    → 0.1.0-rc.7  (real dir, installed as peer; shadows fallback)
~/.dsh/profiles/node_modules/@deepseek-ai/dsh-tools        → 0.1.1-rc.2  (symlink fallback to CLI install, per healProfilesModuleFallback)

The plugin tree imports @deepseek-ai/dsh-tools with baseUrl anchored at the profile directory, so it gets rc.7 (the tools service instance). dsh-agent-loop resolves through the fallback symlink to the CLI installation (rc.2) and reads TOOL_RUNTIME_SCHEDULER with rc.2's Symbol — a different object than rc.7's, so the lookup returns undefined.

Relevant code locations:

• packages/core/agent-loop — dsh-agent-loop/lib/index.js:193 (.prepare() crash site; every tool call passes through here)
• packages/core/tools — dsh-tools/lib/index.js:2416 (TOOL_RUNTIME_SCHEDULER = Symbol(...), per-module-instance), :2592 (super(ctx, "tools"))
• dsh-app-boot/lib/index.js:409 (healProfilesModuleFallback — creates the symlink fallback; assumes profile-local node_modules contains only out-of-tree plugins, never @deepseek-ai core packages)

Suggested fixes

1. Agent loop (bug 2, the session bricking — most impactful): when tool startup (prepare/dispatch) throws, append a synthetic error tool/result for the dangling tool_call before ending the turn, so the session history stays protocol-valid and the session remains usable after recovery. Today only a turn/end error event is written; the OpenAI-compatible history is left permanently invalid.
2. Shadow detection (bug 1): healProfilesModuleFallback (or the loader) should detect when a package in the installation closure is shadowed by a different version under <profile>/node_modules — at minimum log a loud warning at boot (boot currently succeeds silently while every tool call is doomed). This is easy to hit for out-of-tree plugins, since npm auto-installs their peerDependencies into the profile root.
3. Optionally (hardens bug 1): the scheduler registry slot could use a stable, well-known key (e.g. a string on the service definition) instead of a per-module-instance Symbol, so duplicate module copies degrade to "wrong version" errors rather than undefined.prepare crashes that give no hint about the real cause.

Workaround (for anyone hitting this now)

Delete the shadowing package from the profile so resolution falls through to the CLI installation's symlink fallback, then restart:

rm -rf ~/.dsh/profiles/web/node_modules/@deepseek-ai/<package>   # the rc.7 copy, not the fallback symlink
# also check nested copies: ~/.dsh/profiles/web/node_modules/<your-plugin>/node_modules/@deepseek-ai/

Affected sessions cannot be repaired through the UI — start a new session (or hand-edit the session history to add the missing tool result).

---

[xiaoshenming]

第二条「崩溃后会话永久砖了」和 #1593 同类：日志能加载，但缺一条对应的 tool/result，供应商会永久 400。根因是 agent-loop 在 prepare 抛错时写了 turn/end，没补 role: tool 结果。

dsh-session-surgeon 不会发明缺失的 tool/result，也不会改 call id（那会把对账修得更假）。它可以 inspect / 导出脱敏 JSONL，帮你定位那条悬空 tool/call。

如果同时还报 seq gap / torn / lacks an identified message（文件结构坏了），那些可以 dry-run 修：

dsh plugin --profile web add "github:xiaoshenming/dsh-session-surgeon#main"

第一条模块双实例 / Symbol 对不上，是 profile node_modules 遮蔽，修会话文件解决不了，得先把冲突的 @deepseek-ai/dsh-tools 从 profile 里拿掉。