Windows: Full Access rejects benign process launch + loopback health check on 0.153.4

On Windows, Codex repeatedly rejects a benign local process launch and loopback health check with "CreateProcess ... Rejected: blocked by policy", even when the task is using Full Access. This interrupts local rendering and development workflows, and the error does not explain which part of the command caused the rejection.

We reproduced this on codex-cli 0.153.4 with gpt-6-astra, reasoning effort high. The effective settings returned by app-server for the diagnostic run were approvalPolicy=never, approvalsReviewer=user, and sandbox.type=dangerFullAccess. These were the actual per-run settings, not merely values read from config.toml. The host is Windows 11 Pro 25H2, x64, OS build 26200.9445. The shell executable used by the diagnostic tool reports PowerShell 7.6.5. The installed Codex Desktop package version is 26.908.4834.0; the executable used in the test reports codex-cli 0.153.4.

The minimal reproduction was the compound PowerShell fixture from #40060: start a hidden Windows cmd.exe process with arguments /c exit 0, store the returned process object, then run Invoke-RestMethod against http://127.0.0.1:9/health with a one-second timeout inside try/catch, and finally print the process ID. It does not delete or modify files. The fixture was submitted as one unchanged command. Raw tool-call and tool-output records confirmed that the submitted command exactly matched the fixture and that rejection occurred before PowerShell started, with a reported wall time of 0.0 seconds. No approval request was emitted.

The rejection was reproduced in an ephemeral app-server test configured to connect directly to the official ChatGPT Codex backend. The installed executable's OpenAI Authenticode signature was valid.

We also parsed the fixture without executing it using PowerShell's Parser.ParseInput. It reported zero syntax errors and separate CommandAst nodes for Start-Process and Invoke-RestMethod. The HTTP URL belongs to the health-check command, not to the process-launch command.

This appears to be the same Windows classifier false positive described in #40060, now independently reproduced on 0.153.4. In windows_dangerous_commands.rs, is_dangerous_powershell_words checks for a URL across the flattened words and separately checks for Start-Process. In exec_policy.rs, a dangerous classification with approval policy never becomes Forbidden. This is a source-based explanation consistent with our reproduction; the tool error itself did not expose an internal rule identifier.

Expected behavior: an unrelated loopback HTTP request should not cause a benign local executable launch to be classified as a URL launch. Please preserve review for genuinely dangerous operations while correcting this false positive. If a command must still be rejected, an actionable explanation would also help users distinguish a classifier issue from AGENTS.md instructions or an approval-mode mismatch. We are not requesting unrestricted approval of destructive commands.

Related issue: https://github.com/openai/codex/issues/40060

The results above are a text-only summary of local tests performed on September 12, 2026. No private paths, authentication data, or conversation logs are attached.

Scope: this report concerns the process-launch/HTTP-check false positive. The diagnostic used the existing Windows user configuration; a pristine-profile comparison was not performed.

Start by reading windows_dangerous_commands.rs, especially is_dangerous_powershell_words, and then inspect how exec_policy.rs turns dangerous classifications into Forbidden under approvalPolicy=never. Reproduce the unchanged PowerShell fixture from the issue and verify that its unrelated loopback URL no longer causes the benign Start-Process launch to be rejected while genuinely dangerous operations remain reviewed.