Codex Security 0.1.14 Deep Scan fails with spawn EPERM on Windows when CODEX_CLI_PATH is unset

[d0gx]

Summary

Codex Security 0.1.14 Deep Scans fail before discovery on Windows when CODEX_CLI_PATH is unset and PATH resolves codex to the extensionless npm shim.

The Deep Scan worker ultimately calls Node's child_process.spawn with the literal command codex. On this PATH layout, Windows selects %APPDATA%\npm\codex (the extensionless npm shim) and Node returns EPERM. The plugin should resolve a Windows-executable launcher (codex.cmd / codex.exe) or use the Codex executable bundled with the desktop app.

Environment

• Windows 10.0.26200.8894, x64
• ChatGPT desktop app 26.721.4979.0
• Codex Security plugin 0.1.14 (hosted catalog)
• Codex CLI: reproduced with 0.145.0; the minimal launcher reproduction remains on 0.146.0
• Node.js v24.15.0
• PowerShell 5.1.26100.8894
• Codex CLI installed globally through npm
• CODEX_CLI_PATH unset

Steps to reproduce

1. On Windows, install Codex CLI globally through npm so %APPDATA%\npm is on PATH and contains the extensionless codex shim.
2. Leave CODEX_CLI_PATH unset.
3. In the ChatGPT desktop app with Codex Security 0.1.14, start a Deep Security Scan on a local Git repository.
4. Complete setup and allow the preflight to pass.
5. Wait for discovery workers to launch.

Actual behavior

Deep discovery terminates immediately with spawn EPERM. No worker completes and no candidates are produced. Sanitized coordinator result:

{
  "status": "failed",
  "discoveryCount": 0,
  "failure": {
    "phase": "discovery",
    "message": "spawn EPERM",
    "kind": "Error:EPERM"
  }
}

The standalone launcher behavior is reproducible:

node -e "const {spawn}=require('child_process'); spawn('codex',['--version'])"
# Error: spawn EPERM

Spawning the direct npm-installed codex.exe from Node succeeds and prints codex-cli 0.146.0.

Expected behavior

Deep Scan should resolve and launch a valid Windows Codex executable without requiring users to configure CODEX_CLI_PATH manually.

Workaround

Set CODEX_CLI_PATH to the direct npm-installed codex.exe and restart the desktop app.

Suggested fix

On Windows, avoid passing the bare literal codex to child_process.spawn when the extensionless npm shim may win PATH resolution. Resolve codex.cmd / codex.exe, use the SDK's platform binary resolver, or pass the desktop-bundled executable path to the plugin MCP process.

[raederhans]

I can reproduce this on a newer build, with an important variation: CODEX_CLI_PATH is configured in the thread shell environment and points to a working direct npm-installed binary, but the Codex Security MCP Deep Scan worker still fails with spawn EPERM.

Environment

• Windows 10.0.26200.8875, x64
• Codex desktop app 26.727.6591.0
• Codex Security plugin 0.1.15
• Node.js 22.23.0
• Direct npm Codex CLI: 0.144.6
• App-local unpacked Codex CLI: 0.146.0-alpha.9.2

Deep Scan result

Capability preflight completed successfully and deterministic setup completed. Discovery then failed before any worker produced output:

{
  "status": "failed",
  "discoveryCount": 0,
  "failure": {
    "phase": "discovery",
    "message": "spawn EPERM",
    "kind": "Error:EPERM"
  }
}

The failed discovery execution reached attempt 4. The scan was then terminal and could not be resumed.

Binary-resolution checks

In the same Codex thread shell:

node -e "const {spawn}=require('node:child_process'); spawn('codex',['--version'])"
# succeeds: codex-cli 0.144.6

node -e "const {spawn}=require('node:child_process'); spawn(process.env.CODEX_CLI_PATH,['--version'])"
# succeeds: codex-cli 0.144.6

Spawning the packaged executable used by the desktop app reproduces the Deep Scan error:

C:\Program Files\WindowsApps\OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
Error: spawn EPERM
errno: -4048
syscall: spawn

Both unpacked per-user executables work:

%APPDATA%\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe
%LOCALAPPDATA%\OpenAI\Codex\bin\<version>\codex.exe

This suggests the Deep Scan MCP process is not inheriting the thread's configured CODEX_CLI_PATH, or it is receiving/resolving a different value that points to the protected WindowsApps package. The failure appears specific to the MCP/SDK worker launch boundary rather than repository code or general Node child-process creation.

Related WindowsApps executable-resolution reports: #20048 and #19271.