[Bug] 0.1.6-alpha.2 source launch (pnpm dsh) splits @deepseek-ai/dsh-tools across src/lib — every tool call fails with "Cannot read properties of undefined (reading 'prepare')"

[LLKernel]

Summary

On 0.1.6-alpha.2, the documented source launch vector (pnpm dsh <app>, i.e. node --import tsx/esm apps/cli/src/bin.ts) boots normally, but the first turn that calls a tool ends with:

Cannot read properties of undefined (reading 'prepare')

recorded as turn/end with reason.kind: "error" and code: "UNKNOWN". From then on every tool call in that process fails — in new sessions and in pre-existing ones alike. The built launch (node apps/cli/lib/bin.js <app>) is unaffected.

Unlike #6529 / #6416 (a profile that owns a second physical copy of @deepseek-ai/dsh-tools) and #4508 (web mode, scope-proxy hypothesis), this reproduces on a single clean checkout with no version skew and no profile-local install: the source launch itself loads the package from two planes (src and lib), and the 0.1.6-alpha.2 resolution-default change made that split reach the tool path.

This is the same double-load phenomenon already documented for another package in #2091 ("Source launch loads workspace packages twice"), now fatal because @deepseek-ai/dsh-tools keys its scheduler by a module-private Symbol.

Environment

• @deepseek-ai/dsh 0.1.6-alpha.2, source checkout of master at ddefc45fbc
• Windows 11, Node v24.21.0, pnpm workspace install, pnpm install && pnpm run build completed
• profile web (default). Also reproduced with --profile headless in an isolated DSH_HOME
• Upgrade path that exposed it: checkout moved 0d1f50007f → ddefc45fbc (882 commits). Sessions before the update completed tool calls; the first tool-attempting turn after it failed (a text-only turn in the same process still completes).

Root cause

dsh-agent-loop reads the tool scheduler through a module-private symbol key:

// packages/core/agent-loop/src/tool-calls.ts:170
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)

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

Under the source launcher the process ends up with two module instances of @deepseek-ai/dsh-tools, so two distinct symbols exist. The loop imported one; ctx.tools was constructed from the other; the lookup is undefined and the property read throws.

Instrumented module.register load/resolve hooks in a single boot (paths relative to the checkout):

LOAD tools packages/core/tools/src/index.ts
LOAD tools packages/core/tools/lib/index.js
LOAD loop  packages/core/agent-loop/lib/index.js

RESOLVE @deepseek-ai/dsh-agent-loop -> packages/core/agent-loop/lib/index.js  << from apps/cli/node_modules/@deepseek-ai/dsh-base/package.json
RESOLVE @deepseek-ai/dsh-tools      -> packages/core/tools/lib/index.js      << from apps/cli/node_modules/@deepseek-ai/dsh-agent-instructions/package.json
RESOLVE file:///<checkout>/packages/core/tools/src/index.ts -> same            << from packages/core/agent-loop/lib/index.js

i.e. plugin entries are imported from the runtime anchor (lib/), while the tsx ESM hook re-projects the bare workspace specifiers made inside those lib files to src/ through tsconfig paths. Two planes in one process.

Symbol identity check from the same boot (symbols compared with ===, not by description):

{"tools": ["packages/core/tools/src/index.ts", "packages/core/tools/lib/index.js"],
 "loop":  ["packages/core/agent-loop/lib/index.js"],
 "loopSymbolFoundInTools": [["packages/core/tools/src/index.ts"]]}

which means the outcome depends on which copy registered the tools service — a load-order race. The same boot with the built entry (node apps/cli/lib/bin.js) loads exactly one copy (lib) and is stable.

Suspected trigger (regression in the pulled range)

#4471 / 9ddef327a4 ("feat: resolution mode link to runtime") changed the non-packaged default in apps/cli/src/profile-boot.ts:263:

-  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'link'
+  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'

Under link the loader resolves plugins by bare specifier, so tsx's paths projection keeps the whole graph on the src plane. Under runtime the resolution generation hands out runtime-anchor (lib) entries, and the two planes coexist. The desktop half of the same change was reverted before the release (d9a55c7c0d "fix: revert desktop"), the CLI half shipped in 0.1.6-alpha.2.

