[Bug] 0.1.6-alpha.2 — the tsx source launch evaluates two copies of @deepseek-ai/dsh-tools, so every tool call fails with Cannot read properties of undefined (reading 'prepare')

[paichato]

Summary

Booting the CLI through its source entry (pnpm dsh web, i.e. node --import tsx/esm apps/cli/src/bin.ts web) while a profile's plugin rows resolve through node_modules to built lib/ puts two copies of @deepseek-ai/dsh-tools in one process. TOOL_RUNTIME_SCHEDULER is a module-scoped unique symbol used as a lookup key, so each copy produces its own symbol: the agent loop holds one, the mounted tools service carries the other, the lookup yields undefined, and every tool call ends its turn with Cannot read properties of undefined (reading 'prepare'). Booting the built entry (node apps/cli/lib/bin.js web) resolves both sides to lib/ and the failure disappears.

Environment

• macOS (darwin, arm64), Node v22.22.0
• dsh 0.1.6-alpha.2, commit 90d2af322e (merged from tag dsh-v0.1.6-alpha.2)
• profile web, with local .mjs plugins in the profile directory that register tools through defineTool from @deepseek-ai/dsh-tools
• built artifacts were fresh (every packages/*/*/lib/index.js newer than its source) — this is not build staleness

Reproduction

Both commands run from one directory, packages/core/agent-loop, which depends on @deepseek-ai/dsh-tools exactly as a profile plugin row does:

cd packages/core/agent-loop
node --input-type=module -e "const a = await import('@deepseek-ai/dsh-tools'); const b = await import('<repo>/packages/core/tools/lib/index.js'); console.log(a.TOOL_RUNTIME_SCHEDULER === b.TOOL_RUNTIME_SCHEDULER)"
# -> true   one copy: the specifier resolves through node_modules to lib/

node --import tsx/esm --input-type=module -e "<same expression>"
# -> false  two copies: tsx's `paths` map the specifier to src/index.ts

The same probe is saved at ~/.gena/gerados/ferramentas/dsh-scheduler-identity-probe.mts (run it as node --import tsx/esm <file> tsx / node <file> node).

Current behavior

Under the source entry, the first tool call of a turn fails:

turn/end  reason: { kind: "error",
                    error: { message: "Cannot read properties of undefined (reading 'prepare')",
                             code: "UNKNOWN" } }

Observed twice in a real session (2026-09-19 02:20:39 and 02:31:28 CAT); the tool call never executed. The dereference site is packages/core/agent-loop/src/tool-calls.ts:170:

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

Expected behavior

A tool call issued through the source launch executes normally, exactly as it does through the built entry.

Root cause

• TOOL_RUNTIME_SCHEDULER is exported from packages/core/tools/src/index.ts (line 463) as a unique symbol and carried as a property of the registry, so the loop and the service must share one module instance for the key to match.
• Under tsx, @deepseek-ai/dsh-* specifiers resolve through tsconfig.base.json paths to packages/*/*/src/index.ts; profile plugin rows are imported by resolved path and load packages/*/*/lib/.
• Two module instances ⇒ two symbols ⇒ ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined.

Why the test suite does not catch it

Unit tests run under vitest, where every workspace specifier resolves to src/ — one copy, one symbol. The failure only appears in a real boot that mixes the source and artifact planes.

Workaround

Launch the built entry instead of the source entry:

node <repo>/apps/cli/lib/bin.js web

Note that README.md:41 states "pnpm run build prepares the repository artifacts. pnpm dsh web uses those built artifacts without rebuilding" — a rebuild is required after updating the monorepo either way.

Suggested directions (not prescriptive)

1. Let one plane win for the whole process under the source launch: resolve plugin rows through the same paths mapping instead of node_modules → lib/.
2. Or reach the scheduler through the service interface rather than a module-scoped symbol, so identity cannot diverge by construction.
3. At minimum, fail loud at boot when the symbol is absent, instead of surfacing it as a mid-turn error coded UNKNOWN.

Notes

• I did not test --profile headless; the same condition applies whenever the CLI boots through tsx while its plugin rows resolve through node_modules.
• Two distinct failures followed this version upgrade: first stale lib/ artifacts (the composer and other UI components did not activate), then this symbol split. Both are resolved by dps-down && pnpm run build && dps-up.

[argszero]

Your mechanism is right: two copies of @deepseek-ai/dsh-tools in one process, TOOL_RUNTIME_SCHEDULER is Symbol(...) (a plain symbol, packages/core/tools/src/index.ts:463 — the description string is only a decoy), the agent loop holds one key and the mounted tools service carries the other, and tool-calls.ts:170 dereferences undefined. Your deref-site citation is exact.

What I can add is the trigger, because it is narrower than "tsx's paths map the specifier to src/index.ts" — that mapping has been there for a long time. What changed is the default resolution mode of the source launch, in a two-line commit:

