[Bug] latest (0.1.5-rc.2) fails to boot on a clean install: dsh-sandbox-local is not resolved

[Danerus23]

What happens. On a clean machine (Node 24.21.0, npm 11.19.0):

npm i -g @deepseek-ai/dsh
dsh web --no-open --port 3090

Error: dsh: plugin tree failed to load: dsh: plugin(s) failed to load:
@deepseek-ai/dsh-sandbox-local; Cordis startup failed because these plugin(s)
could not be resolved (see the error(s) logged above)

The server never comes up. On machines where the packages were installed earlier it works fine.

Why. The latest tag points to dsh@0.1.5-rc.2. That release declares its dependency @deepseek-ai/dsh-base with the range ^0.1.5-rc.2, so npm resolves it to the already published 0.1.5-rc.3. With dsh-base@0.1.5-rc.3 the package @deepseek-ai/dsh-sandbox-local is no longer hoisted to the top level of node_modules and stays nested inside dsh-base\node_modules\@deepseek-ai\, so the profile loader cannot see it.

install	dsh	dsh-base	dsh-sandbox-local	result
@deepseek-ai/dsh (= latest)	0.1.5-rc.2	0.1.5-rc.3 (floated)	nested	does not boot
@deepseek-ai/dsh@0.1.5-rc.3 (= next)	0.1.5-rc.3	0.1.5-rc.3	hoisted	boots

The package itself is intact: import '@deepseek-ai/dsh-sandbox-local' from the profile directory succeeds — what is missing is reachability from the top level.

Reproduction.

1. Windows, clean machine (no previous dsh installation), Node 24.21.0 with npm 11.19.0
   (also reproduced with npm 12.0.2 on the same layout).
2. npm i -g @deepseek-ai/dsh
3. dsh web --no-open --port 3090

Running it again on the same profile reproduces the same error — this is not a first-run-only issue.

Scope of what was checked. This was reproduced with npm global installs on Windows
(a fresh prefix every time). I have not tried pnpm or macOS/Linux, so I cannot say whether
the layout resolves differently there — with pnpm the tree is laid out differently and the
symptom may not appear.

Related. #7256 reports
the same mechanism (a stale transitive dependency shadowing the needed copy) but caused by a
third-party plugin installed into a profile. Here nothing third-party is involved: the drift
happens inside dsh's own dependencies, on the latest tag, so it affects every fresh install.
#5106 covers the underlying
fragility — one plugin that fails to resolve takes down the whole plugin tree instead of being
isolated.

What would fix it.

1. Move the latest tag to a self-consistent release (0.1.5-rc.3 boots), or pin the dependencies of 0.1.5-rc.2 to exact versions — the ^0.1.5-rc.2 range currently allows a newer prerelease and breaks the layout.
2. Declare @deepseek-ai/dsh-sandbox-local as a direct dependency of dsh, so npm hoists it to the top level regardless of how the other packages are laid out.

[d2kx]

Same here. Fresh install on Windows, does not work at all.

[Danerus23]

Thanks for confirming — that matches what I see.

One more thing I found while narrowing this down, which may explain "does not work at all" on a fresh machine: dsh builds the profile's plugins with pnpm, not npm. Its own help says so:

Commands:
  plugin [options] [args...]  manage a profile's plugins by forwarding the
                              remaining arguments to pnpm in the profile directory

npm i -g @deepseek-ai/dsh does not install pnpm. On a clean machine without pnpm I get, on every start, hundreds of lines like:

Error: failed to import loader entry llm (@deepseek-ai/dsh-llm):
Cannot find package '@deepseek-ai/dsh-llm' imported from C:\Users\<user>\.dsh\profiles\web\

With pnpm present (npm i -g pnpm), the very same build (0.1.5-rc.3, same fresh DSH_HOME) boots on the first try, with zero "Cannot find package" lines.

So on a clean Windows box there seem to be two separate things stacked on top of each other:

