[Bug] Windows + npm global install: dsh web cannot boot — duplicate physical copies of @deepseek-ai/dsh-win32-process trigger koffi "Duplicate type name 'DSH_STARTUPINFOW'", and a create-then-check HMR race exits right after printing the URL

[Van1145141919810]

Summary

On Windows 11 with a standard npm global install, @deepseek-ai/dsh@0.1.5-rc.2 cannot start dsh web out of the box. There are two independent defects; fixing either one alone is not enough:

1. Duplicate physical copies of @deepseek-ai/dsh-win32-process in the npm-expanded tree. Two copies are evaluated in the same boot and both register the same koffi type on the same koffi instance, so koffi throws Duplicate type name 'DSH_STARTUPINFOW'; @deepseek-ai/dsh-sandbox-local then fails to import and the plugin tree fails to load.
2. HMR create-then-check race: after the plugin tree loads and the web server prints its URL, runProfile creates the HMR service dynamically and immediately checks it synchronously, while Hmr extends Service only becomes visible after its async Service.init. The process then throws requires the Cordis HMR service and exits.

Both reproduce with zero third-party plugins: defect 2 on a brand-new empty DSH_HOME (stock web profile), defect 1 on three clean re-installs.

Environment

• OS: Windows 11 (10.0.26200)
• Node.js v24.15.0, npm 11.12.1 (default hoisted install strategy)
• dsh CLI: @deepseek-ai/dsh@0.1.5-rc.2; its dependencies (dsh-base, dsh-app-boot, dsh-sandbox-*, dsh-win32-process, …) resolved to 0.1.5-rc.3
• Install: npm install -g @deepseek-ai/dsh@0.1.5-rc.2
• koffi 3.3.1 (only one copy in the tree)

Defect 1 — duplicate dsh-win32-process → koffi duplicate type

Symptom (unmodified profile):

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)
    at boot (dsh-app-boot/lib/index.js:1545)
    at async runProfile (dsh/lib/profile-boot-*.js:311)

Variant (when the sandbox entry is disabled): @deepseek-ai/dsh-permission-presets: pending (waiting for service: shell) — same root cause.

Direct evidence: require.resolve('@deepseek-ai/dsh-sandbox-local') succeeds, but a real import() throws:

direct import of @deepseek-ai/dsh-sandbox-local FAILED: Duplicate type name 'DSH_STARTUPINFOW'

import('.../dsh-sandbox-local/lib/index.js')
  → import('.../dsh-sandbox-windows-acl/lib/index.js')
    → import('.../dsh-win32-process/lib/index.js')
      ✗ Duplicate type name 'DSH_STARTUPINFOW'

dsh-win32-process/lib/index.js:35 registers the type unconditionally at module top level:

const STARTUPINFOW = koffi.struct("DSH_STARTUPINFOW", { cb: "uint32", lpReserved: "str16", lpDesktop: "str16", lpTitle: "str16", ... });

Root cause: after npm install -g, the tree contains 4 physical copies of @deepseek-ai/dsh-win32-process@0.1.5-rc.3 (byte-identical, different inodes):

dsh-base/node_modules/@deepseek-ai/dsh-subprocess-local/node_modules/@deepseek-ai/dsh-win32-process
dsh-base/node_modules/@deepseek-ai/dsh-sandbox-local/node_modules/@deepseek-ai/dsh-sandbox-windows-acl/node_modules/@deepseek-ai/dsh-win32-process
dsh-sdk-minimal/node_modules/@deepseek-ai/dsh-subprocess-local/node_modules/@deepseek-ai/dsh-win32-process
dsh-sdk-minimal/node_modules/@deepseek-ai/dsh-sandbox-local/node_modules/@deepseek-ai/dsh-sandbox-windows-acl/node_modules/@deepseek-ai/dsh-win32-process

Two of them — dsh-subprocess-local (provides the subprocess service) and dsh-sandbox-windows-acl (loaded by dsh-sandbox-local) — are evaluated in the same boot, and both import the same koffi copy (there is only one koffi in the tree). The module is therefore evaluated twice and the same type name is registered twice on one koffi instance.

This is not a dirty environment: full uninstall (npm uninstall -g + removing %APPDATA%\npm\node_modules\@deepseek-ai) + npm cache clean --force + fresh install reproduced the identical 4-copy shape 3 times. npm install --package-lock-only resolves to a tree with a single copy, so this is npm's reify placement interacting with the package graph; the same install emits roughly 280 npm warn ERESOLVE overriding peer dependency. At least 23 other packages are also duplicated (e.g. dsh-anonymous-user-id ×4, debug ×8).

Impact: any Windows user who installs 0.1.5-rc.2 / rc.3 globally with npm and has a profile containing sandbox (the base default) hits this; dsh web is completely unusable. macOS/Linux are unaffected (they use dsh-bash-sandbox and never load the pwsh/ACL/win32-process chain).

Suggested fixes (any one suffices):

• Make the type registration idempotent (check before registering, or catch and reuse an existing type).
• Or have dsh-sandbox-windows-acl / dsh-subprocess-local consume dsh-win32-process through peerDependencies, so only one copy is placed.
• Or fix the peer-override conflict that causes the duplicate placement (pin the rc.x dependencies exactly, or trim duplicate dependency declarations inside the bundles).

