[0.1.6] Source launch (pnpm dsh) loads @deepseek-ai/dsh-tools twice, so every tool call fails with "Cannot read properties of undefined (reading 'prepare')"

[mcus890]

Summary

Launching dsh from source (pnpm dsh web, i.e. node --import tsx/esm apps/cli/src/bin.ts web) on 0.1.6-alpha.2, the first tool call in any session fails:

This turn failed  Cannot read properties of undefined (reading 'prepare')   UNKNOWN

Every later attempt in that session then fails with DeepSeek Messages tool calls need immediate results (INVALID_REQUEST), because the assistant message has tool calls whose results were never recorded.

Environment

• OS: Windows 11 (win32)
• Node: v22.20.0
• pnpm: 11.7.0 (matches packageManager)
• dsh: 0.1.6-alpha.2 (repo HEAD ddefc45f)
• Launch: pnpm dsh web (source launch via tsx), default resolutionMode: runtime

Steps to reproduce

1. pnpm install && pnpm run build (so packages/*/*/lib exists)
2. pnpm dsh web
3. In any session, send a prompt that triggers a tool call (e.g. run pwsh: Get-Date)

Actual

The tool/call event is appended, then the turn ends with:

turn/end { reason: { kind: 'error', error: { message: "Cannot read properties of undefined (reading 'prepare')", code: "UNKNOWN" } } }

No tool/result is recorded; the session is left with a dangling tool call and becomes unusable.

Expected

The tool executes and its result is recorded.

Root cause

@deepseek-ai/dsh-tools is loaded as two different module instances in one process, so the unique symbol TOOL_RUNTIME_SCHEDULER has two identities:

• The plugin entry is resolved by the runtime profile resolver to the built file packages/core/tools/lib/index.js (generation entry packageDir/declarer: apps/cli/node_modules/@deepseek-ai/dsh-agent-instructions/node_modules/@deepseek-ai/dsh-tools).
• packages/core/agent-loop/lib/index.js imports @deepseek-ai/dsh-tools, and tsx applies the tsconfig paths alias, resolving it to packages/core/tools/src/index.ts.

ToolRuntime stores its scheduler under the symbol defined in the lib copy; tool-calls.ts looks it up with the symbol from the src copy, so ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined and .prepare(...) throws.

This is a regression from the new immutable profile resolution generations (.agents/notes/implemented/architecture/2026-09-09-profile-resolution-generations.md): the runtime resolver delegates entry resolution to the installation's nested package path, where tsx no longer applies the tsconfig aliases, while nested workspace imports still resolve to src. A fully built launch (plain Node, no tsx) is consistent and does not reproduce.

Evidence

Reproduced with the real web profile generation:

const gen = await createProfileResolutionGeneration({ installAnchor, profile })
installProfileResolution(gen, 'enforce')
const entry = await loader.import('@deepseek-ai/dsh-tools', profileBaseUrl, {})
const src   = await import('./packages/core/tools/src/index.ts')
entry.TOOL_RUNTIME_SCHEDULER === src.TOOL_RUNTIME_SCHEDULER  // false

• entry resolves to packages/core/tools/lib/index.js
• import.meta.resolve('@deepseek-ai/dsh-tools', '.../packages/core/agent-loop/lib/index.js') resolves to packages/core/tools/src/index.ts
• both symbols stringify as Symbol(@deepseek-ai/dsh-tools.scheduler) but are not identical

Relevant code:

• packages/core/agent-loop/src/tool-calls.ts:170 - ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)
• packages/core/tools/src/index.ts:463 - TOOL_RUNTIME_SCHEDULER
• packages/core/tools/src/index.ts:798 - the scheduler class field

Suggested fix