1. the latest-tag / nested dsh-sandbox-local problem from the first post, and
2. the profile never being prepared because pnpm is missing.

Could someone confirm whether pnpm is expected to be a prerequisite here? If it is, it would be worth saying so in the install docs (or having npm i -g @deepseek-ai/dsh pull it in), because right now a fresh install has no pnpm and the web profile does not come up.

[argszero]

I reproduced this on a clean macOS box with the versions you name, and the mechanism in the first post does not hold there: the nesting is real, but it is not what stops the loader. Details and a way to test it on your machine.

The tag and the float are exactly as you describe

$ npm view @deepseek-ai/dsh dist-tags --json
{ "latest": "0.1.5-rc.2", "next": "0.1.5-rc.3", "alpha": "0.1.7-alpha.2" }

$ npm view "@deepseek-ai/dsh-base@^0.1.5-rc.2" version --json
[ "0.1.5-rc.2", "0.1.5-rc.3" ]

$ npm view @deepseek-ai/dsh@0.1.5-rc.2 dependencies --json | grep -c sandbox-local
0

dsh@0.1.5-rc.2 declares 72 dependencies as ^0.1.5-rc.2, npm resolves both dsh-base and dsh-pwsh-sandbox to 0.1.5-rc.3, and @deepseek-ai/dsh-sandbox-local is declared only by dsh-base. The float is plain semver: ^0.1.5-rc.2 admits rc.3 because the comparator's prerelease tuple (0.1.5) matches, so nothing here is npm misbehaving.

Worth adding: no code path advances latest. scripts/release/families.ts maps every version containing - to next (:294-296, with alpha/canary mapped to their own channel by the override at :355-360) and leaves only a stable version to npm's latest default. No stable @deepseek-ai/dsh has ever been published (npm view @deepseek-ai/dsh versions is prereleases all the way down), so the tag has stayed where it was; the release notes already warn about the mirror case, an older artifact republished after a newer one taking latest (.agents/notes/implemented/process/2026-08-10-npm-release-sequences.md:185). Moving it is registry state an operator has to change — no publish will correct it on its own.

Nesting is not the step that breaks the loader

Clean prefix, macOS 26, Node v26.5.0, npm 11.17.0, npm install --ignore-scripts @deepseek-ai/dsh@0.1.5-rc.2 (524 packages):

• top-level node_modules/@deepseek-ai/ holds 12 entries (cordis, cosmokit, schemastery, node-addon-system*, dsh, dsh-web-frontend, …)
• all 233 @deepseek-ai/dsh-* packages sit under node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/, every one of them at 0.1.5-rc.3 — the float, as you say. The nesting point differs from yours (under dsh/ here rather than under dsh-base/), but the observable is the same: not at the installation's top level.

Then I ran your version's own boot step against that install — healProfilesModuleFallback, exported by the installed @deepseek-ai/dsh-app-boot/lib/index.js and called from the CLI's composeProfile before the Loader mounts:

fallback entries created: 187 top-level (240 inside the @deepseek-ai scope)
dsh-sandbox-local -> <prefix>/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-sandbox-local
resolve from the profile directory:
  @deepseek-ai/dsh-sandbox-local => <...>/dsh-sandbox-local/lib/index.js
  @deepseek-ai/dsh-llm / dsh-web-app / cordis => resolve

That is the point: the launcher does not rely on hoisting. resolveModuleFallbackEntries walks the installation's dependency closure from <install>/@deepseek-ai/dsh/package.json, and packageDirFromAnchor probes Node's own node_modules lookup order from each declaring package, so a package nested two levels down is found; its directory is then projected as a symlink (junction on Windows) into $DSH_HOME/profiles/node_modules, which the profile reaches through Node's ordinary parent walk. Reachability is by construction, not by layout. On this machine the package your error names resolves fine from the profile directory, at the version npm actually produced.

So the symptom is real and the tag/float is a real defect worth fixing, but "npm floats to rc.3 → not hoisted → the loader cannot see it" is not the causal step — at least not on macOS with npm 11.17. Were nesting the cause, the same install would have failed here the same way, and it does not.

