Windows PowerShell: codex-gateway ignores custom command after -- and falls back to codex app-server

[zZacharyz]

Summary

On Windows PowerShell, codex-gateway does not reliably honor the custom Codex command passed after --.

Running:

codex-gateway -- C:\path\to\codex.exe app-server

still falls back to the default command:

[codex] Spawning: codex app-server

instead of using the provided executable path.

In addition, the default fallback spawn("codex") is not robust on Windows when Codex is installed through npm shims (codex.ps1 / codex.cmd) rather than being directly available as a native executable on PATH.

Environment

• OS: Windows
• Shell: PowerShell
• Node.js: v24.14.1
• @agentrq/codex-gateway: v0.1.2
• Codex CLI: codex-cli 0.142.0

What works

The MCP connection to AgentRQ succeeds:

[config] Loaded .mcp.json from D:\Codex_Study\agentrq_test\.mcp.json
[mcp] Connected to agentrq-0eAptv0iW7F

So this is not a workspace configuration issue.

Reproduction

Case 1: PowerShell + default launcher

Run from a directory containing a valid .mcp.json:

codex-gateway -- C:\Users\HP\AppData\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe app-server

Observed consistently on this machine:

[codex] Spawning: codex app-server
Error: spawn codex ENOENT

Expected:

[codex] Spawning: C:\Users\HP\AppData\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe app-server

Case 2: Bypassing the PowerShell shim

If I explicitly run the npm .cmd launcher for the gateway:

& C:\Users\HP\AppData\Roaming\npm\codex-gateway.cmd -- C:\Users\HP\AppData\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe app-server

then the custom executable path is honored and the log becomes:

[codex] Spawning: C:\Users\HP\AppData\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe app-server

This strongly suggests the argument forwarding through the PowerShell shim is the first issue.

Case 3: Default fallback is not Windows-robust

The current implementation falls back to:

const [codexCmd, ...codexCmdArgs] = codexArgs.length > 0 ? codexArgs : ["codex", "app-server"];

and later starts Codex with:

spawn(this.command, this.cmdArgs, {
  stdio: ["pipe", "pipe", "inherit"],
});

On Windows, codex is often resolved interactively through npm shims such as codex.ps1 / codex.cmd, so spawn("codex") is not equivalent to typing codex in PowerShell.

Source references

Installed package source:

• dist/index.js:150-153 parses process.argv and looks for a literal --
• dist/index.js:160-162 logs and starts the selected Codex command
• dist/codexClient.js:18-25 defaults to codex app-server and uses bare spawn(command, args)

Expected behavior

• codex-gateway -- <custom command> ... should reliably honor the custom command on Windows PowerShell.
• The default Codex spawn path should work on Windows when Codex is installed via the documented npm global install flow.

Likely root cause

This appears to be a combination of two Windows-specific issues:

1. argument forwarding through codex-gateway.ps1 does not preserve the literal -- delimiter the gateway expects
2. the fallback spawn("codex") is too optimistic for Windows/npm-shim environments

Suggested fixes

Potential fixes:

1. use a more Windows-friendly spawn strategy such as cross-spawn
2. add explicit Windows handling for .cmd / npm shim execution
3. support an explicit override such as CODEX_COMMAND or CODEX_BIN
4. document a Windows-specific launch command if the current README example is not portable

[zZacharyz]

Current Windows workaround:

& C:\Users\HP\AppData\Roaming\npm\codex-gateway.cmd -- C:\Users\HP\AppData\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe app-server

This avoids the PowerShell codex-gateway.ps1 shim and preserves the custom command after --.

In my tests, calling codex-gateway directly from PowerShell fell back to:

[codex] Spawning: codex app-server

while calling codex-gateway.cmd used the explicit codex.exe path correctly.

[zZacharyz]

Additional verification on the same Windows machine:

1. Direct Node spawn of codex fails the same way as the gateway fallback:

node -e "const {spawn}=require('child_process'); const p=spawn('codex',['--version'],{stdio:['ignore','pipe','pipe']}); p.on('error',e=>{console.error('ERROR',e.code,e.message); process.exit(2)}); p.stdout.on('data',d=>process.stdout.write(d)); p.stderr.on('data',d=>process.stderr.write(d)); p.on('exit',c=>process.exit(c??0));"

Output:

ERROR ENOENT spawn codex ENOENT

2. The workaround is not just a logging change. It reaches Codex end to end:

[codex] Spawning: C:\Users\HP\AppData\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe app-server
[codex] Connected to codex app-server
[bridge] Found task: "Next assigned task: ID: ..."
[codex] Created thread ...
[codex] Turn ... started
[codex] Turn ... completed
[codex] Reply sent to chat ...

So the current workaround does solve the launch problem on this machine, and Codex is able to connect and start processing tasks after bypassing the PowerShell shim.