Review mode blocks all commands on Windows: sandbox policy rejects PowerShell

[0xZOne]

Bug description

When running /codex:review on Windows, the Codex review produces no useful output because every shell command is rejected by the sandbox policy in the app-server path.

Observed behavior

All commands are declined with blocked by policy:

ERROR codex_core::tools::router: "powershell.exe" -Command 'git status --short' rejected: blocked by policy
ERROR codex_core::tools::router: "powershell.exe" -Command 'Write-Output hi' rejected: blocked by policy

The review output:

Shell access to inspect the working tree was blocked in this session, so I could not review the staged/unstaged/untracked changes directly.

Key detail: Git Bash environment

Our Claude Code session uses Git Bash as its shell, but Codex CLI ignores this and defaults to PowerShell for all command execution on Windows.

Investigation & root cause

We tested three approaches:

Approach	Result
codex review -c 'sandbox_permissions=["disk-full-read-access"]' (CLI direct)	Works — review completes successfully
config.toml with sandbox_permissions = ["disk-full-read-access"] + plugin app-server path	Fails — config not respected by app-server
Plugin app-server path (default sandbox: "read-only")	Fails — all commands blocked

Root cause: The app-server's thread/start RPC accepts a sandbox parameter (read-only / workspace-write / danger-full-access) but does not accept sandboxPermissions. The read-only sandbox mode on Windows blocks all PowerShell commands, including purely read-only ones like git status --short and Write-Output hi. The config.toml sandbox_permissions setting is only respected by the direct CLI path, not the app-server.

This means:

1. The plugin cannot work around this issue — it has no way to pass sandbox permissions through the app-server protocol
2. The fix must be in codex-cli core: either the read-only sandbox mode needs to properly handle Windows/PowerShell, or the app-server thread/start protocol needs to support sandboxPermissions

Steps to reproduce

1. Windows 11, with Git Bash as the shell in Claude Code
2. Node.js v22.17.0, codex-cli 0.117.0, codex-plugin-cc v1.0.1
3. Have a repo with uncommitted changes
4. Run /codex:review in Claude Code
5. All commands are "blocked by policy" and review returns empty

Suggested fix (codex-cli core)

Either:

• Option A: Make read-only sandbox mode on Windows allow read-only shell commands via PowerShell (consistent with bash behavior on macOS/Linux)
• Option B: Add sandboxPermissions support to the app-server thread/start protocol, so the plugin can pass ["disk-full-read-access"]
• Option C: Have the app-server respect config.toml sandbox_permissions when creating threads

Workaround (CLI only)

Users can bypass the issue by using codex review directly from the terminal:

codex review --uncommitted -c 'sandbox_permissions=["disk-full-read-access"]'

This does not help when using the plugin via /codex:review.

Environment

• OS: Windows 11 Pro (10.0.22631)
• Shell (Claude Code): Git Bash
• Shell (Codex): PowerShell (hardcoded)
• Node.js: v22.17.0
• codex-cli: 0.117.0
• codex-plugin-cc: v1.0.1

Related

• spawn() in app-server.mjs fails with ENOENT on Windows #53 / fix: add shell: true to spawn() in app-server for Windows #54 — another Windows compatibility issue (spawn ENOENT)
• This is primarily a codex-cli core issue (codex_core::tools::router policy + app-server protocol), filed here for visibility since the plugin is the entry point.

[amarmehdaouiocb]

Confirming we hit this bug on Windows 11 Pro + Git Bash with codex-plugin-cc v1.0.3 + codex-cli 0.119.0-alpha.20.

Observed behavior on /codex:adversarial-review

powershell.exe -Command Get-Content ... and git branch --all --verbose are declined silently (exit -1) in the read-only sandbox, while git diff --stat and findstr are allowed. Codex launches 3–4 parallel commands per turn; roughly half are rejected, and the remaining signal is too sparse for a useful review. The job never converges — in our case it sat in running state for 1h43m with no further progress after the first ~2 minutes of investigation, eventually orphaning the codex process.

Log excerpt (anonymized)

Running command: pwsh.exe -NoProfile -Command 'git branch --all --verbose'
Command declined: pwsh.exe -NoProfile -Command 'git branch --all --verbose' (exit -1)
Running command: pwsh.exe -NoProfile -Command "Get-Content -Path 'apps/..."
Command declined: pwsh.exe -NoProfile -Command "Get-Content -Path 'apps/..." (exit -1)

Why #178 (Git Bash shell) did not fix this for us

#178 makes Codex honor process.env.SHELL on Windows, but our codex-cli binary still spawns PowerShell for command execution inside the app-server sandbox regardless. The read-only policy is what blocks the commands, not the shell selection.

Workaround we're using

Local patch to scripts/codex-companion.mjs and scripts/lib/codex.mjs that reads CODEX_PLUGIN_SANDBOX_MODE from env and passes it through in place of the hardcoded read-only:

sandbox: process.env.CODEX_PLUGIN_SANDBOX_MODE || "read-only",

With CODEX_PLUGIN_SANDBOX_MODE=danger-full-access set in our shell, both /codex:review and /codex:adversarial-review complete end-to-end. Adversarial-review is review-only by prompt contract so Codex doesn't actually write anything in practice — but this is obviously only acceptable on a trusted dev machine.

+1 for #167's proposal (env var + per-call --sandbox flag). The patch above works but gets clobbered on every plugin update, and silent "no output" reviews are hard to diagnose. An explicit failure mode ("sandbox init refused all commands — set CODEX_PLUGIN_SANDBOX_MODE to override") would have saved hours here.

Happy to test a fix branch.