Fix: profile resolution loads dsh-tools twice under tsx dev mode, breaking every tool call

[jimmyfreecoding]

Bug report with fix: pnpm dsh web breaks every tool call ("Cannot read properties of undefined (reading 'prepare')")

Symptoms: Since 0.1.6-alpha.2 (PR #4471), running the CLI in dev mode (pnpm dsh web, i.e. node --import tsx/esm apps/cli/src/bin.ts) makes every tool call fail with TypeError: Cannot read properties of undefined (reading 'prepare') at packages/core/agent-loop/src/tool-calls.ts:170, regardless of model or tool. Built mode (node apps/cli/lib/bin.js web) works.

Root cause (confirmed by an instrumented boot of the web profile): The new runtime profile resolution routes profile-scoped requests to the declaring package's anchor as the native resolution parent. That anchor is found by walking pnpm's node_modules symlinks (packageDirFromAnchor), so it contains symlink segments (e.g. apps/cli/node_modules/@deepseek-ai/dsh-acp-app/package.json). tsx's resolver (resolveTsPathsSync) keys its tsconfig-paths rewriting off the parent URL and treats parents under node_modules as external packages, skipping the rewrite. The routed request therefore resolves @deepseek-ai/dsh-tools to the built packages/core/tools/lib/index.js, while in-tree imports (agent-loop etc.) resolve to packages/core/tools/src/index.ts. The package loads twice, TOOL_RUNTIME_SCHEDULER (a unique symbol) splits, and ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined — hence the crash on every tool call.

Fix (3-line change): canonicalize the fallback declarer (realpath) before using it as the native resolution parent, in the ESM and CJS fallback paths of packages/boot/app-boot/src/profile-resolution/resolver.ts. Node realpaths parents internally, so default resolution results are unchanged; only the parent URL visible to loader hooks changes.

Verification:

• Repro plugin inside the booted tree: before the fix the slot read via the src module's symbol was undefined; after the fix all probed parents resolve to src/index.ts and the slot is populated.
• Added a regression test in packages/boot/app-boot/tests/profile-resolution.spec.ts (spies the native resolver and asserts the canonical declarer parent; verified it fails without the fix).
• Existing suites pass: profile-resolution.spec.ts (63), profile-resolution-service.spec.ts, profile-resolution-worker-bootstrap.spec.ts, profile.spec.ts, app-boot.spec.ts (132 total).

PRs are disabled on this repository, so the fix is available at:
https://github.com/jimmyfreecoding/deepseek-harness/commits/fix/profile-resolution-canonical-declarer
(commit e522d99e47, cherry-pickable onto master)

[argszero]

Your diagnosis holds, and I can confirm the mechanism from a different direction — from the resolver's own data model rather than from the tsx interaction. Four additions: where the symlinked parent comes from, why the default (not just the symlink) is implicated, what the fix touches beyond the parent URL, and the thread cluster this belongs to.

Verified against master @ ddefc45fbc.

1. The symlinked parent is recorded by contract, and one builder already canonicalizes the anchor it doesn't record

ProfileResolutionEntry.declarer is documented (packages/boot/app-boot/src/profile.ts:98-99) as "Manifest whose dependency edge selected this package" — i.e. the parent package's manifest path, not a canonicalized one. It is populated from the edge-walk parent:

links.set(dep, dir)
declarers.set(dep, next.anchor)          // profile.ts:504  — the parent's manifest path
...
queue.push({ anchor: manifestPath, manifest })   // :508

Under pnpm that parent is exactly the anchor you instrumented (apps/cli/node_modules/@deepseek-ai/dsh-acp-app/package.json), and the resolver later hands it to the loader as the native resolution parent — pathToFileURL(route.entry.declarer).href at resolver.ts:693, :792, :829. So the symlinked-parent premise is not incidental to the reproduction; it is baked into the entry contract.

What makes this look like an oversight rather than a design choice: the other builder in the same file does canonicalize the anchor, immediately before walking it —

const canonicalAnchor = join(realModuleDirectory(dirname(anchor)), basename(anchor))  // profile.ts:683

realModuleDirectory is the repo's canonicalization helper (legacy-links.ts:22-24: isPackagedExecutable() ? realpathSync(path) : realpathSync.native(path)), and profile.ts already imports it (:45). The asymmetry is that the root anchor is canonicalized for manifest reading while the recorded declarer for each edge stays symlinked. Two suggestions while you are in there: canonicalize via realModuleDirectory rather than a fresh fs.realpathSync (it keeps the packaged/native distinction the rest of the resolution code uses), and consider whether the declarer should be canonicalized where it is recorded (profile.ts:504 / :704 / :708) instead of at each consumption site — same defect, one place.

2. The default is implicated, and the author already reverted half of it

The line that made this reachable is one character:

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

9ddef327a4 ("feat: resolution mode link to runtime", imccyu, 2026-09-17 19:52:33 +0800, tagged dsh-v0.1.6-alpha.2) flipped the fallback in two carriers — apps/cli/src/profile-boot.ts and apps/desktop-host/src/index.ts. Fifty-five minutes later the same author reverted only the desktop half: d9a55c7c0d ("fix: revert desktop", 20:47:27). Current HEAD reflects that split:

carrier	HEAD today
apps/cli/src/profile-boot.ts:263	options.resolutionMode ?? 'runtime'
apps/desktop-host/src/index.ts:21	process.argv[5] === 'runtime' ? 'runtime' : 'link'

Two consequences worth having on the record. First, there is no way to select link/dual from the CLI: apps/cli/src/bin.ts:38 never passes resolutionMode, and no flag or environment variable exists (ProfileResolutionMode = 'link' | 'dual' | 'runtime', profile.ts:117, is reachable only as a programmatic option). So a user hitting this cannot even bisect it without editing source — the fix's availability matters more than it would if a switch existed. Second, a maintainer already treated this default as wrong on one surface; that is an argument for fixing the default as well as the anchor, since canonicalizing the declarer only addresses the tsx manifestation, not the "one package identity per process" invariant the resolution mode is supposed to preserve.

3. Blast radius: declarer is not only an ESM parent

Worth checking before you land it, because the name undersells what it feeds:

• CJS: it becomes the synthetic module's filename (new cjs(anchor), resolver.ts:792) and the base for search paths — packageSearchPaths returns cjs._nodeModulePaths(dirname(entry.declarer)) (:250, :254).
• Restart guard: sameResolution already canonicalizes both sides through canonicalPath (:281-286, :124-131), so the requires a process restart comparison at :306 is symlink-insensitive and will not be perturbed — that part is safe by construction, and it also means the codebase already treats a declarer as symlink-tolerant identity.

The CJS half is where I would add an assertion: with the anchor canonicalized, _nodeModulePaths(dirname(anchor)) walks the real package's ancestors rather than the symlinked ones, which under pnpm is a different chain. A routed CJS require that currently resolves a dependency through the symlinked ancestor could change target. Your note that "Node realpaths parents internally, so default resolution results are unchanged" is true for the ESM default resolve path; I would not extend it to the CJS synthetic parent without a test.

4. Complementary hardening, if you want defence in depth

TOOL_RUNTIME_SCHEDULER is export const … : unique symbol = Symbol('@deepseek-ai/dsh-tools.scheduler') (packages/core/tools/src/index.ts:463), and the crash site indexes it (agent-loop/src/tool-calls.ts:170). Making it Symbol.for('@deepseek-ai/dsh-tools.scheduler') removes the split key entirely: Symbol.for type-checks under the existing unique symbol annotation (tsc --strict passes untouched), and dsh-tools keeps no module-level state besides that symbol — all runtime state is instance fields, so a shared key lands on one instance and one state. The honest cost: the loud TypeError becomes silent version divergence between planes, so this is hardening for identity, not a substitute for fixing resolution. (TOOL_ABORTED_BEFORE_DISPATCH is a plain string and createExecutionToken's symbol never crosses planes, so the scheduler key is the only cross-plane identity in that package.)

5. This signature is not new — 11th thread, three launch surfaces

Same Cannot read properties of undefined (reading 'prepare') with no tool/result in the log has been reported across at least ten earlier threads over eight days (#7106, #7107, #7108, #7117, #7126, #7128, #7136, #6967, and the earlier #1337/#1486 family), spanning pnpm dsh, packaged dsh, dsh web, plus Windows and PM2 launches. Two notes for whoever triages: your "built mode works, dev mode breaks" observation is the correct discriminator to standardize on, and at least one of those threads misattributed the identical crash to "the implementation is missing / not packaged" and went off to change packaging — a package that is installed and working in one launch mode cannot be a packaging omission.

Thanks for including the fork commit (e522d99e47) — since PRs are disabled here, that is the only carryable form of the fix, and naming the regression test you added (verified failing without it) is what makes it reviewable.