[Desktop 2.0.10] All subprocesses fail on Windows: private runner launched via process.execPath without ELECTRON_RUN_AS_NODE

[moonxmboo-eng]

Component: @deepseek-ai/dsh-subprocess-local@0.1.6-alpha.1
Environment: DSH Desktop 2.0.10 (Electron 43.3.0, bundled Node 24.18.1), Windows x64

---

Symptom

On the packaged desktop build, every subprocess spawn fails. The code-execution tool, the shell tool and plugin installation are all unusable.

Error: subprocess-local: Windows Job runner exited with exit code 0
       before proving its managed range empty
    at settleRange (<install>\resources\app\node_modules\@deepseek-ai\dsh-subprocess-local\lib\index.js:611:38)
    at ChildProcess.<anonymous> (<install>\...\lib\index.js:668:3)

The DSH server is hosted in Electron's utility Node process:

"DSH Desktop.exe" --type=utility --utility-sub-type=node.mojom.NodeService ...

Root cause

spawnRunnerInvocation() (lib/runner-launch-*.js) resolves the private runner through process.execPath:

function spawnRunnerInvocation() {
    if ("pkg" in process) return [process.execPath];
    if (extname(fileURLToPath(import.meta.url)) !== ".ts")
        return [process.execPath, fileURLToPath(import.meta.resolve("@deepseek-ai/dsh-subprocess-local/runner"))];
    ...
}

Inside Electron's utility Node process process.execPath is DSH Desktop.exe, so the spawn becomes:

"DSH Desktop.exe" "<install>\...\dsh-subprocess-local\lib\runner.js" -- <target argv>

This starts a second app instance. It hits the single-instance lock, forwards its argv to the already-running instance and exits immediately with code 0. The parent then observes exactly the three conditions that settleRange() treats as infrastructure failure:

if (exitCode === 0 && signal === null) {
    if (directResultType !== void 0) { rangeExit.resolve(); return; }
    if (!ipcDisconnected) return;
}
// -> failInfrastructure(...)

exit code 0, no signal, and the IPC channel disconnected before any direct-result message arrived.

ELECTRON_RUN_AS_NODE is never set anywhere in the package (0 occurrences in lib/index.js and lib/runner-launch-*.js).

Deterministic reproduction outside the app

> & "DSH Desktop.exe" "<install>\...\lib\runner.js" -- cmd.exe /c "echo RUNNER_OK"
  # no output, exit=0 after ~235 ms, and the running DSH Desktop window is raised to the foreground

> $env:ELECTRON_RUN_AS_NODE='1'
> & "DSH Desktop.exe" "<install>\...\lib\runner.js" -- cmd.exe /c "echo RUNNER_OK"
  # Node.js v24.18.1 starts and executes the script -> the flag is the only missing piece

Regression: 0.1.5-rc.2 already handled this

@deepseek-ai/dsh-subprocess-local@0.1.5-rc.2 contained, inside runnerEnvironment():

// Electron hosts must launch the private Windows runner in Node mode.
// Target env arrives separately over IPC; never add this flag to it.
if (selection === WINDOWS_RUNNER_SELECTION && process.platform === "win32" && process.versions.electron !== void 0) {
    for (const name of Object.keys(env)) {
        if (name.toUpperCase() === "ELECTRON_RUN_AS_NODE") Reflect.deleteProperty(env, name);
    }
    env.ELECTRON_RUN_AS_NODE = "1";
}

0.1.6-alpha.1 deleted the whole block. Combined with the desktop build moving the server from a standalone node.exe into an Electron utility process, the assumption behind process.execPath ("this is Node") no longer holds.

Additional finding: fixing only the runner is not sufficient

The code-execution worker is also spawned as the Electron binary:

"DSH Desktop.exe" "...\lib\runner.js" -- "DSH Desktop.exe" --max-old-space-size=512 "...\dsh-ptc-runtime-node\lib\process.js" 134217728

so its target environment 鈥?built by targetEnvironment() (childEnv(spec.env)) and by the direct spawnSubprocess() path (controlEnvironment(childEnv(spec.env), ...)) 鈥?needs the flag as well. Without it the failure merely moves one level down:

Error: code run failed (worker-exit): Node process exited before completing (0)

Verified: patching only runnerEnvironment() reproduces the second error; patching the target environment as well fixes it.

Suggested fix

1. Restore the 0.1.5-rc.2 block in runnerEnvironment().
2. Additionally inject the flag for the target environment, but only when the command about to be spawned is the host's own binary, so that unrelated Electron GUI applications launched through the same seam keep starting normally:

function electronNodeEnv(command, env) {
    if (process.versions.electron === void 0 || typeof command !== "string") return env;
    const self = process.execPath;
    if (typeof self !== "string") return env;
    const stem = (value) => String(value).split(/[\\/]/).pop().toLowerCase();
    if (stem(command) !== stem(self)) return env;
    return { ...env, ELECTRON_RUN_AS_NODE: "1" };
}

applied at the two places that build a target environment (targetEnvironment() and the direct branch of spawnSubprocess()).

Note: a naive fix that adds the flag inside childEnv() does make everything work, but it leaks ELECTRON_RUN_AS_NODE into every spawned process, which breaks launching any other Electron GUI application (e.g. VS Code via Code.exe) from inside DSH. That is exactly what the 0.1.5-rc.2 comment warned about. The scoped version above avoids it.

Impact

Complete loss of a core capability on the packaged Windows desktop build (no shell tool, no code execution, no plugin install). The only workaround is patching files inside resources\app, which any future update wipes.

---

Found on a standard Windows x64 installation. Happy to provide further detail or to test a patched build.