[Bug] tsx source launch + Symbol() dual-load: ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined (prepare crash, then INVALID_REQUEST)

[jetsamsun]

Summary

On 0.1.6-alpha.2 (ddefc45fbc, including #4471), launching from a source checkout with pnpm dsh web (node --import tsx/esm apps/cli/src/bin.ts) breaks every tool call.

Text-only turns succeed. The first tool (e.g. Pwsh) fails the whole turn with:

Cannot read properties of undefined (reading 'prepare')

code: UNKNOWN

A later message in the same session then fails serialization with:

DeepSeek Messages tool calls need immediate results

code: INVALID_REQUEST

That second error is a cascade: tool/call was appended, but the crash happens before a matching tool_result is written.

Where it breaks

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

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

TOOL_RUNTIME_SCHEDULER is a per-realm Symbol(), not Symbol.for():

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

pnpm dsh web evaluates CLI/agent-loop through tsx + source, while Cordis plugin load uses package exports �� lib/index.js. That loads @deepseek-ai/dsh-tools twice. Symbol('same description') !== Symbol('same description'), so ctx.tools[importedSymbol] is undefined.

#4471 (feat(cli): use runtime resolution for plain Node launches) makes this split much easier to hit on a source checkout.

Reproduce (Windows, source tree)

1. Checkout dsh-v0.1.6-alpha.2 / master at ddefc45fbc.
2. pnpm install && pnpm run build
3. pnpm dsh web (tsx source launcher, not the installed apps/cli/lib/bin.js)
4. New session, send a text-only prompt �� succeeds.
5. Ask for a filesystem/shell action that must call Pwsh / Bash �� turn dies on prepare.
6. Send another message in that session �� INVALID_REQUEST (unresolved tool_use).

Suggested fix

Use a global symbol so both module copies share one key:

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

Locally, that one change unblocks tool dispatch without changing the scheduler API.

Environment

• OS: Windows 10
• Launch: pnpm dsh web from a git checkout (node --import tsx/esm apps/cli/src/bin.ts)
• Version: @deepseek-ai/dsh-root@0.1.6-alpha.2
• Official PRs are not accepted; posting here per CONTRIBUTING.

[zhang-guo-wen]

已把这批 0.1.6-alpha.2 源码启动故障的共同根因和完整修复方案汇总到 #7011 的这条回复。

本帖属于其中的 tsx src + runtime lib 混载路径。建议上游同时落地四项，而不是只选其中一个 workaround：

1. TypeScript 源码启动默认 link，构建产物/pkg 保持 runtime；
2. TOOL_RUNTIME_SCHEDULER 改用 Symbol.for(...)；
3. profile/plugin 安装后检测同名核心包的多个 realpath/版本；
4. 在写入 tool/call 前取得并验证 scheduler，避免失败后留下无法配对的持久事件。

本地 CLI 聚焦测试 16/16、tools scheduler key 测试和 CLI/tools/agent-loop TypeScript build 已通过。详细补丁、用户恢复步骤、会话处理和回归门禁见上面的集中回复。