Defect 2 — HMR create-then-check race

After working around defect 1:

$ dsh web
dsh web: http://127.0.0.1:3080/?token=XXXX

Error: dsh: user patch-layer watching requires the Cordis HMR service
    at watchUserPatches (dsh-app-boot/lib/index.js:1112:28)
    at runProfile (dsh/lib/profile-boot-*.js:329:9)

The plugin tree loaded and the web server is up — then the process kills itself. 3 of 3 attempts.

Minimal reproduction (stock profile, no third-party plugins):

DSH_HOME=<empty dir> dsh web --no-open
  → dsh web: http://127.0.0.1:3080/?token=…
  → Error: dsh: user patch-layer watching requires the Cordis HMR service

Code path (dsh/lib/profile-boot-*.js:321-333):

if (composed.profile.patchReload === 'live' && …) {
  if (ctx.get('hmr') === void 0) {
    if (ctx.get('timer') === void 0) await ctx.loader.create({ name: '@deepseek-ai/cordis-plugin-timer' });
    await ctx.loader.create({ name: '@deepseek-ai/cordis-plugin-hmr', config: { root: [] } }); // only awaits creation
  }
  await watchUserPatches(ctx, { … }); // immediately reads ctx.get('hmr')
}

and dsh-app-boot/lib/index.js:1112 hard-fails:

const hmr = ctx.get('hmr');
if (hmr === void 0) throw new Error(`${binName}: user patch-layer watching requires the Cordis HMR service`);

Hmr extends Service; the service only becomes visible after async *[Service.init]() (cordis-plugin-hmr/lib/index.js:179+) completes its realpath + loadDependencies + chokidar watch. loader.create() returns while the fiber is still LOADING, so the immediately following synchronous check must lose the race. patchReload: "live" is the default in the official web template, so this is the default path.

Suggested fixes:

• Do not create-then-check: await the entry's activation (e.g. ctx.inject(['hmr'], …), or await the created fiber) — or
• enable the hmr entry that already exists in base (it is disabled: true by default) for official profiles with patchReload: "live" (we verified this works) — and/or
• degrade gracefully: when HMR is unavailable, warn that patch hot-reload is disabled but keep the server running.

Other observations

• @latest produces a mixed tree: CLI 0.1.5-rc.2 with dependencies at 0.1.5-rc.3. Pinning exactly would make reports far easier to triage.
• The failure is not self-diagnosing: plugin(s) failed to load: @deepseek-ai/dsh-sandbox-local … (see the error(s) logged above) — but nothing is logged above; the real koffi error is swallowed. Surfacing the underlying import exception on stderr would save a lot of time.
• --legacy-peer-deps is not a workaround: it removes the duplicates but skips peers, so @deepseek-ai/cordis-plugin-group and others go missing and dsh --version fails with ERR_MODULE_NOT_FOUND.

Local workarounds we are using (workarounds, not fixes)

1. Rename the extra physical copies and replace them with directory junctions pointing at one kept copy, so the module is evaluated once. This must be re-run after every npm install -g of dsh.
2. Enable the existing hmr entry in the profile patch layer (disabled: false) so the boot flow waits for the service instead of racing it.

Related reports already checked

• dsh 在部分 Windows 10 机器上因 koffi 原生崩溃而不可用（含症状/修复思路/修改过程） #197 — koffi native crash on some Windows 10 machines (related area, different failure).
• dsh web 在 macOS arm64 上无法通过常规入口启动（--expose-internals is required for HMR service） #113 / headless profile fails to boot: "--expose-internals is required for HMR service" #1313 — HMR boot failures (--expose-internals is required for HMR service) on macOS arm64 and headless.
• npx dsh-win32 doctor --json reports all-pass on this machine; its koffi check is profile-scoped ("no koffi found in any profile"), so it does not cover duplicated copies inside the global npm tree.
• npx dsh-fix doctor / disable sandbox were tried and did not help (disabling sandbox turns the failure into a misleading permission-presets: pending (waiting for service: shell)).

Requests

• A dsh doctor-style self-check that can detect "the same package is present as multiple physical copies" and "a native addon type was registered twice".
• A documented, officially verified Windows install path (pnpm? a specific npm --install-strategy?) and/or a known-good fallback version.

中文摘要

Windows 11 + npm 全局安装的 @deepseek-ai/dsh@0.1.5-rc.2 开箱即无法启动 dsh web,两个独立缺陷:(A) npm 展开后的依赖树里 @deepseek-ai/dsh-win32-process 有 4 份实体副本,其中两份在同一次启动被求值,却在同一个 koffi 实例上重复注册类型 DSH_STARTUPINFOW → dsh-sandbox-local 导入失败 → 插件树加载失败;(B) 插件树加载完、URL 打印后,runProfile 动态创建 HMR 服务并立即同步检查,而 HMR 的服务可见性要等异步 Service.init → 抛 requires the Cordis HMR service 后进程退出。两者在零第三方插件环境下均可复现(B 在全新空 DSH_HOME 的官方 profile 上 3/3 必现;A 在 3 次干净重装后形态一致)。macOS/Linux 不受 A 影响。