[Bug] 0.1.7-rc.1 no longer heals $DSH_HOME/profiles/node_modules (0.1.6 did) — profiles with locally installed plugins break every child process: run_code and voice input die with "subprocess scope exited before its bootstrap consumed the launch request"

[kaijia323]

Symptom

On 0.1.7-rc.1, a profile that has plugins installed into the profile (what dsh plugin add / Settings → Plugins produces) still works for chat, but every tool call and voice input fails:

Error: code run failed (worker-exit): subprocess scope exited before its bootstrap consumed the launch request
Captured output:
Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@deepseek-ai/cordis'
  imported from <profile>/node_modules/@deepseek-ai/dsh-subprocess/lib/index.js

Voice input fails with the same seam error (语音识别失败：subprocess scope exited before its bootstrap consumed the launch request).

Environment: dsh 0.1.7-rc.1 (pnpm global install), node v24.21.0, pnpm 12.3.4, Linux.
Profile dependencies: @deepseek-ai/dsh-base, dsh-web-app, dsh-experimental-agent-team-profile, dsh-experimental-voice-input-bundle.

Finding 1 — the shared fallback the peers resolve through is stale

Per #5863, autoInstallPeers: false is intentional: profile-local plugins are supposed to resolve peers through the shared installation fallback at $DSH_HOME/profiles/node_modules, via Node's ordinary parent-walk.

On this machine that directory exists but is dead — every entry is a symlink into the 0.1.6 pnpm store generation, which the CLI upgrade garbage-collected:

$ find ~/.dsh/profiles/node_modules -xtype l | wc -l
493

$ ls -l ~/.dsh/profiles/node_modules/@deepseek-ai/cordis
... -> ~/.local/share/pnpm/global/v11/569-18d58149f7e02921-0/node_modules/.pnpm/\
      @deepseek-ai+dsh@0.1.6-alpha.1_f31d87c7…/node_modules/@deepseek-ai/cordis
$ ls ~/.local/share/pnpm/global/v11/569-18d58149f7e02921-0   # gone

So Node walks up from <profile>/node_modules/... into profiles/node_modules, finds only dangling links, and throws.

Finding 2 — 0.1.6 created/healed that fallback; 0.1.7-rc.1 only removes it

dsh-app-boot 0.1.6:

/** Heal one module-fallback generation while the cross-process writer lock is held. */
function healProfilesModuleFallbackLocked(entries, modulesDir) { … }
function ensureSymlink(link, target) { … symlinkSync(target, link, "junction"); }
// exported: createProfileResolutionGeneration, healProfilesModuleFallback

dsh-app-boot 0.1.7-rc.1:

$ grep -rl symlinkSync <installation tree>/@deepseek-ai/    # no hits
$ grep -n 'healProfiles\|createProfileResolutionGeneration' dsh-app-boot/lib/index.js   # no hits

What remains is removal and read-only inspection: removeLinkProjections() (unlinks old .dsh-module-fallback projections), linkedProfileRoots(), realModuleDirectory(). Meanwhile initProfile() still writes the unchanged PROFILE_PNPM_WORKSPACE:

nodeLinker: hoisted
autoInstallPeers: false

Result: nothing maintains the fallback any more, so a profile-local plugin install has no resolvable peers — and #5863's "the peers are not actually missing" reasoning no longer holds for this case.

Finding 3 — why the UI survives and only child processes die

• Main process: createRuntimeResolution() builds an in-memory resolution map (installation closure + profile closure, installation package names reserved), so plugins load and chat works.
• Child processes: the PTC run_code worker and the speech-to-text worker are plain node processes with no such map. runnerEnvironment() even deletes NODE_* / TSX_* from the environment, so NODE_PATH cannot compensate. First import '@deepseek-ai/cordis' on the profile path kills the process → the scope exits before its bootstrap consumes the launch request.

Both affected features go through ctx.subprocess.spawn (dsh-ptc-runtime-node worker; dsh-experimental-speech-to-text-sensevoice line ~638), which is why the failure is uniform.

Finding 4 — clean-room reproduction (no legacy state)

$ export DSH_HOME=/tmp/dsh-repro
$ dsh web --from-default-profile web --dump-config        # profile created, "dependencies": {}
$ dsh plugin --profile web add @deepseek-ai/dsh-experimental-voice-input-bundle
[WARN] Issues with peer dependencies found. Run "pnpm peers check" to list them.
+ @deepseek-ai/dsh-experimental-voice-input-bundle 0.1.7-alpha.1