$ git show 9ddef327a4 --stat --format='%h %ci %s'
9ddef327a4 2026-09-17 20:08:51 +0800 feat: resolution mode link to runtime
 apps/cli/src/profile-boot.ts   | 2 +-
 apps/desktop-host/src/index.ts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

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

It carries exactly one tag: dsh-v0.1.6-alpha.2 — the version you are on. apps/cli/src/profile-boot.ts:263 is still ?? 'runtime' at HEAD.

Why that line is what puts two copies in one process

resolutionMode gates two things, and they are what make the planes meet or miss:

// :210 — which generation the profile's plugin rows resolve through
const resolution = resolutionMode === 'runtime' || resolvedProfile !== undefined
  ? await createProfileResolutionGeneration(resolutionOptions)
  : await healProfilesModuleFallback(resolutionOptions)

// :312 — and whether that generation is enforced on the loader
await hostCtx.plugin(PluginPackages, resolutionMode === 'link' ? {} : {
  generation: composed.resolution,
  behavior: resolutionMode === 'dual' ? 'verify' : 'enforce',
})

Under runtime the loader enforces the runtime generation on every profile plugin row, which is what sends them to lib/. Under link the loader is handed no generation at all and the profile's node_modules links are healed first — that is the plane your own process is running on. So the flip is precisely the switch between "one plane" and "two planes".

The part I would weigh most: the author reverted the other half themselves

$ git show d9a55c7c0d --stat --format='%h %ci %s'
d9a55c7c0d 2026-09-17 20:47:27 +0800 fix: revert desktop
 apps/desktop-host/src/index.ts | 2 +-

Thirty-nine minutes after 9ddef327a4, the same author reverted only apps/desktop-host/src/index.ts, back to process.argv[5] === 'runtime' ? 'runtime' : 'link' (apps/desktop-host/src/index.ts:21 today). The apps/cli half was left flipped. That is the strongest evidence available that the ?? 'runtime' default is wrong — the person who wrote it judged it wrong and rolled it back on one of the two carriers — and it also tells you where the regression boundary is: on the parent of 9ddef327a4, your probe should print true for the tsx case. That is a cheap check and it would confirm the whole chain.

There is no escape hatch from the CLI

apps/cli/src/bin.ts:38 calls runProfile without resolutionMode, and there is no flag or environment variable for it (grep for resolution under apps/cli/src outside profile-boot.ts returns nothing). options.resolutionMode is a library-level option, so an embedding host that calls runProfile directly — the desktop — can pass it; the CLI cannot. Running the built entry is the whole workaround set.

On the fix

Reverting :263 to ?? 'link' is one line and restores the pre-regression behavior, but it is presumably not what the commit wanted: link mode routes through healProfilesModuleFallback, which materializes the fallback mirror under $DSH_HOME/profiles/node_modules (mkdir + symlink writes, under a cross-process file lock, whenever moduleFallbackCurrent says it is not current — packages/boot/app-boot/src/profile.ts:571-584). Trading a two-plane boot for a disk write on launch is a real trade, not a revert.

The narrow fix for this specific failure is to make the key itself cross-plane:

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

I checked whether that is sufficient or merely cosmetic, and for this key it is sufficient: dsh-tools holds no module-level mutable state — its only module-level exports are that symbol and two string constants (TOOL_ABORTED, TOOL_ABORTED_BEFORE_DISPATCH) — and every piece of scheduler state is a field of the registry instance, with readonly [TOOL_RUNTIME_SCHEDULER] (:798) built from arrow closures that bind that instance. So a shared key lands both planes on the same live object and the same state. unique symbol still typechecks on Symbol.for(...).

The honest cost: that removes your symptom without restoring the invariant those two planes exist to hold (one package identity per process). Two module instances would remain, holding different code, so a version skew between src/ and lib/ would go from a loud crash to a silent one. It fixes this key, not this class.

Both of these are upstream changes. This is not mountable as a plugin: the dereference throws before any tool/result is emitted, so a plugin never sees the failure to react to, and the undefined read is inside the agent loop's own graph. Worth knowing so nobody spends time on a plugin-shaped workaround.

Finally, for the record on duplicates: #7146 (posted three hours earlier) and #7126 are the same signature, and #7128 independently landed on the same commit. Your report is the most precise of them — the probe, the built-vs-source contrast, and "not build staleness" are what make it diagnosable.

[paichato]

Your trigger analysis checks out from this side, line by line, and there is one claim in it I have to push back on.