What does produce your error, and how to tell

The closure walk drops declared dependencies it cannot find, silently:

const dir = packageDirFromAnchor(next.anchor, dep)
// A declared-but-uninstalled dependency cannot be a loader-visible
// plugin; skip it rather than fail the whole boot.
if (dir === undefined) continue

(packages/boot/app-boot/src/profile.ts:494-496 on master; same shape in 0.1.5's built lib.) If any package in the installation's graph is missing at every anchor — a partial install, a tree npm adjusted around ERESOLVE (your follow-up log is full of npm warn ERESOLVE overriding peer dependency), an interrupted install — it is never projected, and the Loader then reports the entry as unresolvable. Nothing names the skipped package or the manifest that declared it.

That yields a discriminator that needs no rebuild:

# 1. is the projection there at all (a junction pointing into the installation)?
Get-Item "$env:USERPROFILE\.dsh\profiles\node_modules\@deepseek-ai\dsh-sandbox-local" |
  Select-Object LinkType, Target
# 2. is the package installed anywhere npm can reach from the install anchor?
npm ls @deepseek-ai/dsh-sandbox-local @deepseek-ai/dsh-base -g
# 3. does Node resolve it from the profile, independently of dsh?
node -e "console.log(require.resolve('@deepseek-ai/dsh-sandbox-local',{paths:[process.env.USERPROFILE+'/.dsh/profiles/web']}))"

• (1) missing and (2) missing → the install is incomplete; the boot failure is a symptom, and the fix belongs in install diagnostics rather than in resolution.
• (1) missing while (2) finds it → the heal step itself (anchor, lock, or Windows junction/readlink semantics). That would be a different bug worth its own report, with $DSH_HOME/profiles/node_modules as the artifact to attach.
• (1) present and (3) resolves → resolution is fine and the error(s) above the summary line are the ones to read; the summary only names the entry, not the reason.

On your two fixes

1. Move latest, or pin the ranges — agreed, and the pin is the structurally important half: while @deepseek-ai/dsh@X declares ^X for the whole family, one install may legitimately assemble packages from two releases, so the layout a release was packed and probed with is not the layout a user gets.
2. Declare @deepseek-ai/dsh-sandbox-local in dsh — harmless, but it does not fix resolution: in the measurement above the package is nested and resolves anyway, and the same silent skip applies to every other package that goes missing. It makes the tree more uniform, not more correct.

Cheap and useful either way: keep booting, but say what was skipped. The resolution already records each package's declarer (master's createRuntimeResolution keeps declarers and versions maps), so a diagnostic naming the dropped dependency and the manifest that declared it turns "could not be resolved" into something actionable.

Two smaller things in the same thread

pnpm is not a boot prerequisite. There is no pnpm spawn on the launch path: apps/cli/src/plugin.ts prints dsh: pnpm was not found; install pnpm and make it available on PATH. only for dsh plugin …, which forwards to pnpm — the only CLI consumer; initProfile merely writes the profile's pnpm-workspace.yaml (packages/boot/app-boot/src/profile.ts:211-236), settings for later pnpm runs. A clean npm i -g @deepseek-ai/dsh does not need pnpm to boot a stock profile. Your two observations also differ in version (the failing run was latest = rc.2 with base floated to rc.3; the passing run named rc.3 explicitly), so they are confounded — the 2×2 (rc.2/rc.3 × pnpm present/absent, fresh DSH_HOME each time) separates them. If missing pnpm really does change the outcome, that is a third and separate defect; "hundreds of Cannot find package lines on every start" is the signature of no fallback entries at all rather than of one missing dependency, which is why the discriminator above is worth running first.