$ cd $DSH_HOME/profiles/web && pnpm peers check
Issues with peer dependencies found
✕ missing peer @deepseek-ai/cordis
  Wanted: ^4.0.3: @deepseek-ai/dsh-experimental-voice-input-bundle@0.1.7-alpha.1, …
✕ missing peer @deepseek-ai/dsh-api-gateway
✕ missing peer @deepseek-ai/dsh-api-remotes

$ node --input-type=module -e "import('$PWD/node_modules/@deepseek-ai/dsh-experimental-speech-to-text/lib/index.js')"
Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@deepseek-ai/cordis'
  imported from …/profiles/web/node_modules/@deepseek-ai/dsh-experimental-speech-to-text/lib/index.js

So this is reachable with the official install path alone; the legacy 493-link tree was only masking it.

Workaround that restored the machine (verified)

Set autoInstallPeers: true in <profile>/pnpm-workspace.yaml and run pnpm install (30 peer packages, all 0.1.7-rc.1 / cordis 4.0.4, same versions as the installation tree). Verified afterwards:

• the previously failing import succeeds in a plain node process
• a full dsh-subprocess-local Linux scope + runner bootstrap test succeeds end-to-end (launch request consumed, exit 0, child import OK)
• dsh --profile web --dump-config: exit 0 / empty stderr; app boots with zero errors

This does not break the single-instance invariant from #5863: collectProfileScopePackages passes the installation package names as reserved to dependencyClosure, so the profile's cordis copy is never put into the main process's resolution map (and both copies are 4.0.4).

Suggested fix

Either restore the fallback maintenance that 0.1.6 had (healProfilesModuleFallback, run while holding the profile writer lock, plus a one-time heal for existing profiles whose links point at a dead store generation), or make the profile install actually install the peers it reports as missing. Right now the removal of the former makes autoInstallPeers: false fatal for every profile that installs a plugin, including the two official optional bundles.

[argszero]

Thanks — this is the most complete report I have read on this seam, and every load-bearing claim in it holds up. I re-derived the mechanism from the released artifacts rather than from your machine (I do not have your state), so what follows is independent evidence plus three additions.

Confirming Finding 2 from the published export surfaces

Diffing the published @deepseek-ai/dsh-app-boot tarballs (0.1.6-alpha.2, the last published 0.1.6, vs 0.1.7-rc.1):

• 0.1.6 exported the writer: healProfilesModuleFallback, healProfilesModuleFallbackLocked, healProfileModuleFallback, healIsolatedProfileModuleFallback, unlinkProfileModuleFallback, createProfileResolutionGeneration.
• 0.1.7-rc.1 exports none of them. It grew createRuntimeResolution, removeLinkProjections, prepareProfileEntries, prepareProfilePatches, plus the compatibility surface.

So it is not a lost call site — the whole writer was retired, and the retirement is deliberate: createRuntimeResolution's own docstring is

Compute the runtime resolution without writing module-resolution files. (packages/boot/app-boot/src/profile.ts:402)

and the comment sitting next to autoInstallPeers: false was updated to match it (profile.ts:201-203):

The hoisted linker gives out-of-tree plugins a flat node_modules whose missing peers (cordis and friends) use the runtime resolution, so every plugin shares the installation's single cordis instance instead of a duplicate.

That comment is the precise answer to your "#5863's reasoning no longer holds" sentence: the reasoning still holds for the process that mounts plugins, and the retirement assumed the runtime table could stand in for the disk fallback everywhere. It stands in everywhere except where your Finding 3 points.

Why the child processes lose it (the carrier inventory)

The runtime resolution has exactly two carriers, and both are in-process:

1. installRuntimeInterception(resolution) — loader hooks for the process that owns them (profile-resolution/service.ts:69).
2. registerWorkerResolution(resolution) — resolver.ts:917-923, i.e. worker_threads.setEnvironmentData('@deepseek-ai/dsh-app-boot/profile-resolution', …), consumed by worker-bootstrap.ts:1-8. Its docstring names the audience exactly: "Install the inherited runtime resolution in one Harness-owned Worker", and PluginPackages.replace's says "…for this process and subsequently created Workers".

