Windows desktop: CreateProcess blocked by policy without actionable per-call denial details

Observed problem

In Codex desktop on Windows, an owner-authorized request to start a loopback-only static website preview was rejected before process creation. The exposed error was exec_command failed: CreateProcess ... rejected: blocked by policy. The response did not identify the enforcing component, matched rule, reason, or supported review path.

This report requests per-call diagnosis and a supported remedy, not a safeguard bypass.

Correlation details

• Dispatch UTC: 2026-10-30T19:25:55.207Z
• Rejection UTC: 2026-10-30T19:25:55.434Z
• Tool-call ID: call_6a1d78f868774acaab455820ca515573
• UI-labelled Feedback ID: 01a12241-5919-77d0-b4d1-e9e6ba716113
• In-app submission was confirmed by the user's "Feedback submitted" dialog. This does not establish investigation or remediation.

Bounded findings and limitations

• The original action used PowerShell to request a hidden Python static reader bound to loopback. The original command, paths, and transcript are not attached.
• A read-only codex execpolicy check evaluated the exact original argv as data against one explicit current local rules file: exit 0, matchedRules: [], with no allow verdict. This is not a check of every effective or historical policy layer.
• The diagnostic CLI identified itself as 0.163.0-alpha.11; the desktop UI and dynamic execution-backend versions have not been independently verified.
• The bounded original transcript window exposed no matched-rule or approval/reviewer decision metadata.
• After the initial refusal, the agent started a tool-managed foreground preview once, then stopped it on recognizing that the refusal scope was unclear. No preview listener was retained, and no further launch attempt or policy change followed. The original denied command was not replayed.

This is the original observed sequence, not a newly verified minimal reproduction.

Requested resolution

Please correlate the call and feedback identifiers, identify the actual enforcing component/rule and reason, and specify the supported incident-specific review or remediation path and its verification steps, if one exists. A response will not be treated as permission for unrelated deployment or broader security changes.

Related symptom reports: #54206 and #57623. A shared root cause is not established; the identifiers above concern a separate call.

The user explicitly authorized this sanitized public report. No credentials, local/private paths, client assets, account contents, screenshots, raw logs, or conversation transcript are included.