This mechanism has since been replaced. healProfilesModuleFallback no longer exists on master: the symlink-projection backend is gone, createRuntimeResolution plus an in-process runtime interception (packages/boot/app-boot/src/profile-resolution/resolver.ts) supply the installation closure, and removeLinkProjections survives only to clean up the $DSH_HOME/profiles/node_modules projections an 0.1.5 launch wrote. So this layout fragility is version-specific — if it reproduces on 0.1.7-alpha.2 (what alpha points at), that is worth reporting separately against the new path.

[YS-yiqu]

到同样的问题，目前已成功解决！

在此记录一下：卸载当前版本后，安装 next 标签下的 0.1.5-rc.3 版本即可正常启动。

执行命令：

npm uninstall -g @deepseek-ai/dsh
npm install -g @deepseek-ai/dsh@next

安装后再次运行 dsh web 成功启动，之前的本地记录也正在正常恢复中。感谢方案提供者！

[xswt442-cmd]

Adding a controlled A/B that this thread doesn't have yet: one runner image, one set of steps, only the root version changes.

root package	ubuntu-latest	windows-latest
0.1.5-rc.3	boots	boots
0.1.5-rc.2 (= what latest points at)	plugin(s) failed to load: @deepseek-ai/dsh-sandbox-local	same
0.1.2-rc.1	never comes up	never comes up

Clean runners, npm i -g each time, full run here:
https://github.com/xswt442-cmd/dsh-instance-manager/actions/runs/35808993967

Two things I'd add to the picture above.

pnpm is not what stops the boot. It was missing on every job — the runner images don't ship it any more — and 0.1.5-rc.3 boots anyway. That fits what you see on a fresh Windows box, but it isn't what happens here.

The nesting is real, but the root version looks like the deciding step. npm ls -g does put dsh-sandbox-local only under dsh-base, deduped; at the same time the profile projection contains symlinks straight into the install, so the layout on its own doesn't look like what breaks it. What separates the runs is the root: rc.3 boots, rc.2 doesn't, same machine, minutes apart, with rc.2's sub-dependencies floating up to rc.3.

One more data point, in case it helps: 0.1.2-rc.1 fails differently from latest — it prints its launch URL and then never answers. That spec was green on these same runners a day earlier, with a frozen dependency tree, so something moved in the environment rather than in the packages.

[1420079678-ctrl]

Your diagnosis holds, and the registry confirms it is a property of what latest points at rather than of the machine. Two additions that make it reproducible and actionable.

The mixed tree is by construction

npm view @deepseek-ai/dsh dist-tags today:

latest: 0.1.5-rc.2
next:   0.1.5-rc.3
alpha:  0.1.7-alpha.2

Now compare the two candidates' sibling ranges:

Package	0.1.5-series dependencies	Range
@deepseek-ai/dsh@0.1.5-rc.2	63	all ^0.1.5-rc.2
@deepseek-ai/dsh@0.1.5-rc.3	63	all ^0.1.5-rc.3

^0.1.5-rc.2 admits prereleases of the same major.minor.patch, so npm resolves every one of those 63 siblings to 0.1.5-rc.3 — the highest version that satisfies it. Installing by the latest tag therefore yields dsh@0.1.5-rc.2 with a 0.1.5-rc.3 sibling set: a mixed generation tree, which is exactly the state in which the hoisting no longer puts @deepseek-ai/dsh-sandbox-local where the loader looks for it. latest still points there, so npm i -g @deepseek-ai/dsh keeps reproducing it for every new user.

Reproduce the two trees with:

npm view @deepseek-ai/dsh dist-tags --json
npm view @deepseek-ai/dsh@0.1.5-rc.2 dependencies --json
npm view @deepseek-ai/dsh@0.1.5-rc.3 dependencies --json

What gets a machine running today

Pin the generation instead of the tag, so the whole tree agrees:

npm i -g @deepseek-ai/dsh@0.1.5-rc.3
npm i -g pnpm

Two notes on why both lines are needed:

