PTC run_code workers exit silently with code 0 on Windows: ELECTRON_RUN_AS_NODE is not preserved when the worker env is rebuilt

[17750651785lsj-tech]

Summary

On Windows packaged builds, PTC run_code never executes. The worker process is started with process.execPath — which in a packaged Electron build is the Electron binary — but the PTC runtime rebuilds the worker environment from scratch and drops ELECTRON_RUN_AS_NODE, the flag that makes that binary behave as Node.

The child therefore boots as a second Electron GUI instance, fails to acquire the single-instance lock, and exits cleanly. The parent reports:

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

Exit code 0, stderr empty, captured output empty.

Environment

• OS / arch: Windows 11, x64
• @deepseek-ai/dsh-desktop-runtime: 0.1.0-rc.22 (packaged Electron build)
• Bundled Node.js in the install: 24.17.0 (x64) — not the binary used by the PTC worker in this configuration
• Worker executable actually used: DeepSeek Harness.exe, via process.execPath
• PTC mode: selectable; the ptc agent preset is installed and mounts with mode: ptc

Line numbers below refer to the 0.1.0-rc.22 build (lib/*.js inside the packaged app.asar).

Steps to reproduce

1. Launch DSH Desktop on Windows (packaged build, not a dev checkout).
2. Select the PTC agent preset.
3. Call run_code with any minimal program.

Reproduced with four minimal variants — console.log("x"), returning an object, returning a primitive, and writing directly to process.stdout. All four fail identically, with empty captured output.

Expected behavior

The worker starts as Node, opens its inherited control channel, executes the submitted program, and returns output.

Actual behavior

The worker starts as the Electron binary without ELECTRON_RUN_AS_NODE, exits with code 0 before the bootstrap handshake, and is reported as worker-exit.

Root cause

Chain, each step verifiable in the shipped code:

1. The worker environment is rebuilt. packages/ptc-runtime/ptc-runtime-node/lib/index.js:956 builds env by assigning undefined to every variable not in STARTUP_ENVIRONMENT_NAMES:

   const env = Object.fromEntries(Object.keys(process.env)
     .filter((key) => !STARTUP_ENVIRONMENT_NAMES.has(key.toUpperCase()))
     .map((key) => [key, void 0]));

2. That allowlist does not contain the flag. lib/index.js:478-485 lists only PATH, PATHEXT, SYSTEMROOT, WINDIR, TEMP, TMP.

3. dsh-subprocess-local then removes it entirely. In the Windows branch of childEnv() the inherited entry with a matching name is dropped first, then the undefined placeholder is pushed; targetEnvironment() then filters the placeholder out:

   // childEnv(), Windows branch
   entries = entries.filter(([inherited]) => inherited.toUpperCase() !== normalized);
   entries.push([key, value]);
   
   // targetEnvironment()
   const env = Object.fromEntries(
     Object.entries(childEnv(spec.env)).filter((entry) => entry[1] !== void 0)
   );

   Net effect: the variable is neither inherited nor set — it is absent.

4. The worker executable defaults to process.execPath. lib/index.js:794:

   nodeExecutable: config.nodeExecutable ?? process.execPath

   The composed row sets no such config (packages/.../dsh-base/cordis.patch.yml:369-370 — a ptc-runtime row with no config block).

5. In a packaged build that is the Electron binary. The desktop shell resolves its runtime "node" to process.execPath in packaged builds and must pass ELECTRON_RUN_AS_NODE: "1" for it to behave as Node:

   // desktop shell, packaged app: lib/main.js
   const development = !app.isPackaged;
   return { node: development ? /* resources/runtime/node/node.exe */ : process.execPath, ... };
   
   const child = spawn(this.executable, [entry, runtimeDir, projectDir], {
     env: { ...scrubbed, ELECTRON_RUN_AS_NODE: "1" },
   });

6. Without the flag the child is a GUI app. It takes the single-instance path, loses the lock, and quits with code 0, never opening the control channel. The parent's processFinished handler maps that to kind: "worker-exit" with the message template Node process exited before completing (${exitCode}).

Exit code 0 with empty stderr is what rules out the usual suspects: a module-load failure would exit 1 with stderr; a sandbox denial would classify as sandbox-unavailable; a framing problem as protocol; an overrun as output-limit.

Suggested minimal fix

