Bug: tool calls fail with "Cannot read properties of undefined (reading 'prepare')" when running from source (pnpm dsh web)

[vanuska]

Environment

• dsh 0.1.6-alpha.2, run from a clean checkout (pnpm install && pnpm run build && pnpm dsh web)
• Node v24.19.0, Windows x64
• Reproduces on the very first tool call of any turn (also reproduced via pnpm dsh headless)

Symptom

Every turn that calls a tool fails. The UI shows the tool card as "Interrupted: interrupted", then the turn ends with:

This turn failed: Cannot read properties of undefined (reading 'prepare') (code UNKNOWN).

The failing site is packages/core/agent-loop/src/tool-calls.ts:170:

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

Root cause

When dsh boots from source, its packages end up loaded twice in the same process:

• the vendored plugin loader (vendor/loader/src/config/tree.ts) resolves plugin packages through real package resolution → packages/*/lib/index.js;
• bare-specifier imports made from those loaded files fall through to tsx, which applies the paths aliases from tsconfig.base.json → packages/*/src (source copies).

TOOL_RUNTIME_SCHEDULER is declared as a plain Symbol('@deepseek-ai/dsh-tools.scheduler'). The ToolRuntime instance is constructed by one module copy and the agent-loop reads the scheduler with the other copy's symbol, so ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined.

Fix

Registering the symbol in the global symbol registry makes both copies agree:

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

Verified locally: with this one-line change, headless runs execute tools and complete normally.

[JimChen]

It works. thanks.

[xhd2015]

Also reproduced here (macOS, Node 24, source launch). @vanuska's dual-load diagnosis is right, and Symbol.for is a working workaround. Adding the regression origin and a resolver-level fix that removes the dual load instead of teaching the two copies to share one symbol.

Regression origin

9ddef327a4 ("feat: resolution mode link to runtime", 2026-09-17) changed the source-launch default in apps/cli/src/profile-boot.ts:

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

With link, no profile resolver is installed, so every plugin import goes through tsx's paths map and everything loads from src/ — one copy of each package. With runtime, the profile resolver (packages/boot/app-boot/src/profile-resolution/resolver.ts) resolves fallback packages from the declarer recorded in the generation. For this install that declarer is a symlink under apps/cli/node_modules/:

• tsx skips the repo paths map for an importer under node_modules, so the tools service resolves @deepseek-ai/dsh-tools to packages/core/tools/lib/index.js;
• the agent loop file (packages/core/agent-loop/lib/index.js) is not under node_modules, so its bare import still goes through paths to packages/core/tools/src/index.ts.

Two copies → two TOOL_RUNTIME_SCHEDULER symbols → ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined → .prepare throws. That is why this only started failing on source launches after 2026-09-17; packaged builds do not use tsx, so both sides stay on lib/.

Resolver-level fix

realpath the fallback declarer before handing it to Node's resolver, at three sites: the ESM routedParent, the CommonJS anchor, and the CommonJS resolveRouted fallback:

// packages/boot/app-boot/src/profile-resolution/resolver.ts
function fallbackDeclarer(declarer: string): string {
  return realpathSync(declarer)
}

const routedParent = pathToFileURL(route.kind === 'fallback'
  ? fallbackDeclarer(route.entry.declarer)
  : route.parent).href

apps/cli/node_modules/@deepseek-ai/dsh-agent-instructions/package.json canonicalizes to packages/context/agent-instructions/package.json, which is outside node_modules, so tsx applies paths and both sides land on src/. In a built launch (no tsx) the real parent still follows exports to lib/ for both sides, so built behavior is unchanged.

Unlike Symbol.for, this keeps a single copy of each package in the process. Verified locally on a source launch; the profile-resolution suite passes (63 tests, including a new symlinked-declarer case).

Upstream status

origin_official/master at ddefc45fbc (merge of PR #4469) still contains 9ddef327a4 and still passes the raw declarer through in resolver.ts (ESM fallback route at line 693, CommonJS anchor at line 792), so this is not fixed upstream yet. The only later commit touching those files, 0ea890044f, covers the runtime default in tests and docs.

[dsh-community-assistant[bot]]

Thanks for the report.