A ctx.subprocess.spawn child is neither. ptc-runtime-node/src/index.ts:236 and speech-to-text-sensevoice/src/recognizer.ts:262 both go through the subprocess seam, and that seam leaves no slot for a resolution — two independent closures:

• the env door is shut on purpose: RUNNER_CONTROL_ENV_PREFIXES = ['NODE_', 'TSX_'] (subprocess-local/src/runner-launch.ts:23) and runnerEnvironment() deletes every name matching it (:78-84). Your NODE_PATH observation is that code, not an accident.
• the private parent→runner vocabulary has no field for it either: LinuxLaunchRequest / WindowsStartRequest carry cwd, env, control and nothing else (subprocess-local/src/runner-protocol.ts). The "target overrides arrive through request/IPC" comment in runnerEnvironment is about the target's own environment, and nothing fills that channel with a resolution.

So the child resolves the Node way, walks up into the shared fallback, and no carrier is left to make that walk succeed.

One addition to Finding 1: there are two sub-cases, not one

removeLinkProjections (profile.ts:242-252, called from loadProfile at :704) unlinks only <profile>/node_modules entries that point into <profile>/.dsh-module-fallback/node_modules, then removes that directory. It never touches <home>/profiles/node_modules. So on 0.1.7 the shared fallback is unowned in both directions: nothing writes it, nothing deletes it.

• upgraded machine (yours): the directory survives as 493 links into a dead store generation — permanent residue that no code path will refresh or clean;
• machine that never ran 0.1.6 (your clean room, and mine): the directory simply does not exist, so the parent-walk ends at <profile>/node_modules.

Both fail identically, which is why your Finding 4 reproduces from "dependencies": {} plus one bundle. The practical consequence for a fix: an one-time "re-heal profiles whose links are dead" would close your box and leave the fresh-install case open — case (b) needs a creator, not a healer. (The 493-link residue itself is your environment observation; I could not check it here and am flagging it as unverified on my side.)

Your workaround is sound, and here is the mechanism that says so

collectProfileScopePackages (profile.ts:513-524) passes the installation's package names into dependencyClosure as reserved (:473-478, const visited = new Set(reserved)), so a profile-local copy can never enter the main process's table for a name the installation owns. autoInstallPeers: true therefore gives the children real peers on disk to walk into while leaving the installation's single cordis in charge of the process that mounts plugins. That also means the versions carry more weight than the setting: as long as both trees agree (your 4.0.4 on both sides), the divergence costs nothing.

Two notes on the suggested fix

• The shape of a re-heal matters: the case-(a) residue is 0.1.6-shaped, and not all of it was symlinks — ensureModuleProxy wrote synthetic package directories (dsh.moduleFallback.targets + generated entry-N.js re-exports) and refused to touch a path it had not created. A healer that can no longer produce that shape has to decide what to do with the entries that have it.
• If the intended answer is "the runtime resolution is the fallback", then the missing piece is a child-process carrier, and the seam that would carry it is the one that deliberately refuses to carry anything (NODE_*/TSX_* strip plus the closed runner protocol). Delivering the resolution to the target would have to survive that boundary on purpose. That reads less like a regression to patch and more like: autoInstallPeers: false was safe only while the disk fallback existed.

I am tracking this on the plugin side as well — the failure shape is the same as the one in the Windows ACL thread: a working UI sitting on top of a dead execution path, where the only visible symptom is a tool that silently is not there.

[argszero]

The diagnosis above now has a shipped implementation, for anyone who hits this and does not want to change their install:

@argszero/cordis-plugin-profile-fallback-advisor@0.1.0 — https://www.npmjs.com/package/@argszero/cordis-plugin-profile-fallback-advisor (source: https://github.com/argszero/cordis-plugin-profile-fallback-advisor)

One-line usage — install it into the profile and mount it:

cd ~/.dsh/profiles/<profile> && pnpm add @argszero/cordis-plugin-profile-fallback-advisor

# either through Settings → Plugins, or by adding to the profile's cordis.patch.yml
- insert:
    - id: profile-fallback-advisor
      name: '@argszero/cordis-plugin-profile-fallback-advisor'
      config:
        repair: false

It is a stopgap, not the fix — the fix belongs upstream (restore the writer, or tell the child about the resolution). What it does:

• On boot, it runs the same upward walk a child process performs (<profile>/node_modules → $DSH_HOME/profiles/node_modules → $DSH_HOME/node_modules) for every name the profile's locally installed packages require, and logs the verdicts and the limits of the scan, so a quiet start and a scan that never ran do not look alike.
• On the first recognized child-process failure, it attaches one durable user-role message to the failing tool result naming the package, the importer, what the walk found at each level, and the two options the user owns. The model reads it beside the failure rather than only in a log it never sees, and it says plainly that retrying cannot help.
• Optionally (repair: true, off by default), it links the installation's own copies into $DSH_HOME/profiles/node_modules — the directory 0.1.7 neither writes nor deletes, so nothing else is writing there. That write is strictly additive: it recreates/refreshes links on every boot, replaces only a dangling symlink or a dsh-managed module proxy, reports anything else for a human instead of removing it, never touches the profile's pnpm-owned node_modules, and never links a name whose copy exists nowhere. It covers both shapes of an upgraded machine: a directory full of dangling links from 0.1.6, and no such directory at all.

The two remedies it hands the user are the ones already in this thread: autoInstallPeers: true + pnpm install in the profile (the plugin mounts keep using the installation's single cordis, because the installation's names stay reserved), or the repair above. Both need a dsh restart. What does not help is in the advisory too: retrying, NODE_PATH (the subprocess runner deletes it before launch), and proxy/routing changes.

What it deliberately does not claim, so nobody is surprised later: it does not inject a resolution into the child (every carrier was checked and is closed — NODE_*/TSX_* are deleted and the runner protocol has no resolution field), it does not replace the subprocess service (one implementation per service, and that would displace the sandboxed local provider), its scan covers only the top level of the profile's node_modules (the hoisted shape), and it recognizes only Node's ESM rendering of the miss — a CommonJS Require stack: block is left alone, so a CJS-only package missing a peer keeps the bare error.

Verified with 74 tests across four suites (the classifier's refusals, the walk on a real tree in both sub-cases, the repair's additive invariants, and the mount on a real dsh-tools ToolRuntime through tools/post-execute), plus 11 defect-injection arms — 10 caught, 1 recorded as equivalent with its reason. The failure path is platform-neutral, so it is exercised on a real tree rather than on Windows.

[kaijia323]

Thanks for the teardown — and for the correction on framing. "The writer was retired on purpose, and the runtime table was assumed to cover the disk fallback everywhere" is the accurate statement, and the thing it misses is exactly ctx.subprocess.spawn children. I've updated my model accordingly.

Two data points that may be useful:

1. 0.1.7-rc.2 does not change any of this. Checked on the tree the CLI actually runs from, and on the profile's own copy of dsh-app-boot@0.1.7-rc.2:

$ grep -rl healProfilesModuleFallback <tree>/@deepseek-ai/     # no hits
$ grep -rl symlinkSync              <tree>/@deepseek-ai/        # no hits
$ grep -n 'without writing module-resolution' dsh-app-boot/lib/index.js
726: * Compute the runtime resolution without writing module-resolution files.
$ grep -A 5 '^const PROFILE_PNPM_WORKSPACE' dsh-app-boot/lib/index.js
const PROFILE_PNPM_WORKSPACE = `packages:
  - .

nodeLinker: hoisted
autoInstallPeers: false
`;

So on rc.2 the stopgap is still the only remedy that does not change the install (the alternative being autoInstallPeers: true + pnpm install in the profile, which is what I applied here, and which survives the rc.2 upgrade and a subsequent plugin install).

2. On the residue shape (you flagged it as unverified on your side): I only have my earlier records — that tree was cleaned up during the rc.2 upgrade on this machine, so I cannot add the dsh.moduleFallback.targets evidence you were interested in. What I recorded at the time: 493 symlinks, all dangling, all pointing into the garbage-collected global/v11/569-… generation (@deepseek-ai+dsh@0.1.6-alpha.1_…), and the only non-symlink top-level entries were the @scope directories. Consistent with symlink-only residue for the 0.1.6 → 0.1.7 path, but I cannot rule out nested proxies.

Confirming your case (b) from the clean room as well: neither of the throwaway DSH_HOMEs I created ever had profiles/node_modules, so "a creator, not a healer" matches what I see.