• Pin, do not force. Adding @deepseek-ai/dsh-sandbox-local on its own only moves one package; the load failure comes from the set disagreeing, so pinning the entry point to the same generation as its siblings is what makes the layout stable. If you prefer to stay on rc.2, pin all 63 siblings — which is the same thing with more typing.
• pnpm is independent, as you found. The same clean machine fails even after the tree is consistent, because plugin management in a profile is delegated to pnpm in the profile directory and a global npm install does not bring it. Fixing resolution alone will not make a fresh machine boot.

I verified the version families and dist-tags above against the registry just now. I could not reproduce your clean-install run end to end — my machine is a source checkout with an existing profile, which is precisely the machine where this does not show — so treat the "two trees" reproduction as the evidence, not a second clean-room install.

What fixes it upstream

Bumping the latest tag to a self-consistent generation (or republishing rc.2 with sibling ranges that pin rc.2) — otherwise the default install command stays broken for new users. Declaring pnpm as a prerequisite of the global install, or bundling a fallback, would close the second half. It may be worth noting both in one place, since a user hitting either one sees "server never comes up" and cannot tell them apart.

[Gniy7Ga]

Thanks for the detailed report and the Windows confirmation. I've filed an investigation into the clean-install startup failure, including the difference between the default install and an explicitly selected release. The package-nesting and pnpm explanations are still hypotheses; the macOS comparison here is useful, but does not establish why the Windows launch failed. We'll track the startup failure separately from installation-time missing-package errors and report back here when a fix is verified in an available release.

[1420079678-ctrl]

I reproduced this on Windows and can name the step that fails, which also reconciles the two readings above: the package is projected and does resolve from the profile directory, and the lookup that fails is anchored somewhere else.

Reproduction (isolated prefix installs, so the two roots can be compared on one machine)

npm install -g --prefix <tmp>\rc2 --ignore-scripts @deepseek-ai/dsh@0.1.5-rc.2
npm install -g --prefix <tmp>\rc3 --ignore-scripts @deepseek-ai/dsh@0.1.5-rc.3
# fresh DSH_HOME per run, then: node <prefix>\node_modules\@deepseek-ai\dsh\lib\bin.js web --no-open --port <free>

	rc.2	rc.3
boot	exit 1 — plugin tree failed to load: @deepseek-ai/dsh-sandbox-local ... could not be resolved, 19 lines on stderr, no URL	alive after 35 s, stderr empty, prints dsh web: http://127.0.0.1:<port>/?token=…
where dsh-sandbox-local lands	@deepseek-ai/dsh/node_modules/@deepseek-ai/**dsh-base**/node_modules/@deepseek-ai/dsh-sandbox-local (plus a second copy under dsh-sdk-minimal)	@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-sandbox-local
packages installed	563	518

Same machine, same npm, same Node, minutes apart, only the root version differs — which matches the runner A/B two comments up. The installs sit outside any other checkout, so nothing else on the machine can satisfy the lookup.

The three probes that separate the explanations

probe	rc.2	rc.3
resolve @deepseek-ai/dsh-sandbox-local from the app install (<prefix>/@deepseek-ai/dsh/lib)	MODULE_NOT_FOUND	OK
the profile's projected link	present, pointing two levels deep	present, pointing at the copy beside the app
resolve it from the profile directory	OK	OK

So on rc.2 the profile projection is present and usable (which is what the profile-dir probe shows), and the same name cannot be resolved from the app install anchor. The boot's failure names exactly that lookup. On rc.3 the copy sits beside the app, so the same anchor succeeds.

That is what makes the two earlier readings both right about their own probe: checking resolution from the profile directory cannot show this failure, because the profile directory is not where the failing lookup starts. And "incomplete install" is not needed to explain it — the tree is complete, one package is simply out of reach of the anchor the boot uses.

What I did not establish: which call site performs that lookup. I measured which anchor fails, not the code path; if someone points me at it I will check whether a profile-anchored resolution would be the right fix there, rather than adding the package to the app's own dependency set.

Two things worth fixing on top of the tag