Preserve the flag when the worker environment is built — only when the parent already carries it and the worker is the parent's own binary:

// packages/ptc-runtime/ptc-runtime-node/src/index.ts, in execute(),
// immediately after the `const env = …` rebuild and before the `packaged` branch
const electronRunAsNode = process.env.ELECTRON_RUN_AS_NODE;
if (electronRunAsNode !== void 0 && executable === process.execPath) {
  env.ELECTRON_RUN_AS_NODE = electronRunAsNode;
}

Why the two conditions:

• !== void 0 — never invent the flag; a plain-Node parent (dev checkout, Linux node dsh) does not carry it, so nothing is injected.
• executable === process.execPath — only propagate when the worker is the parent's own binary. An explicitly configured nodeExecutable pointing at a standalone node.exe therefore never receives it.

The value is copied rather than hard-coded to "1", so the patch mirrors whatever the host set and needs no change if Electron alters the flag's representation.

That is the whole patch: one file, one hunk.

Note: no bootstrap change is needed

runNodeMain() already enforces the "starts empty" contract on entry:

// lib/process.js:1063-1064
for (const key of Object.keys(processState.env))
  if (!STARTUP_ENVIRONMENT_NAMES.has(key.toUpperCase())) Reflect.deleteProperty(processState.env, key);
processState.env = Object.create(null);

Its own STARTUP_ENVIRONMENT_NAMES (lib/process.js:1044-1051) is identical to the parent-side list and does not include the flag. So the flag is deleted before any submitted program runs, and process.env is replaced with an empty object — neither the program nor any child it spawns can observe it. No change is suggested to src/process.ts.

Test suggestions

Unit

• Flag is preserved when the parent has it and nodeExecutable is unset.
• Flag is absent when nodeExecutable is configured, or when the parent lacks it.
• All other non-allowlisted variables are still neutralized to undefined.
• Regression: runNodeMain() still empties process.env, so the flag is not observable by the submitted program.

Integration (Windows)

• Ready/boot handshake over the control channel for the managed windows-job path.
• Same for the fallback path (force it by stubbing the Win32 Job probe).
• Assert the worker sees the flag during startup and loses it before program evaluation.

End-to-end (packaged build)

• run_code returns output and values for the four minimal variants.
• A child process spawned from within run_code does not inherit the flag.
• Regression: native (non-PTC) sessions; shell tooling; MCP client connectivity.

Cross-platform

• macOS / Linux: with a plain-Node parent, nothing is injected and PTC mode is unaffected.

Not verified

• The exact point at which Electron's native layer consumes ELECTRON_RUN_AS_NODE — only the binary ships, so this could not be cited from the package. (This is also why the existing runNodeMain cleanup is safe.)
• Whether the flag is also present in process.versions.electron under run-as-node mode; the patch deliberately does not depend on it.
• Which containment path (windows-job vs fallback) a given machine takes.
• End-to-end behaviour after the fix — the patch has not been implemented, compiled, or tested.

Additional context

Configuring nodeExecutable alone does not work around this. Without bootstrapPath, the worker bootstrap still resolves to process.js inside app.asar, and a standalone Node has no ASAR support — that path is not mapped to app.asar.unpacked by the filesystem provider, and the package is not unpacked. It trades this failure for Cannot find module …app.asar\…\process.js. So nodeExecutable is currently unusable in packaged builds, which is a further argument for fixing this at the environment-construction site.

[PerryLink]

Your diagnosis is right, and 0.2.2 keeps the flag.

At e8f7b93a the worker env filter removes the startup names but spares this one: packages/ptc-runtime/ptc-runtime-node/src/worker.ts:323-325. The same line is at dsh-v0.2.2-rc.1 (worker.ts:252) and dsh-v0.2.2-rc.2 (:291).

The packaged branch still adds DSH_PTC_RUNTIME_NODE=1 and NODE_OPTIONS (:326-329), and the env map only marks removals, so the flag survives.

Your 0.1.0-rc.22 build has the old filter shape you quoted. Check the installed ptc-runtime-node/lib/index.js for !== 'ELECTRON_RUN_AS_NODE': if it is missing, the app packaged an older runtime, and a desktop build carrying the 0.2.2 runtime has the fix. I read the source only, no Windows packaged run here.

You can hand this to an AI assistant to compare those lines against your installed lib/index.js.