0.1.6-alpha.2: tool calls crash with "Cannot read properties of undefined (reading 'prepare')"

[zshqzcn]

Environment

• OS: Windows 11
• Node: v25.2.1
• pnpm: 11.7.0
• Version: dsh-v0.1.6-alpha.2 (commit ddefc45)

Summary

Tool calls crash in 0.1.6-alpha.2. Simple conversation works fine, but the moment the model tries to invoke any tool (shell, computer-control, etc.) the turn fails. 0.1.5-rc.2 works correctly on the same machine.

Steps to reproduce

pnpm install
pnpm run build
pnpm dsh headless "Run the shell command: echo hello"

Expected

The tool call executes and returns "hello".

Actual

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

The --json event stream shows the model emits a tool_call, then the turn ends with:

{"type":"status","phase":"turn_end","reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}

Root cause (source analysis)

packages/core/agent-loop/src/tool-calls.ts:170:

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

At runtime ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined — the Symbol-keyed scheduler view (TOOL_RUNTIME_SCHEDULER, defined in packages/core/tools/src/index.ts) is not reachable, so .prepare throws.

Notes

• Regression: 0.1.5-rc.2 works, 0.1.6-alpha.2 broken.
• DeepSeek API direct calls (including tool_use) work fine — this is a harness-side scheduling issue, not an API/model problem.
• Verified with a clean official build (pnpm run build, client build record present).

[YellowMax2001]

Tool-scheduler crash on the first tool call under pnpm dsh (tsx source mode), which then wedges the session permanently

中英文对照：以上为英文正文，中文全文见文末 中文版。

Summary

Two defects that compound. The first is a one-line fix; the second turns it from a crash into permanent data-level corruption of the session log.

1. Crash. Launching the CLI in tsx source mode (pnpm dsh …) while built artifacts are present evaluates @deepseek-ai/dsh-tools twice. TOOL_RUNTIME_SCHEDULER is declared with a plain Symbol(), so the two module instances hold different keys. ctx.tools[TOOL_RUNTIME_SCHEDULER] is therefore undefined, and the first tool call of the session dies with Cannot read properties of undefined (reading 'prepare').

2. Permanent wedge. The crash lands after the tool/call event is durably appended but before any tool/result. repair.ts only closes turns that are still open, and a scheduler crash closes the turn with {kind:'error'}, so the orphaned call is never repaired. Every later request then fails with DeepSeek Messages tool calls need immediate results — permanently, and restarting the server does not help, because the damage is in the session log on disk.

The setup sequence in the root README (pnpm install → pnpm run build → pnpm dsh web) produces exactly the state that triggers (1).

Environment

• dsh v0.1.6-alpha.2, commit ddefc45
• Node v24.17.0, pnpm 11.7.0
• Windows 11 (the defect is in module resolution, not platform-specific)
• Launch: pnpm dsh web (= node --import tsx/esm apps/cli/src/bin.ts web)

Reproduction

git clone https://github.com/deepseek-ai/deepseek-harness
cd deepseek-harness
pnpm install
pnpm run build          # required: this is what makes lib/ exist
pnpm dsh web            # tsx source mode

In any session, make a turn that calls a tool. Expected: the tool runs. Actual: the turn fails with Cannot read properties of undefined (reading 'prepare') / code UNKNOWN, and from that point on every turn in that session fails with DeepSeek Messages tool calls need immediate results.

A turn that makes no tool call succeeds — which is why the first turn often looks healthy.

Root cause 1 — two module instances, two Symbol() values

packages/core/tools/src/index.ts:463:

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

packages/core/agent-loop/src/tool-calls.ts:170:

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

Under tsx the same package name resolves two ways:

• tsx implements its own tsconfig paths resolution (visible in the stack as resolveTsPathsSync) and maps bare @deepseek-ai/* imports to src/. This is deliberate — it is what lets the source tree run without building.
• The cordis plugin Loader mounts plugin rows through its own dynamic import with a base URL (packages/boot/app-boot/src/index.ts:510-528), which bypasses that mapping and lands on the package exports → lib/.

Two evaluations, two distinct symbols. The ToolRuntime instance carries the lib symbol as an own property key; agent-loop holds the src symbol, so the lookup misses.

Measured both ways:

launch	import.meta.resolve('@deepseek-ai/dsh-tools')	bare.SYM === lib.SYM
node --import tsx/esm …	packages/core/tools/src/index.ts	false
plain node (built entry)	packages/core/tools/lib/index.js	true

Why the error message does not lead anywhere. Both symbols have the same .description (@deepseek-ai/dsh-tools.scheduler), so nothing in the output distinguishes them; agent.ts:334 flattens any non-LlmError into {message, code:'UNKNOWN'}, dropping the stack; and the message names prepare, which invites you to hunt for a missing method rather than a mismatched key.

Why earlier calls appear to work. ctx.tools.executionMode(...) is a prototype method, so it resolves through the prototype chain and is unaffected by the symbol. Only the symbol-keyed own field is missing. tool/call events are appended normally right up to the failing prepare.

Root cause 2 — the orphan is never repaired

The crash sits between two writes:

callSeqs[index] = appendToolCall(session, turn, step, call.block)   // durable
started++
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)  // throws here

packages/core/session/src/repair.ts is built to close exactly this kind of gap: interruptedTurnClosers() emits synthetic error results for calls with no recorded outcome. But it returns [] immediately when openTurn === null — it only handles unclosed turns. A scheduler crash closes the turn with {kind:'error'}, so repair skips it and the unpaired call stays in the log forever.

From then on, packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:117 rejects every request:

if (pending.size > 0) throw new LlmError('DeepSeek Messages tool calls need immediate results', 'INVALID_REQUEST')

This wedge is Messages-protocol-only. The chat-completions serializer does not enforce call/result pairing, so the same log keeps working when llm-deepseek.protocol is chat-completions. Worth knowing when building a repro.

Why the existing test/CI matrix does not catch this

The two halves of the divergence are each covered, but never together — the hybrid state is not exercised anywhere:

• .github/workflows/e2e.yml:109-123 builds and then runs e2e with DSH_EXAMPLE_MODE: lib — a pure lib graph.
• The coverage lane in ci.yml deliberately builds nothing, so workspace imports resolve to src — a pure src graph.
• apps/cli/tests/source-launch.compat.spec.ts does launch the real CLI through tsx, but it only asserts the missing---profile diagnostic and exits before any tool call or plugin dynamic import.

docs/testing.md:45 already names this exact hazard — "stale artifacts there load a second copy of module singletons" — but scopes the rule to the vitest process and explicitly carves out subprocesses ("Built artifacts are consumed only explicitly: lib-mode subprocesses…"). The Loader's dynamic import inside a src-mode child process is precisely the unguarded case.

Nothing checks lib/ against src/; there is no host/CLI watch or rebuild loop; and apps/cli/README.md:56 states plainly that "The launcher does not check freshness."

Finally, the type system cannot help here: ctx.tools[TOOL_RUNTIME_SCHEDULER] is declared non-optional, which is correct under a single module graph. Types are a compile-time claim about one module graph and cannot see that the module was evaluated twice — so no call site is written defensively and no check reports the possibility.

Suggested fix

1. Make the handshake survive duplicate module evaluation (one line). packages/core/tools/src/index.ts:463:

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

Symbol.for uses the global registry, so both module instances hand out the same key. Verified: the identity comparison above goes from false to true under tsx, and the crash no longer reproduces.

2. Do not leave an announced call without a result. In tool-calls.ts, the scheduler-failure path rethrows without closing out started calls (the abort path already does this via appendSkippedToolCall). Closing every remaining call of the step before propagating keeps the transcript serializable. This is defense in depth — it does not fix (1), but it stops any internal failure from poisoning a session beyond the one turn.

3. Optional: assert at activation that ctx.tools?.[TOOL_RUNTIME_SCHEDULER] !== undefined, so a future instance split fails loudly at boot instead of at the session's first tool call.

Verification performed

• Symbol identity probe in both launch modes (table above).
• A repro that boots the real CLI in tsx mode against a mock LLM and issues a tool call: crashed before the fix, runs two tool calls cleanly after.
• For defect 2, since packages/test-support/llm-mock-server serves chat-completions only (it 404s /v1/messages), the A/B was done offline at the serializer boundary using the real readers: decode the session log, cut each variant at the request boundary (the first user/message after the failed turn/end), rebuild with Session.create(id, events), project with deriveMessages(), then call the Messages serialize(). On the identical injected failure: without the guard it throws tool calls need immediate results; with the guard it serializes to 3 wire messages.
• packages/core/agent-loop + packages/core/tools (842 tests) and packages/core/session + packages/llm/llm-deepseek + packages/session (3026 tests) all pass with both changes. No test encoded the previous "do not fabricate tool results" behaviour.

---

中文版

概要

两个缺陷叠加。第一个是一行修复；第二个把它从"一次崩溃"升级成"会话日志的永久性损坏"。

1. 崩溃。 在构建产物已存在的情况下，用 tsx 源码模式启动 CLI（pnpm dsh …）会让 @deepseek-ai/dsh-tools 被求值两次。TOOL_RUNTIME_SCHEDULER 用的是普通 Symbol()，两份模块实例于是持有不同的键，ctx.tools[TOOL_RUNTIME_SCHEDULER] 为 undefined，会话的第一次工具调用即崩溃：Cannot read properties of undefined (reading 'prepare')。

2. 永久卡死。 崩溃点落在 tool/call 事件已持久化之后、任何 tool/result 之前。repair.ts 只修复尚未闭合的 turn，而调度器崩溃会把 turn 以 {kind:'error'} 正常闭合，因此这条孤立调用永远不会被修复。之后每一次请求都会失败于 DeepSeek Messages tool calls need immediate results——永久如此，重启服务器也没用，因为损坏在磁盘上的会话日志里。

根 README 的安装流程（pnpm install → pnpm run build → pnpm dsh web）产生的正是触发第 1 条的状态。

环境

• dsh v0.1.6-alpha.2，commit ddefc45
• Node v24.17.0，pnpm 11.7.0
• Windows 11（缺陷在于模块解析，与平台无关）
• 启动方式：pnpm dsh web（即 node --import tsx/esm apps/cli/src/bin.ts web）

复现步骤

git clone https://github.com/deepseek-ai/deepseek-harness
cd deepseek-harness
pnpm install
pnpm run build          # 关键：这一步让 lib/ 存在
pnpm dsh web            # tsx 源码模式

在任意会话中发一轮会调用工具的消息。预期：工具正常执行。实际：该轮失败于 Cannot read properties of undefined (reading 'prepare')，code 为 UNKNOWN；此后该会话的每一轮都失败于 DeepSeek Messages tool calls need immediate results。

不调用工具的轮次是正常的——这也是为什么第一轮常常看起来没问题。

根因 1 —— 两份模块实例，两个 Symbol()

packages/core/tools/src/index.ts:463：

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

packages/core/agent-loop/src/tool-calls.ts:170：

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

在 tsx 下同一个包名有两条解析路径：

• tsx 自己实现了一套 tsconfig paths 解析（堆栈里可见 resolveTsPathsSync），把裸 @deepseek-ai/* 映射到 src/。这是刻意的——正因如此源码树才能免构建直接运行。
• cordis 插件 Loader 通过自己带 base URL 的动态 import 挂载插件行（packages/boot/app-boot/src/index.ts:510-528），绕开了上述映射，落到 package exports → lib/。

两次求值，两个不同的 symbol。ToolRuntime 实例身上挂着 lib 那份 symbol 作自有属性键，而 agent-loop 手里是 src 那份，于是查表落空。

两个方向的实测：

启动方式	import.meta.resolve('@deepseek-ai/dsh-tools')	bare.SYM === lib.SYM
node --import tsx/esm …	packages/core/tools/src/index.ts	false
原生 node（构建入口）	packages/core/tools/lib/index.js	true

为什么这条报错毫无指向性。 两个 symbol 的 .description 完全相同（@deepseek-ai/dsh-tools.scheduler），输出里没有任何东西能区分它们；agent.ts:334 把所有非 LlmError 压成 {message, code:'UNKNOWN'}，堆栈丢失；而报错文案点名的是 prepare，会诱导你去查"哪个方法没了"，而真正原因是"键对不上"。

为什么之前的调用看起来是好的。 ctx.tools.executionMode(...) 是原型方法，走原型链解析，不受 symbol 影响。丢的只是 symbol 键的自有字段。tool/call 事件会一直正常写入，直到那个失败的 prepare。

根因 2 —— 孤立调用永远不会被修复

崩溃点卡在两次写入之间：

callSeqs[index] = appendToolCall(session, turn, step, call.block)   // 已持久化
started++
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)  // 在这里抛出

packages/core/session/src/repair.ts 本就是为补这类缺口而生的：interruptedTurnClosers() 会为"没有记录结果的调用"补发合成 error result。但它在 openTurn === null 时直接返回 []——它只处理未闭合的 turn。而调度器崩溃会把 turn 以 {kind:'error'} 正常闭合，于是 repair 跳过，未配对的调用永久留在日志里。

此后 packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:117 会拒绝每一个请求：

if (pending.size > 0) throw new LlmError('DeepSeek Messages tool calls need immediate results', 'INVALID_REQUEST')

这个卡死只在 Messages 协议下发生。 chat-completions 的序列化器不校验调用/结果配对，所以同一条日志在 llm-deepseek.protocol 为 chat-completions 时依然能跑。构造复现时值得注意这一点。

为什么现有的测试/CI 矩阵抓不到

分歧的两半各自都有覆盖，但从不一起覆盖——这个混合状态在任何地方都没有被执行到：

• .github/workflows/e2e.yml:109-123 先构建，再用 DSH_EXAMPLE_MODE: lib 跑 e2e —— 纯 lib 图。
• ci.yml 的覆盖率 lane 刻意不构建，于是工作区导入全部解析到 src —— 纯 src 图。
• apps/cli/tests/source-launch.compat.spec.ts 确实通过 tsx 启动了真实 CLI，但它只断言缺少 --profile 时的诊断信息就退出了，走不到任何工具调用或插件动态 import。

docs/testing.md:45 其实已经点名过这个危险——"stale artifacts there load a second copy of module singletons"——但该规则被限定在 vitest 进程内，并明确把子进程排除在外（"Built artifacts are consumed only explicitly: lib-mode subprocesses…"）。而 Loader 在一个 src 模式子进程内部做的那次动态 import，恰恰是这个规则没覆盖到的情况。

没有任何检查比对 lib/ 与 src/；没有 host/CLI 的 watch 或 rebuild 循环；apps/cli/README.md:56 也直说了："The launcher does not check freshness."

最后，类型系统在这里帮不上忙：ctx.tools[TOOL_RUNTIME_SCHEDULER] 被声明为非可选，这在单模块图下是完全正确的。类型是关于一份模块图的编译期断言，它看不见模块被求值了两次——于是没有任何调用点写防御性判空，也没有任何检查会报告这种可能性。

建议的修复

1. 让握手在模块被重复求值时依然成立（一行）。 packages/core/tools/src/index.ts:463：

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

Symbol.for 走全局注册表，两份模块实例会拿到同一个键。实测：tsx 下上面的同一性比较由 false 变为 true，崩溃不再复现。

2. 不要让一条已公布的调用没有结果。 在 tool-calls.ts 中，调度器失败路径在重抛前没有收尾已启动的调用（而 abort 路径已经通过 appendSkippedToolCall 做了这件事）。在向上抛之前把该 step 剩余的全部调用收尾，可以保证记录始终可序列化。这属于纵深防御——它修不了第 1 条，但能阻止任何内部失败把会话毒化到超过一轮。

3. 可选： 在激活时断言 ctx.tools?.[TOOL_RUNTIME_SCHEDULER] !== undefined，让将来任何实例分裂在启动时就大声失败，而不是等到会话的第一次工具调用。

已做的验证

• 两种启动模式下的 symbol 同一性探针（见上表）。
• 一个在 tsx 模式下启动真实 CLI、对接 mock LLM 并发起工具调用的复现：修复前必崩，修复后两次工具调用全部正常。
• 针对缺陷 2：由于 packages/test-support/llm-mock-server 只提供 chat-completions（对 /v1/messages 返回 404），A/B 改为在序列化器边界离线进行，且全部使用真实代码路径——解码会话日志、把两个变体都截在请求边界上（失败的 turn/end 之后的第一条 user/message）、用 Session.create(id, events) 重建、用 deriveMessages() 投影，再调用 Messages 的 serialize()。在完全相同的注入失败下：无护栏版本抛出 tool calls need immediate results，有护栏版本正常序列化为 3 条 wire message。
• 两处改动后，packages/core/agent-loop + packages/core/tools（842 项）与 packages/core/session + packages/llm/llm-deepseek + packages/session（3026 项）测试全绿。没有测试固化了此前"不伪造工具结果"的行为。

[wxy123-ctrl]

原来不止我一个遇到这个问题，发版都不测的吗...

[PerryLink]

Confirming the diagnosis from a second machine, plus two additions that matter for whoever applies the fix.

What I reproduced

I worked from a checkout at ddefc45fbc — the same commit both reports cite.

1. The declaration is still plain — so this is not fixed yet.

packages/core/tools/src/index.ts:463

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

2. Under tsx the bare specifier resolves to source, and a second evaluation produces a different symbol — same process, measured:

$ node --import tsx/esm --input-type=module -e "console.log(import.meta.resolve('@deepseek-ai/dsh-tools'))"
file:///D:/deepseek-harness/packages/core/tools/src/index.ts

$ node --import tsx/esm --input-type=module -e "
    const a = await import('@deepseek-ai/dsh-tools')
    const b = await import('./packages/core/tools/lib/index.js')
    console.log(a.TOOL_RUNTIME_SCHEDULER === b.TOOL_RUNTIME_SCHEDULER)"
false

3. The hazard is not really about src-vs-lib. Two instances of the same built file reproduce it, which is the cleaner demonstration and also confirms the remedy:

a = ./packages/core/tools/lib/index.js
b = ./packages/core/tools/lib/index.js?v=2

a.TOOL_RUNTIME_SCHEDULER === b.TOOL_RUNTIME_SCHEDULER                  -> false
a.TOOL_RUNTIME_SCHEDULER.description === b.TOOL_RUNTIME_SCHEDULER.description -> true
Symbol.for('@deepseek-ai/dsh-tools.scheduler') === Symbol.for(same)    -> true

Addition 1 — do not blanket-replace Symbol() in that file

There is a second plain Symbol() two thousand lines further down, and it has to stay one.

packages/core/tools/src/index.ts:1875

/** Mint a same-process correlation token whose identity is its value. */
function createExecutionToken(): ToolExecutionToken {
  return Symbol('dsh.tool.execution') as ToolExecutionToken
}

Its identity is its value: it is minted per call, carried as a value on ToolExecution/ToolExecutionResult, and correlated through private readonly canonicalResults = new WeakMap<object, ToolExecutionToken>(). Registering it globally would make two concurrent calls collide. So the one-line change on :463 is a complete fix, not half of one — which is worth stating explicitly, because "use Symbol.for for symbols" applied mechanically here would introduce a new bug.

Addition 2 — Symbol.for is already this repo's convention for exactly this handshake

This is not a workaround; the codebase already does it wherever a key has to survive a second evaluation:

• packages/typert/protocol/src/owned-value.ts:4 — export const TYPERT_OWNED_VALUE = Symbol.for('dsh.typert.owned-value')
• packages/subagent/subagent/src/internal.ts:15,42 — Symbol.for('dsh.subagent.adjacentAgentSendMessageTool'), Symbol.for('dsh.subagent.deliverPrompt')
• packages/experimental/inspector/src/shared/cordis/collector.ts:14 — Symbol.for('cordis.shadow')

And packages/typert/protocol/tests/owned-value.spec.ts:19-23 is the same scenario as this report, written as a test — it is named "recognizes a separately produced marker…" and constructs the second evaluation by hand:

const siblingBundle = { [Symbol.for('dsh.typert.owned-value')]: true, value: {}, [Symbol.dispose]() {} }
expect(isTypertOwnedValue(siblingBundle)).toBe(true)

That is the natural template for a regression test here:

expect(TOOL_RUNTIME_SCHEDULER).toBe(Symbol.for('@deepseek-ai/dsh-tools.scheduler'))

It is a one-line assertion that would have caught this, and it fails today.

What I did not verify

• I did not re-run the end-to-end CLI repro (source-mode CLI + mock LLM + a real tool call). What I confirmed is the three-hop chain: tsx resolves the bare specifier to src; a second evaluation yields a different symbol; the two descriptions are identical.
• I did not instrument the cordis Loader to prove it is the specific second importer. Statically the mechanism is consistent with the code: mountRootInclude(ctx, absoluteConfigPath, patches, bareModuleBaseUrl) in packages/boot/app-boot/src/index.ts routes bare specifiers through internal.import(specifier, bareModuleBaseUrl, {}), which does not go through tsconfig paths.
• I did not run the 842 + 3026 test suites.

One more thing that supports the "why CI misses it" section: docs/testing.md:45 does already state the rule — "bare workspace imports resolve to src … never through package exports to built lib/ — stale artifacts there load a second copy of module singletons" — but scopes it to the vitest process and carves subprocesses out. A src-mode child process is outside the rule as written, which is exactly where the Loader's import lands.

---

中文摘要

在另一台机器上按两位报告者所引的同一个 commit（ddefc45fbc）独立复核，结论成立：

1. :463 至今仍是普通 Symbol()，修复未落地；
2. tsx 下裸标识符解析到 src/index.ts，同一进程内第二次求值拿到的是另一个 symbol（=== 为 false）；
3. 这个坑与 src/lib 无关——把同一个构建产物加载两次，结果同样是 false；而 Symbol.for 两次得到同一个键。这也顺带证明了那条一行修复的方向是对的。

两点补充（给动手改的人）：

• ⚠️ 不要顺手把这个文件里所有 Symbol() 都换成 Symbol.for。:1875 的 createExecutionToken() 必须保持普通 Symbol()——它的身份即其值，按调用现造、按值传递、用 WeakMap 关联；注册成全局键会让两次并发调用撞车。所以只改 :463 一处就是完整修复。
• ✅ Symbol.for 本就是本仓处理「同一个逻辑模块被求值两次」的既有约定：typert/protocol/src/owned-value.ts:4、subagent/subagent/src/internal.ts:15,42、inspector/…/collector.ts:14。而 typert/protocol/tests/owned-value.spec.ts:19-23 那条测试的名字就是 "recognizes a separately produced marker…"，它手工构造的 siblingBundle 与本案是同一场景——照着它加一行断言即可：expect(TOOL_RUNTIME_SCHEDULER).toBe(Symbol.for('@deepseek-ai/dsh-tools.scheduler'))。这行断言今天就会失败。

未验证的部分（如实说明）：没有重跑端到端 CLI 复现，也没有给 cordis Loader 打点确认它就是那个「第二个 importer」；842 + 3026 两套测试也没跑。

[argszero]

This thread has the mechanism and the remedy right. Three things are still missing from it: why 0.1.5-rc.2 → 0.1.6-alpha.2 is a boundary at all (the README sequence does not explain it — lib/ exists under 0.1.5-rc.2 too), the exact closing rule for defect 2 (the obvious version of it has a trap), and anything that helps a session which is already wedged.

1. The boundary is a one-commit default flip — and that flip implemented written intent

9ddef327a4 ("feat: resolution mode link to runtime", 2026-09-17 20:08 +0800) changes exactly two lines:

 apps/cli/src/profile-boot.ts:263
-  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'link'
+  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'

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

That flip is the whole release delta, not the build step:

$ git tag --contains 9ddef327a4
dsh-v0.1.6-alpha.2
$ git merge-base --is-ancestor 9ddef327a4 dsh-v0.1.5-rc.2    # exit 1

With ?? 'link' the source launcher resolves the profile through healProfilesModuleFallback (disk links); with ?? 'runtime' it computes the runtime generation and registers PluginPackages with behavior: 'enforce' (profile-boot.ts:210, :312-315). That second plane is precisely the precondition for the src/lib divergence you measured, which is why the older release is clean on the same machine. apps/cli/src/bin.ts:38 calls runProfile without resolutionMode, and no flag or env var reaches it, so the default is the behaviour.

The same commit's other half was reverted 39 minutes later. d9a55c7c0d ("fix: revert desktop") puts apps/desktop-host/src/index.ts:21 back to process.argv[5] === 'runtime' ? 'runtime' : 'link'. Both commits are contained in dsh-v0.1.6-alpha.2, so the desktop launcher already defaults to link again and only the CLI half is still standing.

But this is not a stray edit, and that changes what the fix should be. .agents/notes/implemented/architecture/2026-09-09-profile-resolution-generations.md:77 states the intent — "The dsh launcher selects runtime mode when an ordinary Node caller omits resolutionMode. A pkg executable always selects runtime mode, and the Electron Host explicitly selects runtime mode in both development and packaged builds…" — and the same note already names the hazard, for Workers: "The ESM bootstrap cannot affect static dependencies linked before its execution" (:59). Under runtime the generation deliberately routes plugin imports to built entries, so a launcher that is itself running from src/ has two identity planes by design. The durable question is therefore not "which default is right" but "which identity handshakes must survive a second evaluation".

The three layers are not alternatives:

	change	what it fixes	cost
a	profile-boot.ts:263 back to ?? 'link'	this release's regression, immediately	contradicts the design note above — a decision, not a quiet fix
b	tools/src/index.ts:463 → Symbol.for('@deepseek-ai/dsh-tools.scheduler')	the class: any second evaluation, in any mode	one line; keeps runtime mode; the :1875 caveat above applies
c	canonicalize the recorded declarer (profile.ts:504, consumed at resolver.ts:693/:792/:829)	the resolution defect itself	the 3-line change already proposed in #7201

(b) is the one that generalizes, and it is this repo's own convention rather than a workaround: TYPERT_OWNED_VALUE (typert/protocol/src/owned-value.ts:4) exists for exactly this case ("a separately produced marker"), alongside the subagent and inspector keys already listed here. If (b) is the answer, the other cross-plane identity keys are worth auditing in the same pass rather than fixing this symbol alone.

2. Defect 2 — the closer set is [committed, group.length), and group.slice(started) misses the culprit

The abort path and the failure path sit six lines apart, and only one of them pairs its calls:

callSeqs[index] = appendToolCall(session, turn, step, call.block)   // :168  durable
started++                                                          // :169
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)  // :170  throws
…
} catch (error: unknown) {                                          // :232
  schedulerFailure ??= { error }
  await Promise.allSettled(inFlight.values())
  throw schedulerFailure.error                                      // ← nothing paired
}
if (aborted) {                                                      // :238
  for (const call of group.slice(started)) appendSkippedToolCall(session, turn, step, call.block)

runGroup's own doc comment already admits the gap: "Scheduler failure drains dispatches without committing synthetic recovery results."

The trap when closing it: started++ (:169) runs before the await that throws (:170), so the failing call sits at an index below started. Copying the abort branch's group.slice(started) therefore skips exactly the call that caused the failure. It is not merely an off-by-one at started - 1 either: with a parallel pool the failing call can be any started index. The predicate has to be per slot rather than a slice — for every index in [committed, group.length):

• callSeqs[index] === undefined → never announced → append the call and its result, mirroring appendSkippedToolCall (:250-261);
• callSeqs[index] !== undefined → already durable → append only the result, citing callSeqs[index], mirroring commitReady's tail (:145-147).

The two cases also deserve different wording, because different things are known: a prepare that threw proves the body never ran (the message :254-259 already carries, TOOL_ABORTED_BEFORE_DISPATCH), whereas a call that was dispatched and whose promise rejected (:179-183 sets schedulerFailure and leaves slots[index] unset) did run, and there only repair.ts:106's "outcome is unknown" phrasing is honest. One boolean recorded at dispatch separates the two.

Unlike (b), this one also covers every other member of the family where the scheduler fails for reasons that have nothing to do with symbols: the poison is written by whichever write comes first, and the pairing gap is downstream of all of them.

3. For a session that is already wedged

Neither fix helps a log that is already poisoned — including the one in this report. There is a plugin for that case:

@argszero/cordis-plugin-orphan-tool-call-guard · npm · repo

- insert:
    - id: orphan-tool-call-guard
      name: '@argszero/cordis-plugin-orphan-tool-call-guard'

It listens on the llm/stream waterfall and, per outgoing request, supplies a synthetic result for every declared tool call nothing answers — re-derived on each request, so the session stays usable. The wording it injects is interruptedTurnClosers()'s own (the tests compare against the real function rather than against a copy of its text), and mode: observe reports the poison without repairing it.

Its boundary is the same one your defect-2 analysis reaches from the other side: it cannot write to the log, because an appended tool/result has to name the currently open turn and step, and that turn closed with {kind:'error'}. So it repairs the request, not the log — the log keeps telling the truth about what happened, and the request carries one synthetic message that says what it is. The trade is a session that cannot reach any provider, versus a request the log does not fully own.

Cross-links

The source-launch subclass of this family is now six threads in four days: #6967 (09-17, instrumented module.register boot), #7106 / #7107 / #7108 / #7117 (09-18; #7107 is the one that named 9ddef327a4), #7201 (09-19, resolver data model plus the 3-line fix), and this one. Older reports with the same signature but different triggers — a duplicated copy from hoisting, from a packaged dependency, or from a plugin bundling its own copy — are #1337, #2660 and #3033.