Source-launch resolution-mode default 'runtime' mixes src/lib module planes: every tool call fails with Cannot read properties of undefined (reading 'prepare')

[githubxzw]

Summary

In a source workspace (running pnpm dsh web through the tsx source launch), every agent turn that executes a tool fails with:

Cannot read properties of undefined (reading 'prepare')

The failure starts with commit 9ddef327a4 ("feat: resolution mode link to runtime"), which flipped the non-packaged CLI default resolution mode from link to runtime. That puts two module instances of @deepseek-ai/dsh-tools in one process (one src/, one lib/), and the tool scheduler slot — keyed by a Symbol() — only exists under the other copy's symbol.

This violates the repo's own "Source plane vs artifact plane, never mixed" rule for source launches. Packaged installs are unaffected (single lib/ plane). CI does not catch it because gates run against one consistent plane.

Environment

• Source workspace at ddefc45fbc (0.1.6-alpha.2 line), pulled across 0d1f50007f..ddefc45fbc (882 commits, includes 9ddef327a4)
• macOS arm64, Node 26.7.0, launch command pnpm dsh web (node --import tsx/esm apps/cli/src/bin.ts)
• Web profile with third-party plugins (not required for the failure)

Reproduction

1. Check out any revision at or after 9ddef327a4, pnpm install && pnpm run build.
2. pnpm dsh web and send any message that triggers a tool call.
3. The turn ends with reason.kind: "error" and the message above, right after the assistant emits a tool call.

Durable session-log timeline from my workspace (same session, same machine):

turn  1..7   09-17 13:43–17:41  completed   (before the pull)
turn  8      09-18 11:00        error  Cannot read properties of undefined (reading 'prepare')
turn 10      09-18 11:10        error  Cannot read properties of undefined (reading 'prepare')

Root cause

apps/cli/src/profile-boot.ts:

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

In runtime mode the loader resolves each plugin's directory on disk and loads its built lib/ entry by file path (consistent with stack frames pointing at packages/client/connection/lib/index.js in a source launch). But tsx still applies tsconfig paths to bare-specifier imports made from those lib/ files. So:

• The tools plugin entry is loader-loaded from packages/core/tools/lib/index.js, and its ToolRuntime class field is keyed by that copy's TOOL_RUNTIME_SCHEDULER = Symbol('@deepseek-ai/dsh-tools.scheduler') (symbol A).
• agent-loop's built bundle keeps from "@deepseek-ai/dsh-tools" external (peer dep), so its import is tsx-redirected to packages/core/tools/src/index.ts — a second module evaluation with its own Symbol() (symbol B).
• ctx.tools[TOOL_RUNTIME_SCHEDULER] read at tool-calls.ts:170 (prepare(call.exec)) is undefined. String-keyed methods on the same service (ctx.tools.executionMode(...), line 89) work fine, which is why turns stream normally and only tool dispatch crashes.

Probe

From any file in the repo:

$ node --import tsx/esm -p "import.meta.resolve('@deepseek-ai/dsh-tools')"
file:///…/packages/core/tools/src/index.ts        # bare name → src plane everywhere

Importing the same specifier vs. the lib file directly:

bare === lib : false                               # two evaluations, two Symbols

Suggested fixes

1. Minimal: restore the source-launch default to 'link' (keep runtime for packaged launches). One-line revert of the default.
2. Deeper: make runtime mode a true artifact plane — loader-controlled resolution that bypasses tsconfig paths for plugin entries and their inter-package imports, so src can never meet lib in one process.
3. Hazard-class fix: key cross-package service slots through something that survives duplicate module instances (Symbol.for or string registry keys) instead of per-evaluation Symbol()s.
4. Orthogonal: expose resolutionMode as a CLI flag — today there is no way to opt out without patching source.

Workaround

Local, uncommitted patch (what I am running now):

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

After restarting, tool execution works again; lib/ staleness also stops mattering for source launches.

[coldxiangyu163]

Your analysis matches what we reproduced independently: after 9ddef327a4 flipped the non-packaged default to runtime, a source workspace holds both planes. One mechanism detail worth adding — the profile fallback resolves its ESM request from a declaring manifest that, under pnpm, is a symlinked node_modules/.../package.json; tsx skips the tsconfig paths projection for parentURLs containing /node_modules/ (tsx@4.22.4), so the plugin side lands on package exports (lib/) while the CLI side lands on src/.

Minimal fix (normalize that anchor to its real path, keep Node/tsx owning exports and hooks), regression tests, and A/B plus end-to-end verification are in #7048. Unlike reverting the default to link, this keeps runtime mode single-plane for source launches.