A second copy of the core packages in a profile makes every tool call fail with "Cannot read properties of undefined (reading 'prepare')"

[sashabogi]

Setup: @deepseek-ai/dsh 0.1.0-rc.7 from npm, node 26.3, macOS (arm64).

If a profile's node_modules ends up holding a second copy of the core packages, boot succeeds and tool-free turns answer normally, but every turn that calls any tool (native or MCP) exits 1 with only this:

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

Sometimes it prints after the final answer and the exit code flips between runs, which makes it look like a teardown race. It isn't, it's deterministic on tool use.

How you get there naturally: hit the missing-peer error from installing dsh-hooks-claude-code (reported separately: #3515), then "fix" it by running plain npm install inside the profile. npm 7+ auto-installs peers, so the profile gains its own copies of dsh-agent, dsh-tools, dsh-session, dsh-code-runtime and friends alongside the ones in the dsh installation.

What seems to happen: the loader mounts some plugins against one module instance of the core and some against the other, so the tool runtime scheduler is registered under one instance's key and read back under the other. ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...) (agent-loop/src/tool-calls.ts) then reads prepare off undefined on the first tool call.

Fix on our side: reinstall the profile with pnpm and autoInstallPeers: false, matching the shipped template. Everything works after that, we verified a full agent run with native tools plus an MCP server.

Suggestion: a boot-time invariant that detects a core package present in both the installation tree and the profile tree and fails loud naming both paths. The current error points nowhere near the cause, and we burned a while bisecting it (first suspected env vars, then our own SessionStart hook, both wrong).

[ylwl1997]

This matches a classic “two copies of the framework in one Node module graph” failure: the profile boots, plain chat works, but tool calls blow up with Cannot redefine property / duplicate package identity because require resolves different physical copies of @deepseek-ai/*.

Practical mitigation until upstream hardens resolution:

1. Inspect .../profiles/<name>/node_modules/@deepseek-ai and the parent CLI’s node_modules — if the same package name appears in both trees with different realpaths, that’s the bug.
2. Prefer installing only plugins into the profile; avoid dsh plugin adding core packages (dsh-base, dsh-tools, …) a second time.
3. Nuke the profile node_modules + lockfile and re-add only the third-party plugins you need.

If you can paste npm ls @deepseek-ai/dsh-tools (or the package named in the error) from inside the profile, we can confirm the duplicate path pair.

[sashabogi]

Confirmed your duplicate-copy theory, with the broken profile preserved as evidence. node_modules/@deepseek-ai inside the profile held the whole core at the bridge's ancient peer range while the CLI tree runs the current generation:

dsh-tools    profile=0.0.1-rc.5   cli-tree=0.1.0-rc.8
dsh-session  profile=0.0.1-rc.5   cli-tree=0.1.0-rc.8
dsh-agent    profile=0.0.1-rc.5   cli-tree=0.1.0-rc.8

So it's two copies AND two generations. npm pulled them in as auto-installed peers of dsh-hooks-claude-code@0.0.1-rc.5, which is what the stale latest tag hands you (details in #3515).

One correction for anyone matching symptoms: the error here is exactly Cannot read properties of undefined (reading 'prepare') on the first tool call, not Cannot redefine property. Tool-free turns answer normally, which is what makes it look like a teardown race until you bisect on tool use.

Your mitigation list matches what fixed it for us: profile installs only the plugins, via pnpm with autoInstallPeers: false, and pin the plugin versions to the CLI's. A boot-time duplicate-core check that names both realpaths would have saved us the whole hunt.

[denial123789]

I traced the exact rc.8 identity boundary (141eb6f), which confirms why equal versions do not make this safe.

@deepseek-ai/dsh-tools declares:

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

The Agent loop imports that key and calls ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...). Two physical module instances create different local Symbols (A ≠ B), even if name, version, and bytes match. If ToolRuntime registers under A and agent-loop reads with B, the first tool call deterministically gets undefined; model-only chat never touches the scheduler and therefore passes.

rc.8's intended profile topology reinforces the report's recovery: generated workspace config sets autoInstallPeers: false, and app-boot maintains a flat $DSH_HOME/profiles/node_modules fallback linking installation-owned app/bundle dependencies. Out-of-tree plugins should reuse that Host core closure rather than materializing their own peers.

For an upstream invariant, I would compare canonical realpaths from both the Host and importing-plugin resolution anchors and report package/version/importer/expected/actual paths before Session creation. It should inspect nested plugin copies, while avoiding false positives when multiple symlink paths canonicalize to the same physical file.

I would not solve this only by changing to Symbol.for() or optional-chaining the scheduler. That can hide this lookup while service classes, context augmentation, registries, instanceof, and other module identities remain split—or silently skip every tool.

I wrote a transactional recovery and invariant-design runbook with native + MCP + restart gates here:

• Visual diagnosis: https://sandbaseai.github.io/deepseek-harness-handbook/duplicate-core-runtime.html
• Full runbook: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/duplicate-core-runtime-closure.md

[ylwl1997]

Confirmed on both counts — thanks @sashabogi for keeping the broken profile as evidence, and @denial123789 for the identity boundary.

The user-facing recipe is narrower than the unique-symbol internals:

1. Do not let @deepseek-ai/dsh-* core packages exist as real copies under ~/.dsh/profiles/<name>/node_modules. That tree is for third-party plugins only.
2. When adding the Claude Code hooks bridge, pin to the CLI generation (see dsh-hooks-claude-code cannot be installed out-of-tree: dsh-hook-protocol is an unsatisfiable peer dependency #3515) so latest cannot drag rc.5 core in as peers.
3. If the profile is already poisoned: stop DSH, delete profiles/<name>/node_modules (or at least node_modules/@deepseek-ai), then reinstall only the third-party plugins with version pins. A matching version in both trees is not enough once two physical copies are loaded.

#3557 is the same dual-copy split arriving through dsh plugin add + pnpm hoist, just diagnosed from the kScope side.