• The diagnostic gap is real: the summary says "see the error(s) logged above" and there are no such lines above it — stderr carried nothing but the summary and the stack. Naming the skipped name and the manifest that declared it would have turned this thread into a five-minute diagnosis.
• The layout is the deciding difference, so a release that ships the flat shape is the fix users can install today; @next (0.1.5-rc.3) does boot here, as others found. Since no code path moves the latest tag, the default install command keeps producing the broken layout until an operator moves it.

[Bear0117]

Windows confirmation, with the swallowed root error and a same-machine A/B

Adding a Windows data point that ties this thread to #7578 and rules out one hypothesis that keeps coming up (install scripts / --allow-scripts).

Environment

• Windows 11 Pro 10.0.26200, Node v24.21.0, npm 11.19.0
• No PowerShell 7 on PATH (dsh falls back to Windows PowerShell 5.1, unrelated to this bug)
• Model route: a custom openai-completions provider injected with --patch, so every run below is a fresh DSH_HOME with no profile state

Same machine, same day, five installs of the same dsh version

# | How @deepseek-ai/dsh@0.1.5-rc.2 was installed | Sibling packages resolved to | dsh-win32-process copies | dsh --profile headless "…" -- | -- | -- | -- | -- 1 | npx cache created 2026-09-22 10:18 +0800, i.e. before 0.1.5-rc.3 was published (05:45Z = 13:45 +0800) | 231 × rc.2, 0 duplicates | 1 | boots, answers 2 | npm install -g @deepseek-ai/dsh today (npm 11 default, install scripts skipped) | 1 × rc.2 root + 270 × rc.3, 28 packages duplicated | 4 | fails 3 | npm install -g --allow-scripts=… @deepseek-ai/dsh (install scripts allowed) | same mixed graph as #2 | 4 | fails 4 | npm install @deepseek-ai/dsh@0.1.5-rc.2 into an empty local project (npm init -y first) | 1 × rc.2 root + 230 × rc.3, but hoisted flat, 0 dsh duplicates | 1 | boots, answers 5 | npx -y @deepseek-ai/dsh@alpha (0.1.7-alpha.2, install scripts skipped) | 267 × alpha.2, 0 duplicates | 1 | boots, answers

Rows 2 vs 3 show install scripts are not the variable: allowing them changes nothing, and row 5 boots with them skipped. Rows 2 vs 4 show the same mixed rc.2/rc.3 graph boots when npm can hoist it flat and fails when dsh itself is the root of the tree. Row 1 vs 2 is the timeline: an rc.2 install taken before rc.3 existed is coherent and works.

What the global tree looks like (row 2, reproduced with npm install -g --prefix <tmp> so the real global dir is untouched)

@deepseek-ai/dsh                       0.1.5-rc.2
  node_modules/@deepseek-ai/dsh-base   0.1.5-rc.3
    node_modules/@deepseek-ai/dsh-subprocess-local  0.1.5-rc.3
      node_modules/@deepseek-ai/dsh-win32-process   0.1.5-rc.3   (copy 1)
    node_modules/@deepseek-ai/dsh-sandbox-local     0.1.5-rc.3
      node_modules/@deepseek-ai/dsh-sandbox-windows-acl
        node_modules/@deepseek-ai/dsh-win32-process 0.1.5-rc.3   (copy 2)
  node_modules/@deepseek-ai/dsh-sdk-minimal 0.1.5-rc.3
    … same two subtrees again …                                   (copies 3 and 4)
  node_modules/koffi 3.3.1                                        (single copy, shared by all four)

Because the rc.2 root declares ^0.1.5-rc.2 ranges, dsh-base and dsh-sdk-minimal both resolve to rc.3 and npm cannot hoist their shared rc.3 dependencies above a rc.2 root, so each consumer gets its own nested copy. koffi stays a single hoisted copy, so all four dsh-win32-process modules register their native structs against the same koffi instance.

The error the loader swallows

Importing the four dsh-win32-process copies from that tree in order, with plain import() and no dsh involved:

