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

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.

I can reproduce this again on a newer Codex Security version, after this issue was closed as completed.

Environment

• Windows 11 Pro 25H2 x64, build 26200
• Codex Desktop / MSIX
• Codex CLI: 0.147.0-alpha.6.6
• Codex Security plugin: 0.1.19
• Windows sandbox: elevated

Reproduction

Codex Security Deep Scan failed before source discovery with:

spawn EPERM

Diagnostics showed that the worker launcher ultimately resolved codex to the protected MSIX executable:

C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\codex.exe

Direct Node reproduction:

child_process.spawn("codex", ["--version"])
→ EPERM

Spawning the absolute WindowsApps codex.exe also returned EPERM.

However, the user-local native Codex CLI worked:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\<build-hash>\codex.exe

codex-cli 0.147.0-alpha.6.6

pwsh.exe and cmd.exe also spawned successfully from Node, so this was not a general child-process restriction.

After prepending the directory containing the native user-local codex.exe to PATH, the exact Node spawn mechanism succeeded:

spawnSync("codex", ["--version"])

status = 0
error = undefined
stdout = codex-cli 0.147.0-alpha.6.6

After this workaround, Deep Scan was able to proceed past worker launch.

Additional ENOENT failure mode

There was also an intermediate failure mode when running from Codex CLI:

spawn codex ENOENT

The Security MCP environment contained npm/PowerShell wrappers such as codex.ps1 and codex.cmd, but no directly spawnable native codex.exe in the effective PATH.

Node child_process.spawn("codex", ...) does not use PowerShell to resolve .ps1 wrappers.

Prepending the actual native Codex binary directory fixed this as well.

Expected behavior

Codex Security discovery workers should resolve and launch an executable that is valid in the current Windows execution context.

On Windows, the launcher should prefer an accessible native CLI / validated CODEX_CLI_PATH instead of resolving to the protected WindowsApps executable or depending on a shell-specific wrapper.

Related issue

This may also be related to #29365, where Codex Desktop generates a wrapper that selects the protected WindowsApps codex.exe instead of the accessible local CODEX_CLI_PATH.

The important point here is that the original Codex Security spawn EPERM failure is still reproducible with Codex Security 0.1.19.