Reproduction (keyless, ~1 minute)

Uses the in-repo mock provider, so no API key is needed:

# 1. scripted model: one tool call, then a final text response
node --import tsx packages/test-support/llm-mock-server/src/bin.ts \
  --port 8125 --api-key mock-key --sequence tool_call_success,success --repeat-last \
  --tool-name pwsh --tool-arguments '{"command":"echo probe","description":"probe"}'

# 2. real source launch against it
mkdir -p /tmp/dsh-probe && printf 'llm-deepseek:\n  protocol: chat-completions\n' > /tmp/dsh-probe/settings.yaml
DSH_HOME=/tmp/dsh-probe DSH_TELEMETRY_DISABLED=1 \
DEEPSEEK_API_KEY=mock-key DEEPSEEK_BASE_URL=http://127.0.0.1:8125/v1 \
  node --import tsx/esm apps/cli/src/bin.ts --profile headless "run a probe"

Observed: dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare') on the tool-executing turn.

• In an isolated DSH_HOME this is intermittent (roughly 1 in 7 fresh boots; presumably the service-registration race).
• On the reporting checkout (profile web, users' normal pnpm dsh web) it was consistent: a text-only turn completed, the next tool-calling turn failed; a brand-new session failed on its first tool call as well.

What does not work as a workaround

Reverting the default to 'link' is not viable on 0.1.6-alpha.2 for an existing profile — the boot then fails outright:

dsh: startup failed: 1 required plugin did not activate
  agent-loop (required)
    Package: @deepseek-ai/dsh-agent-loop
    failed to import

Workaround that does work (verified): launch the built entry, i.e. pnpm run build once and then

node apps/cli/lib/bin.js web      # equivalent of `pnpm dsh web`

Secondary observation from the same default change

Plugins inserted through a profile patch that are not in the install-anchor closure now fail to import under runtime mode, where they used to resolve through tsx in a source launch:

dsh: warning: 2 entries did not activate
computer-use (@deepseek-ai/dsh-computer-use): failed to import
computer-use-cua-driver-native (@deepseek-ai/dsh-experimental-computer-use-cua-driver-native): failed to import

@deepseek-ai/dsh-computer-use exists in the tree but is not a dependency of apps/cli, so the runtime generation cannot route it. Installing them into the profile via the documented command restores them:

dsh plugin --profile web add @deepseek-ai/dsh-computer-use

CI gap

Nothing in the current gates covers the source launch's plugin plane:

• test:snapshot resolves workspace imports through vite + tsconfig paths (single plane);
• apps/cli/tests/built-bin.e2e.ts launches the built lib/ (single plane);
• apps/cli/tests/source-launch.compat.spec.ts only asserts the TTY refusal.

A gate that boots the source vector and asserts a single dsh-tools module instance (or that executes one tool call) would have caught this.

Suggested fixes

1. Keep the source launch on one plane. In a source launch the runtime generation should not import plugin entry files from lib while tsx re-projects their internal workspace specifiers to src — either route every workspace specifier through the same plane, or keep the tsconfig paths projection from applying to files under lib/.
2. Harden the seam. Symbol.for('@deepseek-ai/dsh-tools.scheduler'), or a string-keyed/Service-method scheduler, would make a duplicate instance degrade instead of taking down every tool call in the process (same suggestion as Idea: tool-scheduler prepare() failures are very hard to diagnose (Symbol mismatch invisible) #5758).
3. Fail loud at the access site. tool-calls.ts:170 could name the duplicate-instance cause instead of emitting a bare property-read TypeError (Idea: tool-scheduler prepare() failures are very hard to diagnose (Symbol mismatch invisible) #5758).

Related reports

• Source launch loads workspace packages twice, splitting the Typert @Remote registry - the gateway then skips the service silently #2091 — source launch loads workspace packages twice (dsh-typert-protocol, silent @Remote split): same root phenomenon, different consumer
• Tool calls crash with "Cannot read properties of undefined (reading 'prepare')" when a profile loads a second copy of @deepseek-ai/dsh-tools — TOOL_RUNTIME_SCHEDULER is a module-local Symbol() #6529 / [dsh] profile 内出现第二份核心包 → Symbol/instanceof 跨实例失效 → 工具派发崩溃（reading 'prepare'） #6416 — same prepare crash when a profile owns a second physical copy of dsh-tools
• Idea: tool-scheduler prepare() failures are very hard to diagnose (Symbol mismatch invisible) #5758 — diagnosability of prepare() failures; maintainer comment confirms the symbol-identity mechanism
• [Bug] Web mode tool execution fails: Cannot read properties of undefined (reading 'prepare') #4508 — same symptom in web mode (0.1.1-rc.2), scope-proxy hypothesis, unresolved

---

中文摘要：0.1.6-alpha.2 上，用文档里的源码启动方式（pnpm dsh web）时，@deepseek-ai/dsh-tools 会从 src 和 lib 两个平面各加载一份，两个模块私有的 Symbol('@deepseek-ai/dsh-tools.scheduler') 不相等，于是 ctx.tools[TOOL_RUNTIME_SCHEDULER] 为 undefined，任何工具调用都抛 Cannot read properties of undefined (reading 'prepare')。触发点是本版把非打包运行的 resolutionMode 默认值从 link 改成 runtime（#4471；desktop 那一半已在发版前回退）。临时可用办法是用构建产物启动（node apps/cli/lib/bin.js web）。

[LLKernel]

Follow-up after repairing this locally — one correction to my report, plus a verified fix.

Correction: link resolution is viable

My report said reverting the default to 'link' fails to boot (agent-loop (required): failed to import). That was wrong, and it was my own probe's fault: I appended an instrumentation snippet referencing TOOL_RUNTIME_SCHEDULER into every module my loader hook matched, including packages/core/agent-loop/src/index.ts, which does not declare that identifier. The resulting ReferenceError: TOOL_RUNTIME_SCHEDULER is not defined aborted that plugin import and looked like a resolution failure. With the probe fixed, both boots succeed:

• fresh isolated DSH_HOME, --profile headless, scripted mock tool call: the tool ran (pwsh, isError: false, output final-ok), turn completed, and the loader hook reports exactly one @deepseek-ai/dsh-tools and one @deepseek-ai/dsh-agent-loop, both from src/ — one module plane;
• existing web profile: dsh web boots and serves on 127.0.0.1 (HTTP 401 auth challenge).

So the pre-0.1.6-alpha.2 source-launch behavior was correct all along; the regression is only that runtime resolution put plugin entries on the lib plane while tsx kept re-projecting their workspace imports to src.

Local repair: pick the resolution mode by launch plane

apps/cli/src/profile-boot.ts — source launches resolve plugins through the profile's disk links (tsx owns every workspace specifier, single src plane); launches that run built lib/ throughout keep runtime resolution, which is the split #4471 wanted for plain Node launches (the desktop half was already reverted in d9a55c7c0d):

const SOURCE_LAUNCH = import.meta.url.endsWith('.ts')
const defaultResolutionMode: ProfileResolutionMode = SOURCE_LAUNCH ? 'link' : 'runtime'
const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? defaultResolutionMode

apps/cli/tests/resolved-profile-boot.spec.ts's default-mode row now asserts link, so flipping the default back to a blanket runtime fails that gate.

Verified after the change: pnpm exec tsc -b apps/cli/tsconfig.json clean, vitest run apps/cli/tests/resolved-profile-boot.spec.ts 16/16, and the two boots above (pnpm dsh web from source; node apps/cli/lib/bin.js web unchanged).

[LLKernel]

Second, distinct consequence of the same crash — a poisoned session history

Repairing an affected install turned up a follow-on defect: the crash does not just fail the turn, it makes the session unusable for every later turn. A turn that ends with an error has already appended the assistant message carrying its tool calls, while the results never arrive:

assistant/message (tool-call grep, tool-call pwsh)
tool/call (grep)              <- first call recorded as started
step/end
turn/end (error)              <- the crash

Every subsequent turn re-sends that history, and the provider protocol refuses it:

DeepSeek Messages tool calls need immediate results        (INVALID_REQUEST)
DeepSeek Messages history ends with unresolved tools

(packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:117)

interruptedTurnClosers does not close this shape: it repairs only an open final turn — it resets pending calls at every turn boundary — and the crashed turn did log its turn/end. Four sessions on this install were permanently broken, including turns started after the crash, which inherit the same history and fail before reaching the model.

What worked locally: truncate each log after the last tool/call of the damaged step so the built-in crash repair closes that turn on the next resume. Verified with the real serializer on the repaired logs — the original log is rejected with history ends with unresolved tools, the repaired log plus its appended closers serializes clean, with every tool call paired to a result. Only the failed turn's own artifacts are lost.

Suggested fix: when a turn ends with an error, synthesize results for its pending calls through the same closers path, so a crashed turn cannot poison the rest of a session.

[DreamStan]

Independent confirmation, on a different platform, plus one constraint on the fix space.

Environment: macOS arm64, Node v25.2.1, pnpm 11.7.0, master @ ddefc45fbc (0.1.6-alpha.2), clean pnpm install && pnpm run build, profile web launched with the documented source vector (node --import tsx/esm apps/cli/src/bin.ts web, cwd = repo root).

In-process probe of the booted profile (no model involved, so it cannot be a provider-protocol artifact):

check	result
ctx.tools[<lib-plane TOOL_RUNTIME_SCHEDULER>] !== undefined	true
ctx.tools[<src-plane TOOL_RUNTIME_SCHEDULER>] !== undefined	false
srcSymbol === libSymbol	false

The session log matches your report exactly: tool/call {name:"bash"} followed by turn/end with reason.kind:"error", code:"UNKNOWN", Cannot read properties of undefined (reading 'prepare'), then DeepSeek Messages tool calls need immediate results on every later turn.

Resolution matrix (what the loaded @deepseek-ai/dsh-tools resolves to, per importing context):

importer context	tsx paths active (current source launch)	paths disabled
packages/core/agent-loop/lib/index.js	packages/core/tools/src/index.ts	packages/core/tools/lib/index.js
apps/cli/package.json (install anchor)	…/src/index.ts	…/lib/index.js
~/.dsh/profiles/web/package.json	…/src/index.ts	…/lib/index.js

So tsx projects the bare specifier to src from every parent, while the runtime generation mounts the plugin tree from lib — the split is in the process, not in any one importer.

Constraint on the fix space: "disable tsx paths so everything is lib" does not work here. With TSX_TSCONFIG_PATH pointed at a paths-less tsconfig the plugin tree and the launcher graph do agree on lib, but the source launcher then fails at import time:

SyntaxError: The requested module '@deepseek-ai/cordis' does not provide an export named 'FiberState'

FiberState is a const enum (vendor/cordis/src/fiber.ts:147). tsc inlines it, so vendor/cordis/lib/index.js carries no runtime enum object and apps/cli/lib/profile-boot.js imports neither FiberState nor cordis. A source launch therefore must keep the src plane for the launcher's own graph, which rules out "route everything to lib" and supports your repair direction instead (source → link, built → runtime).

Also confirming your built-launch workaround on macOS: node apps/cli/lib/bin.js web boots and the scheduler symbol resolves (bare-symbol keyed: true), including with a profile that mounts third-party bundles.

[PerryLink]

Independent confirmation from Windows, in case a third platform helps pin this down.

Same commit ddefc45fbc, Node v22.22.3, pnpm 11.7.0, Windows 11, zero local modifications (git status --porcelain empty). Same symptom: the first tool call of the first turn dies with Cannot read properties of undefined (reading 'prepare').

I didn't have your loader-hook instrumentation, so I approached it by flipping a single line — apps/cli/src/profile-boot.ts:263 back to ?? 'link' — which gives a clean A/B on an otherwise untouched tree:

launch	resolutionMode	result
node --import tsx/esm apps/cli/src/bin.ts --profile headless "…read a file…"	runtime	exit 1 — dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')
same command	link	exit 0 — tool ran, answer printed
node apps/cli/lib/bin.js --profile headless "…"	runtime	exit 0 — unaffected

That's consistent with your LOAD tools src/index.ts + LOAD tools lib/index.js capture, and with your follow-up that link resolution is viable: with link the tool actually ran, on a single module plane.

The correction in your first comment deserves a highlight, by the way. It would have been easy to conclude "link doesn't boot" from a probe that was itself broken, and drop the one thing that actually fixes it. Glad you went back and checked.

[askdkc]

node apps/cli/lib/bin.js web

You are a lifesaver. Thanks!!

[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 已通过。详细补丁、用户恢复步骤、会话处理和回归门禁见上面的集中回复。

[TingDongHu]

One refinement to the resolution matrix above, plus a measured table from a third platform.

The discriminator is the importer's path, not the plane

tsx 4.22.4 applies the paths map only when the importing parent URL is not under node_modules/. From node_modules/tsx/dist/register-CKju0f8h.cjs (minified, resolveTsPaths) — it computes a value literally named fromNodeModules for its own log:

Oe=l(async(e,r,t,s)=>{const o=ne(e);if(n.logEsm(3,"resolveTsPaths",{specifier:e,context:r,
tsconfigPathAliasSpecifier:o,tsconfig:s.parsedTsconfig,
fromNodeModules:r.parentURL?.includes("/node_modules/")}),
o&&s.parsedTsconfig&&!r.parentURL?.includes("/node_modules/")){const a=n.wt(s.parsedTsconfig,e);...

This slightly changes how "tsx projects the bare specifier to src from every parent" reads: the three importers in that matrix (packages/core/agent-loop/lib/index.js, apps/cli/package.json, ~/.dsh/profiles/web/package.json) are all outside node_modules, so the exemption never shows up in it. The runtime generation, by contrast, mounts plugin entries with a parent inside it — per the RESOLVE lines in the report, apps/cli/node_modules/@deepseek-ai/dsh-base/package.json and apps/cli/node_modules/@deepseek-ai/dsh-agent-instructions/package.json. That is exactly the case the guard skips, so the split is not "tsx projects from every parent while the loader comes from lib" but "the loader's parents are the only importers tsx refuses to project".

It also explains why link repairs it: with disk links the loader resolves through the app's own graph, every parent is outside node_modules/, tsx projects the whole graph to src, and there is a single dsh-tools — consistent with the 16/16 spec assertion in the local repair above.

Same split, measured with a synchronous resolve hook (macOS, Node 24.16)

macOS 27.0 arm64, Node v24.16.0, pnpm 11.7.0, tsx 4.22.4, checkout ddefc45fbc, complete pnpm run build (typecheck exit 0), profile web. One boot under module.registerHooks({resolve}):

loader-driven plugin row imports (135 total)   -> all lib
  @deepseek-ai/dsh-tools       from apps/cli/node_modules/@deepseek-ai/dsh-agent-instructions/package.json -> packages/core/tools/lib/index.js
  @deepseek-ai/dsh-agent-loop  from apps/cli/node_modules/@deepseek-ai/dsh-base/package.json               -> packages/core/agent-loop/lib/index.js
static imports made from repo files            -> all src
  @deepseek-ai/dsh-tools       from packages/core/agent-loop/lib/index.js -> packages/core/tools/src/index.ts
  @deepseek-ai/dsh-util-values from packages/core/tools/lib/index.js      -> packages/util/values/src/index.ts

The last row is the one worth keeping in mind for the fix space: a file inside lib/ has its own static imports re-projected to src, so within a source launch "lib is the self-consistent plane" does not hold for importers that live in the repo.

Symbol creation sites, same two boots: source route 2 (packages/core/tools/src/index.ts:463, packages/core/tools/lib/index.js:2526), built route 1.

Probe gotcha for anyone re-running this: module.register()'s async hook is bypassed in this setup and reports 0 resolutions — the synchronous module.registerHooks() is the one that sees them. A 0-hit probe means the hook never ran, not that tsx took over.

Status today

origin/master is still ddefc45fbc and apps/cli/src/profile-boot.ts:263 still reads options.resolutionMode ?? 'runtime' (fetched 2026-09-20), so the CLI half of 9ddef327a4 is still as shipped and the source-link repair above remains the only remedy in the thread — the built-entry workaround keeps working.