Windows: local Markdown QA report write rejected before execution with "blocked by policy", no review entry

Summary

Codex Desktop on Windows rejected a user-authorized command intended to read public local candidate files, verify their hashes, and exclusively create a new Markdown static-QA report. The rejection occurred before the report-writing process started.

The visible error was:

exec_command failed: CreateProcess ... rejected: blocked by policy

This is a request to identify the enforcing policy and the supported review path, not a request to disable safeguards.

Environment

• Windows 11, Codex Desktop.
• Exact app/core version at the time of rejection: not yet verified.
• Model and subscription at the time of rejection: not yet verified.
• The affected task reported approval_policy=never.
• The submitted command used the bundled PowerShell executable, a here-string containing Python code, and an existing local Python interpreter with -I -S -B -c.

Intended operation

The command would:

1. Read an existing public candidate JSON and public control programs.
2. Verify expected byte lengths, SHA256 values, and file metadata.
3. Exclusively create one new Markdown QA report using Python open("xb").
4. Read back the report and print its public file metadata.

It did not execute UAC, the diagnostic probe being reviewed, symlink creation, deletion, ACL/owner changes, or a network service. The report text describes those testing boundaries; that text is not executed.

The underlying project uses synthetic local test materials. Exact local paths and project contents are intentionally omitted here.

Observed result

• The tool rejected the command before the report-writing process started.
• There was no program exit code.
• No rule ID, detailed denial rationale, approval ID, or actionable review entry was exposed.
• The visible tool error itself contained a truncation marker, so the full internal rejection text is unavailable.
• The report remains unwritten. The candidate remains pending and downstream execution is paused.
• No alternate execution channel, permission weakening, or replay of this denied write was used to bypass the rejection.

This is an observed incident in an existing task, not a standalone deterministic minimal reproduction.

Requested clarification

1. Which component and policy/rule rejected this exact operation?
2. How can the full rejection reason and corresponding call identifier be obtained?
3. Is there a supported action-specific review procedure in the Windows desktop app for this denial?
4. If the restriction is intentional, please explain its applicable scope.

Feedback reference

In-app feedback was successfully submitted:

01a09a3f-ecfb-7761-a5a1-144bf78529cb

This is the identifier displayed by the feedback submission dialog, not an asserted approval ID.

Related reports

• #41779
• #44430

These have similar pre-execution rejection symptoms, but concern service/tunnel launches. This report concerns a local Markdown report write. A shared root cause has not been established.

No credentials, private source code, raw session logs, or real user data are attached. If additional diagnostics are needed, please specify the smallest useful scope and an appropriate submission channel.

Start by comparing the observed Windows desktop rejection with related reports #41779 and #44430, then review the policy-handling entry points for pre-execution command denials. Done means identifying the enforcing component and rule, explaining how to obtain the complete reason and call identifier, and documenting any supported action-specific review path.