Cannot read properties of undefined (reading 'prepare') — root cause and one-line patch

[gool-zz]

Filing this as a bug report and a working patch, since I've hit it repeatedly and traced it to a specific Symbol identity problem in @deepseek-ai/dsh-tools.

Symptoms

Every tool call fails immediately with:

Cannot read properties of undefined (reading 'prepare')

The failure happens on the first tool call after boot. Every session in that Host process is affected. Restarting DSH does not fix it. Removing plugins does not fix it. Cleaning node_modules and reinstalling does not fix it.

The session history is left with an orphaned tool_calls block and no matching tool result. After that, every subsequent message fails with 400 INVALID_REQUEST because the tool-call protocol is violated.

Root cause

packages/core/tools/src/index.ts defines the tool runtime scheduler key as a module-local Symbol:

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

When two physical copies of @deepseek-ai/dsh-tools exist in the same Node process — which happens whenever any profile-local plugin declares it as a regular dependency instead of a peerDependency — each copy evaluates that line separately and creates a different Symbol object. The description string is identical, but the runtime values are not equal:

Symbol('x') !== Symbol('x') // true

The Agent loop looks up the scheduler using the host copy's Symbol. The ToolRuntime registered itself under the profile copy's Symbol. The lookup returns undefined, and calling .prepare() on it crashes.

Why Symbol.for() fixes it

Symbol.for(key) uses the global symbol registry. No matter how many copies of the module exist, they all call Symbol.for('@deepseek-ai/dsh-tools.scheduler') and receive the exact same Symbol object back. The lookup matches and .prepare() succeeds.

The patch

import os, re, shutil

p = os.path.expanduser('~/deepseek-harness/packages/core/tools/src/index.ts')

with open(p) as f:
    content = f.read()

shutil.copy(p, p + '.bak')
content = re.sub(
    r"Symbol\(['\"]@deepseek-ai/dsh-tools\.scheduler['\"]\)",
    "Symbol.for('@deepseek-ai/dsh-tools.scheduler')",
    content
)

with open(p, 'w') as f:
    f.write(content)

Then rebuild:

cd ~/deepseek-harness
pnpm run build

That's it. The patch survives until the next git checkout of the source tree, so it needs to be reapplied after each DSH upgrade.

Verified

· DSH 0.1.6-alpha.2
· Node v22.23.2
· macOS arm64
· Reproduced with a profile containing plugins that declare @deepseek-ai/dsh-tools as a regular dependency
· Patch resolves the crash immediately and permanently for the current version

Related issues

This has been reported by other users with the same prepare crash, but the Symbol mismatch has not been identified as the root cause elsewhere. Linked reports:

· Various issues in the plugin ecosystem where profile-local plugins break all tool calls

Suggested upstream fix

Change the Symbol declaration to use Symbol.for() permanently:

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

This is a one-line change, has no behavioral downside, and makes the key resilient to duplicate module instances. Plugins that incorrectly declare host packages as dependencies will no longer be able to break the tool runtime.

[WQMYH]

Confirmed on a third platform/config, with one practical addition.

Environment

• Windows 11 (build 26200, x64)
• DSH 0.1.6-alpha.2, master@ddefc45fbc (2026-09-17)
• Launch path: source entry (package.json script dsh = node --import tsx/esm apps/cli/src/bin.ts, i.e. pnpm dsh web), profile web

Reproduction
First tool call in a fresh session fails: UNKNOWN: Cannot read properties of undefined (reading 'prepare'). The session event log ($DSH_HOME/sessions/<proj>/session-<id>/session.v3.jsonl.zstd) shows assistant/message → tool/call → turn/end(kind=error, ... 'prepare'), with no command/run event — the command never started.

Second-order effect (why re-prompting cannot recover the session)
The aborted call leaves an assistant tool_calls with no matching tool result, so every later turn is rejected:

turn/end → INVALID_REQUEST: DeepSeek Messages tool calls need immediate results

It reproduced on 3 consecutive user turns in that session, and a brand-new session hits the same prepare crash. Clearing the session is the only recovery.

Practical addition: no rebuild needed
Patching only packages/core/tools/src/index.ts requires pnpm run build (and the split src/lib graph means the running face matters). Patching both faces makes the fix effective immediately:

• packages/core/tools/src/index.ts: Symbol('@deepseek-ai/dsh-tools.scheduler') → Symbol.for(...)
• packages/core/tools/lib/index.js: Symbol("@deepseek-ai/dsh-tools.scheduler") → Symbol.for(...)

Verification (loading two independent copies of the module and comparing the symbol, which is exactly the failing condition):

original  : TOOL_RUNTIME_SCHEDULER === TOOL_RUNTIME_SCHEDULER (2nd copy) -> false
patched   : -> true

node --check packages/core/tools/lib/index.js passes; git status shows only the tracked src/index.ts edit (since lib/ is gitignored), so a one-file git apply-able patch can be re-applied after each upgrade.

[Sheldondxx]

Confirmed on Linux with the released 0.1.6-alpha.2 (master@ddefc45fbc), with one addition that may widen the blast radius beyond profile-local plugin dependencies.

Environment: Ubuntu (kernel without Landlock), x64, Node v22.23.2, pnpm 11.7.0, fresh pnpm install && pnpm run build.

What we observed: the dual load happens even with zero profile-local plugins. Under the documented source launch (pnpm dsh web, i.e. node --import tsx/esm apps/cli/src/bin.ts), tsx's tsconfig-paths hook redirects every bare @deepseek-ai/dsh-tools import to packages/core/tools/src/index.ts — including imports from built lib/*.js artifacts. The Cordis plugin loader, however, imports plugin entries by file URL (new URL(name, baseUrl) in vendor/loader/src/config/tree.ts), which bypasses paths mapping, so the composition's ToolRuntime comes from lib/index.js. Result: agent-loop (running from lib/) holds the src copy's TOOL_RUNTIME_SCHEDULER Symbol while the registered ToolRuntime instance carries the lib copy's — same description string, different identity.

Runtime probe inside startCall (packages/core/agent-loop/lib/index.js):

ctx.tools.constructor.name === 'ToolRuntime'
ctx.tools instanceof (imported ToolRuntime) === false
Object.getOwnPropertySymbols(ctx.tools) contains a symbol described '@deepseek-ai/dsh-tools.scheduler'
(TOOL_RUNTIME_SCHEDULER in ctx.tools) === false

So in a source checkout with build outputs present (the normal dev state after pnpm run build), the documented pnpm dsh entry point breaks every tool call, not just exotic compositions.

Workaround that fully unblocks us: skip the tsx source launch and run the built CLI directly — node apps/cli/lib/bin.js web. Single module plane, tool pipeline works.

The Symbol.for(...) patch in the OP would fix the identity split, but the mixed src/lib evaluation still looks worth closing at the resolution layer (e.g. loader resolving through the same paths mapping, or the source launch failing fast when lib/ is present).

[dsh-community-assistant[bot]]

Thanks for the report.