fix: Windows Bad Gateway — Vite killed by unquoted path in spawnService shell

[jamiechicago312]

Fixes #715

Root Cause

buildNpmScriptCommand() in scripts/dev-safe.mjs returns process.execPath as the command when npm_execpath is set (i.e. when launched via npm run dev):

// dev-safe.mjs:752
if (env.npm_execpath) {
  return {
    command: env.npm_node_execpath || nodeExecPath,  // e.g. C:\Program Files\nodejs\node.exe
    args: [env.npm_execpath, "run", scriptName],
  };
}

spawnService() in scripts/dev-with-automation.mjs then spawns that command with shell: true on Windows:

// dev-with-automation.mjs:460
shell: process.platform === "win32",

Node passes the command to cmd.exe unquoted, so cmd.exe sees C:\Program as the executable and errors out — killing Vite before the ingress starts, which causes Bad Gateway on localhost:8000.

This affects any Windows user whose Node.js is installed in C:\Program Files\ (the default installer path), regardless of clean or existing install.

Changes

• README: adds a one-paragraph Windows workaround note with the direct-script fallback (dev-with-automation.mjs)

Suggested code fix (follow-up)

Remove shell: process.platform === "win32" from spawnService(). When npm_execpath is set, buildNpmScriptCommand already returns a full node.exe path — shell: false spawns it correctly. When it isn't set (Windows non-npm path), buildNpmScriptCommand returns cmd.exe as the command explicitly, so no shell wrapping is needed there either.

This PR was created by an AI agent (OpenHands) on behalf of the user.

[vercel]

@jamiechicago312 is attempting to deploy a commit to the openhands Team on Vercel.

A member of the Team first needs to authorize it.

[all-hands-bot]

✅ LGTM - Clear documentation of a Windows-specific workaround.

The note is well-placed in the quickstart section, accurately describes the symptom, and provides a concrete solution. The workaround script exists and is the correct path for direct stack invocation.

[RISK ASSESSMENT]

• [Overall PR] ⚠️ Risk Assessment: 🟢 LOW

Documentation-only change with no code modifications. Adds user-facing guidance for a known Windows path issue. No breaking changes possible.

---

Was this automated review useful? React with 👍 or 👎 to this review to help us measure review quality.
Workflow run: https://github.com/OpenHands/agent-canvas/actions/runs/26243249005

[malhotra5]

Hmm npm run dev simply wraps node --env-file-if-exists=.env scripts/dev-with-automation.mjs command

Unclear to me why one fails but the other works

[malhotra5]

Is there a workaround that allows npm run dev to work? Because once we release the npm package it would be great if they could use it directly

[jamiechicago312]

That is the thing. I got this error for the first time I used agent canvas last week. And then earlier this week it worked great. and then i got bad getaway again!

@OpenHands can you investigate the codebase. What would need to change so windows, mac, and linux can run without running into bad getaway at all so that a user after npm install can just run npm run dev

[openhands-ai]

Uh oh! There was an unexpected error starting the job :(

[jamiechicago312]

Superseded by #734, which fixes the root cause in code rather than documenting a workaround.

The actual bug was a one-line ordering issue in buildNpmScriptCommand: the npm_execpath branch fired before the win32 branch, so on Windows the function returned the full C:\Program Files\nodejs\node.exe path as the spawn command. spawnService uses shell:true on Windows, and Node.js passes that unquoted path straight to cmd.exe, which splits on the space and fails with ‘C:\Program’ is not recognized.

Closing this in favour of #734.

This comment was added by an AI agent (OpenHands) on behalf of the user.