Make the internal cross-package scheduler key survive duplicate module instances by registering it in the global symbol registry (already the repo's pattern for this, e.g. packages/typert/protocol/src/owned-value.ts, packages/subagent/subagent/src/internal.ts):

export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol.for('@deepseek-ai/dsh-tools.scheduler')

A one-line change in packages/core/tools/src/index.ts (plus rebuilding lib/) fixes it; verified locally (a fresh session then executes tools normally). Fixing the resolver so plugin entries and their imports resolve on the same source/lib plane would remove the underlying inconsistency, but is a larger change.

Notes

• Reproduced on Windows; the nested pnpm node_modules layout (.../dsh-agent-instructions/node_modules/@deepseek-ai/dsh-tools) may differ on macOS/Linux, so this may be platform-dependent. Snapshot tests boot source via tsx but do not appear to exercise this path.
• Workaround without a code change: launch the built entry instead of the tsx source entry.

[romankurnovskii]

same on mac

[argszero]

Same mechanism as #7106, #7107 and #7117 — this is one regression across four reports, and your environment details (plus the "same on mac" confirmation) are what show it is not Windows- or Node-22-specific.

Root cause is one line. apps/cli/src/profile-boot.ts:263 at HEAD is … options.resolutionMode ?? 'runtime'; commit 9ddef327a4 ("feat: resolution mode link to runtime", shipped only in dsh-v0.1.6-alpha.2) changed ?? 'link' into ?? 'runtime'. Source launch now boots profile rows through the runtime resolution generation while agent-loop's static import of @deepseek-ai/dsh-tools was linked natively beforehand — two URLs, two module instances, and the module-level Symbol('@deepseek-ai/dsh-tools.scheduler') (packages/core/tools/src/index.ts:463) is therefore evaluated twice. packages/core/agent-loop/src/tool-calls.ts:170 looks it up with the other copy's key, reads undefined, and throws on .prepare before any tool body runs — hence the missing tool/result and the follow-on INVALID_REQUEST on every later request.

The same commit also flipped apps/desktop-host/src/index.ts:21, and 39 minutes later the same author reverted only that half (d9a55c7c0d "fix: revert desktop"), restoring the conditional. Both are in dsh-v0.1.6-alpha.2, so the CLI carrier is the remaining flipped half.

One thing specific to your repro: you run pnpm run build before pnpm dsh web, so lib/ exists and the two planes can pair a source instance against a built one. A key-identity fix removes the crash but leaves both instances alive, so that src-versus-built pairing is the case where a symptom fix could turn a loud failure into a quiet mismatch. Details in #7117.

[Gniy7Ga]

Thanks for the detailed reproduction and the macOS confirmation. We’ve linked this report to the existing investigation into source-launch tool dispatch failures, including the missing tool result and subsequent INVALID_REQUEST in the affected session. Your source/built module comparison and local patch results are recorded as evidence; they are not yet a verified released fix. We’ll follow up here when a user-available release is confirmed to address this scenario.

[yamingmou]

EN / English

What this adds, and what it does not. This is about the downstream half of what the team described as under investigation — "the missing tool result and subsequent INVALID_REQUEST in the affected session". The upstream half is already pinned to one line by @argszero below (and that desktop-only revert is the strongest available evidence the default was recognised as wrong), so I am not re-stating it, and I am not claiming this mechanism as our find.

The narrower question we asked: once the dispatch step throws and the tool/call is already durable, why doesn't the harness heal itself? It owns a repair path that synthesizes exactly the missing result.

From dsh-session@0.1.6-alpha.2, lib/types/repair.js:

• :23 interruptedTurnClosers(events) scans the log, remembers every tool/call that has no tool/result, and at the end synthesizes one for each — ToolOutcomeUnknownError / TOOL_OUTCOME_UNKNOWN when the call had started (:112-114), ToolNotStartedError / TOOL_NOT_STARTED when it never did;
• and it is wired into resume: dsh-agent-loop lib/index.js:1896 resumeWith() → :1916 cold-reads the full log → :1919 calls interruptedTurnClosers → :1920 appends whatever it returned.

But repair.js:76 decides whether it does anything at all:

if (openTurn === null || last === undefined) return [];   // "Balanced log (no crash mid-turn): nothing to close"

It fires only when the log ends with an unclosed turn — and this failure path does not leave one. The shape recorded in #2034 is tool/call (no result) → step/end → turn/end. So openTurn is null, the log reads as balanced, closers is [], nothing is appended, and the dangling call is loaded as-is on every later resume. Both recovery readers share that predicate — dsh-session-query lib/index.js:52 calls the same function, so there is no second path that would catch it.

Why this matters for this thread specifically: reverting the default or switching launch entry stops new sessions from being poisoned; it does not repair sessions already written — those stay at INVALID_REQUEST until something reads the log and fills the gap out-of-band. So closing this scenario likely needs both halves: the dispatch failure and the sessions already on disk.

Detail, the family table and the boundaries are in #4549 (posted today) — I did not want to paste that much into this thread.

Boundaries, stated plainly. Everything above is static reading of the shipped code on 0.1.6-alpha.2, not a triggered reproduction; the turn/end-already-written shape is quoted from #2034's reproduction, not ours. And the converse holds too — if the turn is genuinely left unclosed, the closers do fire; the gap is specifically the case where the failure is caught and the turn closes normally. If any line here misstates the mechanism, say so and I will correct it.

Authorship note: reproduced and documented by me in real-world usage; root-cause tracing and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版 / ZH

先说清这条补的是什么、不是什么。 这里只谈调查范围的下游那一半 —— 官方原话里的 "the missing tool result and subsequent INVALID_REQUEST in the affected session"。上游那一半已由 @argszero 在本帖钉死到单行（而那次"只回退桌面半"的提交，是"该默认值被认定为错"的最强现成证据），所以我不重复上游，也不主张这个机制是我们的发现。

我们问的是一个更窄的问题：调度那一步抛错、而 tool/call 已经落盘之后，为什么引擎不会自愈？—— 它手里就有一条能合成出那条缺失结果的修复路径。

取自 dsh-session@0.1.6-alpha.2 的 lib/types/repair.js：

• :23 interruptedTurnClosers(events) 遍历日志，记住每一件没有 tool/result 的 tool/call，在结尾为它们逐个合成 —— 该调用已 started 时产出 ToolOutcomeUnknownError / TOOL_OUTCOME_UNKNOWN（:112-114），从未 started 时产出 ToolNotStartedError / TOOL_NOT_STARTED；
• 而且它确实接在恢复路径上：dsh-agent-loop lib/index.js:1896 resumeWith() → :1916 冷读全量日志 → :1919 调用 interruptedTurnClosers → :1920 有返回就追加。

但 repair.js:76 决定它到底动不动：

if (openTurn === null || last === undefined) return [];   // "Balanced log (no crash mid-turn): nothing to close"

它只在日志以未闭合的 turn 结尾时启动 —— 而这条失败路径不留这种尾巴。#2034 记下的形态是 tool/call（无结果）→ step/end → turn/end。于是 openTurn 为 null、日志被读成平衡的、closers 是 []、什么都不追加，此后每次恢复都把那条悬空调用原样载入。两个恢复读取方共用这一判据 —— dsh-session-query 的 lib/index.js:52 调的是同一个函数，所以不存在"另一条路能兜住"。

对本帖的实际含义：回退那个默认值、或换启动入口，只让新会话不再被毒；治不了已经写坏的会话 —— 那些会一直停在 INVALID_REQUEST，直到有人离线读日志把缺口补上。所以要关掉这个场景，很可能两半都得做：调度失败本身，以及已经落盘的那些会话。

细节、家族表和边界在 #4549（今天发的），我不想把那么长一段贴进本帖。

边界，直说。 以上全部是对已发布代码的静态阅读（0.1.6-alpha.2），不是构造会话触发的复现；turn/end 已落盘这一形态转引自 #2034 的复现记录，不是我们复现的。反向边界同样成立 —— 若 turn 确实是未闭合的，closers 会生效；缺口专指"失败被捕获、turn 正常闭合"这一情形。若这里哪一句把机制写错了，请直接说，我会改。

协作说明：本文由我在真实使用中复现并记录；根因与成文由 AI 协助完成，我负责校验与发布。我非工程背景，技术表述如有错误，欢迎指出——我会回去用工具链重新验证后更正。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com