[Fixed in 0.1.7-alpha.1] Dev source launch (pnpm dsh) fails every tool call with "Cannot read properties of undefined (reading 'prepare')" — resolutionMode 'runtime' default mixes src/lib module planes

[iinlanjian]

Summary

On current master, every dev source launch of dsh (pnpm dsh <profile> ...) fails on every tool call with:

Cannot read properties of undefined (reading 'prepare')

The turn ends with reason: { kind: 'error', code: 'UNKNOWN' } before any tool executes. It is not escalation/sandbox-specific — even a plain bash call like git status crashes. GUI sessions (web profile) show the turn failing with UNKNOWN.

Reproduction (keyless, clean tree)

pnpm install && pnpm run build        # as documented
pnpm run test:snapshot -t bash-tool-turn

Note the snapshot suite run without DSH_EXAMPLE_MODE (i.e. the default src launch mode). It fails:

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

The same crash hits any real run, e.g. pnpm dsh --profile headless "task" or pnpm dsh web — every tool call dies before dispatch.

Root cause: two module planes in one process

dsh source launch runs through tsx (node --import tsx/esm apps/cli/src/bin.ts). Every package's leaf tsconfig extends tsconfig.base.json, whose paths map resolves workspace bare imports to src/. So a module loaded from lib/ still resolves its workspace imports into src/.

Since #4471 (commit 9ddef327a4, "feat: resolution mode link to runtime"), the profile loader resolves plugin entries in 'runtime' mode through built artifacts (package.json exports → lib/). The result is two executions of @deepseek-ai/dsh-tools in one process:

• the tools service instance is constructed from packages/core/tools/lib/index.js;
• agent-loop's static import { TOOL_RUNTIME_SCHEDULER } from '@deepseek-ai/dsh-tools' binds the copy compiled from packages/core/tools/src/index.ts.

Two Symbol(...) calls with the same description are not ===. In agent-loop/src/tool-calls.ts:170:

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

ctx.tools is the lib-constructed ToolRuntime, which owns the lib-copy symbol, so the lookup with the src-copy symbol is undefined and every tool call throws. Instrumenting the bundles confirms it:

[registry] [
  'file:///…/packages/core/tools/src/index.ts sameAsImported=true',
  'file:///…/packages/core/tools/lib/index.js sameAsImported=false'
]
// ctx.tools own symbols contain a same-description symbol whose .prepare IS a function;
// the imported binding's lookup is undefined

Introduced by

9ddef327a4 — the default changed:

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

Verified causally: reverting only that one default back to 'link' on the same tree makes bash-tool-turn, bash-startup-timeout, and fs-edit snapshot replays pass again.

Why the gates miss it

scripts/run-gates.ts runs the snapshot suite with DSH_EXAMPLE_MODE: 'lib' (pure artifact plane — no mixing, passes). The plain developer flow (pnpm dsh …, or pnpm run test:snapshot without the env override) runs in src mode and crashes.

Suggested fix

Either:

1. restore the 'link' default for non-packaged launches (verified working), or
2. keep 'runtime', but make the source launch single-plane — e.g. have runtime-mode plugin resolution go through the same resolution the importing modules use, or prevent tsconfig-paths resolution for specifiers that the loader resolves through artifacts (identity-sensitive seams like TOOL_RUNTIME_SCHEDULER, class identity, and branded types otherwise break).

Environment

• master @ ddefc45fbc (v0.1.6-alpha.2)
• macOS (Darwin 25.6.0, arm64)
• node v25.3.0, pnpm 11.7.0

[iinlanjian]

Update — fixed, verified on 0.1.7-alpha.1.

The fix landed as 335c5cbe26 — "fix(cli): keep source profile imports in one module graph" (included in the 0.1.7-alpha.1 release, c36a83ff6b). Its commit message matches this report's diagnosis exactly: in a tsx source launch, profile resolution loaded both packages/core/tools/src/index.ts and packages/core/tools/lib/index.js, so the ToolRuntime instance and the agent-loop consumer held different private TOOL_RUNTIME_SCHEDULER symbols and the first tool call failed reading scheduler.prepare.

What changed:

• The TypeScript CLI entry now explicitly selects linked profile resolution based on its own .ts module identity; built and packaged launches keep runtime resolution. No service or symbol identity was widened to conceal duplicate module instances.
• The gate gap from this report is closed too: sourceImport is forwarded through runLoaderSmoke and headless source snapshots now select tsx/esm, so the snapshot suite actually exercises the src-plane launch.

Verified locally on a clean tree at c36a83ff6b (pnpm install && pnpm run clean && pnpm run build):

pnpm run test:snapshot -t bash-tool-turn        # passed
pnpm run test:snapshot -t bash-startup-timeout  # passed
pnpm run test:snapshot -t fs-edit               # passed

All three previously failed in default (src) mode on ddefc45fbc. Thanks for the quick turnaround!

[iinlanjian]

Follow-up: the crash window of this bug also left durable log damage (dangling tool/call rows inside closed steps). The v3→v4 read-time migration refuses such sessions; analysis and an accepted repair shape posted in #7617.