Confirmed: 9ddef32 touches only apps/cli/src/profile-boot.ts and apps/desktop-host/src/index.ts, one line each, and dsh-v0.1.6-alpha.2 is the only tag containing it. profile-boot.ts:263 is still packaged ? 'runtime' : options.resolutionMode ?? 'runtime' at HEAD and at origin/master (ddefc45). d9a55c7, 39 minutes later from the same author, restores only the desktop half; desktop-host:21 today is the argv-based default. And there is no CLI escape: resolutionMode appears nowhere under apps/cli/src outside profile-boot.ts, and bin.ts:38 calls runProfile without it.

The correction is the cheap check you proposed. "On the parent of 9ddef32, your probe should print true for the tsx case" does not hold, and I measured it instead of arguing it: the probe compares two imports made from packages/core/agent-loop and never loads profile-boot.ts, so nothing in that commit can move its result.

$ cd packages/core/agent-loop
$ node --import tsx/esm --input-type=module -e "..."
a resolves to:  file:///.../packages/core/tools/src/index.ts
b is:           /.../packages/core/tools/lib/index.js
identity equal: false

What the commit changes is which plane the profile's plugin rows are loaded from the fallback declarer anchor under node_modules against the source-side anchor - and the probe exercises neither. Confirming the regression boundary means booting, or replaying the keyless gate, on the parent commit, which needs a build, so I have not done it. I am flagging it as the one step your reply asserts and my evidence does not carry.

One nuance on Symbol.for sufficiency: the conclusion is right, but "no module-level mutable state" is slightly strong, there is also SDK_RENDERERS, a module-scope Record at packages/core/tools/src/index.ts:54. Read-only, and it holds no scheduler state, so your point stands; I am just recording that the exported surface is not the whole module.

On the fix: your reply predates my report by about half an hour, so for completeness, this tree applies both directions. 02f86e631b canonicalizes the fallback anchor at packages/boot/app-boot/src/profile-resolution/resolver.ts:693 (canonicalPath already lives in that file) while keeping the runtime default, so a source launch keeps one module plane that is the invariant half your "honest cost" paragraph leaves unrestored. 4aa2c5a884 is the Symbol.for change you recommend, kept for the HMR and second-physical-copy paths it also covers. The keyless gate measured red then green here: DSH_SNAPSHOT=replay pnpm run test:snapshot -t bash-tool-turn (1 failed, 161 skipped, about 2.4 s, then 1 passed), plus 48 files / 1087 tests across packages/boot/app-boot, packages/core/tools and packages/core/agent-loop, and a clean tsc -b.

And for the record on duplicates: agreed, #7146 and #7128 came first, and #7048 is the one that made the mechanism readable at all. Yours is what turned it from a mechanism into a commit boundary.

[paichato]

Independent cross-check on macOS, plus the fix that is running in this tree.

Environment: macOS arm64, Node v22.22.0, dsh 0.1.6-alpha.2 (90d2af322e), profile web with local .mjs plugins that register tools through defineTool.

Reproduced from one directory - packages/core/agent-loop, which depends on @deepseek-ai/dsh-tools exactly as a plugin row does:

node --input-type=module -e "const a = await import('@deepseek-ai/dsh-tools'); const b = await import('<repo>/packages/core/tools/lib/index.js'); console.log(a.TOOL_RUNTIME_SCHEDULER === b.TOOL_RUNTIME_SCHEDULER)"
# -> true    built entry: one copy

node --import tsx/esm --input-type=module -e "<same expression>"
# -> false   source entry: the specifier is a second copy beside lib/

The keyless gate reproduces the failure end to end in ~2.5 s: DSH_SNAPSHOT=replay pnpm run test:snapshot -t bash-tool-turn exits 1 with UNKNOWN: Cannot read properties of undefined (reading 'prepare') before the fix, and passes after it. pnpm dsh and pnpm dsh web fail the same way; node apps/cli/lib/bin.js web never did.

Fix applied here, in the direction #7048 documents (two commits):

1. packages/boot/app-boot/src/profile-resolution/resolver.ts:693 - canonicalize the fallback anchor (canonicalPath(route.entry.declarer)), keeping the runtime default. The delegating resolve no longer names a path under node_modules, so the loader's source projection applies to plugin rows exactly as it does to the CLI, and both sides share one module instance.
2. packages/core/tools/src/index.ts:463 - TOOL_RUNTIME_SCHEDULER uses Symbol.for('@deepseek-ai/dsh-tools.scheduler'). This does not remove duplication; it keeps the remaining paths (HMR re-evaluation, a profile carrying a second copy) from taking every tool call down.

Verification: gate red -> green; vitest run packages/boot/app-boot packages/core/tools packages/core/agent-loop = 48 files / 1087 tests; tsc -b clean; the keyless snapshot suite is usable again as a source-launch signal.

One detail worth folding into the fix: per #7048, a source launch with no lib/ at all resolves that anchor to apps/cli/node_modules/@deepseek-ai/dsh-tools/lib/index.js and fails as ERR_MODULE_NOT_FOUND, so the source plane is unhealthy in both states today.