OK   dsh-win32-process  …/dsh-base/…/dsh-sandbox-windows-acl/node_modules/@deepseek-ai/dsh-win32-process
FAIL dsh-win32-process  …/dsh-base/node_modules/@deepseek-ai/dsh-subprocess-local/node_modules/@deepseek-ai/dsh-win32-process
     -> Duplicate type name 'DSH_STARTUPINFOW'
FAIL dsh-subprocess-local (both copies)      -> Duplicate type name 'DSH_STARTUPINFOW'
FAIL dsh-sandbox-local (second copy)         -> Duplicate type name 'DSH_STARTUPINFOW'

The same probe against row 4 (flat tree, one copy of everything) imports all of them cleanly. So on Windows the chain is: mixed prerelease graph → nested duplicate dsh-win32-process → koffi Duplicate type name 'DSH_STARTUPINFOW' on the second import (exactly #7578) → the plugin's apply never completes → the user only sees:

dsh: cannot create effect on inactive context
Error: dsh: plugin tree failed to load: dsh: plugin(s) failed to load: @deepseek-ai/dsh-sandbox-local;
Cordis startup failed because these plugin(s) could not be resolved (see the error(s) logged above)

There is no "error logged above": the koffi message never reaches stderr.

Reproduce without touching your global install

npm install -g --prefix $env:TEMP\dsh-gprefix @deepseek-ai/dsh@0.1.5-rc.2
$env:DSH_HOME = "$env:TEMP\dsh-home-test"
node $env:TEMP\dsh-gprefix\node_modules\@deepseek-ai\dsh\lib\bin.js --profile headless "Reply OK"
# fails; then compare with a local-project install of the same version, which boots

Suggestions, in order of blast radius

1. Release side: point latest at a self-consistent release (rc.3 or later), or republish rc.2 with exact sibling pins. Every ^0.1.x-rc.N range on a prerelease root is a time bomb the moment rc.N+1 ships.
2. dsh-win32-process: make the koffi struct registration idempotent (check koffi.types / keep the registration in a module keyed on the koffi instance) so two copies in one process degrade gracefully instead of throwing.
3. app-boot: when a plugin fails to load, include the original import error message and the failing package path in the summary. That one line would have pointed at koffi instead of at dsh-sandbox-local.
4. Docs: the README only shows npx; a note that npm install -g needs a pinned version (and pnpm for dsh plugin) would save the next dozen reports.

Workaround for anyone landing here today: npm install -g @deepseek-ai/dsh@0.1.5-rc.3 (or @alpha), or keep using npx, and clear %LOCALAPPDATA%\npm-cache\_npx if an older cached rc.2 was created after 2026-09-22 05:45Z.

[dsh-community-assistant[bot]]

The new Windows comparisons narrow this down: allowing install scripts did not fix the failing global install, while the flat local-project install booted. The profile-resolution probe and the duplicate DSH_STARTUPINFOW import error are useful but distinct leads; we still need to establish which one occurs along the failing startup path.

I have added both comparisons to the existing investigation, including the missing underlying error in the startup diagnostic. The reported rc.3/alpha.2 successes are useful workarounds, but do not yet establish that the default install is fixed.

[Danerus23]

Thanks for digging into this properly — you're right on both counts, and I want to walk back my earlier pnpm comment so it doesn't send anyone the wrong way.

pnpm is not a boot prerequisite. My two runs confounded two variables — I moved from latest (= rc.2) to rc.3 and added pnpm in the same step, so I attributed the fix to pnpm. The A/B above (rc.3 boots with pnpm absent) and your walk of the launch path settle it: dsh plugin is the only pnpm consumer, and initProfile only writes pnpm-workspace.yaml. Please disregard that part of my comment.

The actionable part stays: latest should move to a self-consistent release (or rc.2's ^0.1.5-rc.2 sibling ranges be pinned), otherwise a fresh npm i -g @deepseek-ai/dsh keeps assembling the broken mixed tree.