fix: resolve Windows ENOENT when spawning codex app-server

[zeta987]

Summary

• Adds shell: true (Windows-only) and windowsHide: true to the spawn("codex", ...) call in app-server.mjs so Node.js resolves .cmd shims installed by npm.
• Uses terminateProcessTree in close() to kill the entire process tree on Windows, preventing orphaned node.exe processes caused by shell: true wrapping the child in cmd.exe.
• Adds windowsHide: true to the existing spawnSync call in process.mjs to suppress transient console window flashes.

Problem

On Windows, npm installs codex as a global package and exposes it through a .cmd shim (codex.cmd). When app-server.mjs calls spawn("codex", ["app-server"]) without shell: true, Node.js attempts to execute codex as a raw binary. This fails immediately:

Error: spawn codex ENOENT
    at ChildProcess._handle.onexit (node:internal/child_process:286:19)

This error breaks /codex:setup and /codex:review on Windows. The spawnSync path in process.mjs was resolved in PR #13, but the asynchronous spawn path in app-server.mjs requires a similar fix.

Solution

plugins/codex/scripts/lib/app-server.mjs (+17/−1)

• Updates spawn("codex", ["app-server"]) to include shell: process.platform === "win32" and windowsHide: true. The platform guard leaves macOS and Linux behavior unchanged.
• Adds a Windows-specific branch to close() that calls terminateProcessTree(this.proc.pid) instead of SIGTERM. The shell: true option makes cmd.exe the direct child process; using SIGTERM terminates cmd.exe but leaves the node-based codex process orphaned. The call is wrapped in a try/catch block because it executes inside an unref'd timer during shutdown.

plugins/codex/scripts/lib/process.mjs (+2/−1)

• Adds windowsHide: true to the spawnSync options. This supplements the shell: process.platform === "win32" configuration from PR fix: resolve ENOENT for .cmd shims on Windows #13 for consistency.

Why not just shell: true?

Using shell: true resolves the ENOENT error but introduces two secondary issues on Windows:

• Zombie processes: Node.js spawns cmd.exe /d /s /c codex app-server. The existing SIGTERM logic in close() kills cmd.exe, but the node.exe grandchild survives. Testing showed 274+ orphaned node.exe processes accumulating across plugin reloads. terminateProcessTree uses taskkill /PID <pid> /T /F to terminate the entire tree.
• Console window flash: Every spawn call with shell: true briefly flashes a cmd.exe console window. The windowsHide: true option suppresses this using CREATE_NO_WINDOW.

Testing

Verified on Windows 11 running Claude Code with the codex plugin:

Scenario	Before	After
/codex:setup	spawn codex ENOENT	Completes successfully
/codex:review	spawn codex ENOENT	Completes successfully
Plugin reload (×10)	274 orphaned node.exe	0 orphaned processes
Console window flash	Visible cmd.exe popup	No visible window
macOS/Linux behavior	N/A (unchanged)	N/A (unchanged)

Related

Fixes: #32, #46

Related PRs:

• fix: add shell: true on Windows for codex app-server spawn #39 by @cadamsgcmlp — identifies the shell: true root cause; this PR builds on that insight by adding windowsHide and terminateProcessTree.
• fix: add shell option for Windows spawn in app-server #47 by @alexhuang0915 — independently identifies the same root cause.
• fix: resolve ENOENT for .cmd shims on Windows #13 (merged) — implements the original shell: true fix for spawnSync in process.mjs.

[zeta987]

I've added a follow-up commit to guard the delayed terminateProcessTree call against potential PID reuse on Windows.

Since ChildProcess.killed stays false when a child exits on its own, the 50ms timer could theoretically fire after cmd.exe has exited and its PID has been reassigned to an unrelated process.

Adding an exitCode === null check prevents this edge case by ensuring we only run taskkill while the child is still actively running:

if (this.proc && !this.proc.killed && this.proc.exitCode === null) {

Verified on Windows 11; local testing confirms that shutdown behavior remains correct.