Agent terminal fails with 'C:\Program' is not recognized on Windows (unquoted path in spawn)

[billrehm]

What happened?

Relates to: The original Windows agent spawn bug (error code 193 / node-pty cannot execute npm wrapper scripts), which was closed as fixed in 0.2.4.

On 0.2.4 running on an Azure Virtual Desktop (AVD), agent spawning partially works on Windows. Michael now loads successfully (previously he would clock in and disappear). However, when launched without the .exe wrapper workaround, every agent's terminal immediately fails with:

'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
─ process exited (code 1) ─

The path to node.exe (or claude.exe) under C:\Program Files\ contains a space that is not being quoted or escaped before being passed to the shell. The command interpreter splits at the space and tries to execute C:\Program as a standalone command.

With the .exe wrapper in place (which lives at a path without spaces), Michael loads and Claude starts in the terminal window. So the wrapper sidesteps the unquoted-path bug rather than the bug being fixed.

Additional evidence of Windows path handling issues:
The GOD agent attempted to move processed inbox files using mv with Unix-style MSYS/Git Bash paths:
Error: Exit code 1
mv: cannot stat '/c/Users/BillRehm/HarnessAgents/hive/hive/agents/god/inbox/2026-06-09T14-03-36-870Z-8d54df.json': No such file or directory

The /c/Users/ path format is MSYS convention, not native Windows. This suggests the harness is either shelling out through Git Bash or generating paths with a Unix-to-Windows translation layer that isn't converting back before executing file operations.

Behavior with the queue when terminal is dead: Any text sent via the message queue to an agent whose terminal failed with the C:\Program error simply refreshes the terminal with the same error text. There is no live session behind it.

Steps to reproduce

1. Install Munder Difflin 0.2.4 on Windows 11 where Claude Code is installed under a path containing spaces (e.g. C:\Program Files\nodejs\npm-global, as is the case with npm global installs on an AVD).
2. Launch without the .exe wrapper workaround.
3. Michael loads on the floor and his terminal opens.
4. Observe the terminal shows 'C:\Program' is not recognized and exits with code 1.
5. Add any additional agents via Restore Team. Same error in their terminals.
6. Repeat with the .exe wrapper in place. Michael's terminal works. Agent terminals work after Restore Team.

Logs / screenshots

Terminal output (verbatim, every agent):
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
─ process exited (code 1) ─

GOD inbox file operation error:
Error: Exit code 1
mv: cannot stat '/c/Users/BillRehm/HarnessAgents/hive/hive/agents/god/inbox/2026-06-09T14-03-36-870Z-8d54df.json': No such file or directory

macOS version

Windows 11 (Azure Virtual Desktop, build 10.0.26200.8457)

Node version

v24.13.0

Claude Code version (if relevant)

v2.1.126

Pre-flight

• I re-ran npm install so node-pty is rebuilt for the current Electron ABI.
• I searched existing issues and this isn't a duplicate.

[chaitanyagiri]

Confirmed — this is a follow-on gap in the 0.2.4 Windows spawn fix (#51): cmd.exe /c is handed an unquoted path containing spaces.

Verified in src/main/pty.ts. The #51 fix routes non-.exe/.com targets through cmd.exe /c (correct — that's what lets .cmd/extensionless shims run at all), but it passes the resolved path as a bare argument:

// pty.ts:153-154
const file = needsCmd ? (process.env.ComSpec || 'cmd.exe') : resolved;
const spawnArgs = needsCmd ? ['/c', resolved, ...(opts.args ?? [])] : (opts.args ?? []);

When resolved is e.g. C:\Program Files\nodejs\npm-global\claude.cmd, cmd.exe parses up to the first space and tries to run C:\Program → exactly your 'C:\Program' is not recognized. The .exe wrapper sidesteps it because its path has no spaces, so as you said the bug was masked, not fixed.

resolveCommand (pty.ts:73) takes the first PATHEXT-eligible where hit, which on an npm-global AVD install is the claude.cmd under Program Files — so the path-with-spaces case is the common one there, not an edge case. High severity: every Windows agent terminal fails without the wrapper.

Fix — quote the command for cmd.exe. The robust, Node-core-blessed form is cmd.exe /d /s /c "<command line>" with the program path and each arg explicitly double-quoted:

if (needsCmd) {
  const line = [resolved, ...(opts.args ?? [])].map(a => `"${a}"`).join(' ');
  // file = ComSpec || 'cmd.exe'
  // spawnArgs = ['/d', '/s', '/c', line]
}

/s makes cmd strip exactly the outer quote pair, so an inner-quoted path with spaces survives. ⚠️ One thing to verify when implementing: node-pty does its own Windows arg-quoting (argsToCommandLine); confirm it doesn't double-wrap the already-quoted line — if it does, the inner quotes alone are enough. This keeps the BatBadBut metacharacter hardening from #51 intact since args stay individually quoted.

Secondary symptom (mv: cannot stat '/c/Users/...'): that's GOD generating MSYS/Git-Bash style paths in its own terminal, separate from the spawn bug — native cmd/PowerShell can't stat a /c/Users/... path. Worth a separate look at how AGENT_DIR/HIVE_ROOT are formatted on win32.

cc @chaitanyagiri

[chaitanyagiri]

Verified fixed in v0.2.5 (commit e5c144e) — recommend close.

The new buildCmdCommandLine() in src/main/pty.ts routes non-.exe Windows targets through cmd.exe /d /s /c "<line>", double-quoting the resolved target and each arg only when it contains a space/tab/quote, then wrapping the whole inner command in one outer pair that /s strips. So C:\Program Files\...\claude.cmd now survives its space instead of splitting at C:\Program — exactly the repro in this issue. The JSDoc also confirms node-pty receives this as a pre-escaped CommandLine and passes it through verbatim (no double-wrapping), which was the concern when I first reviewed the #51 fix.

Separate latent item (not this bug): cmd.exe still expands %VAR% inside quotes, so the generated -p prompt path in assistant.ts/reflect.ts would ideally move to stdin as a follow-up hardening. The crash this issue reports is resolved.

— @chaitanyagiri ok to close once you've confirmed on Win11.