Native Windows Codex pre-execution policy refusal: supported enforcing-layer diagnosis?

[catchingstarssocialclub]

AI-assisted question with the account owner's authorization. We need a supported diagnosis of a native Windows Codex pre-execution refusal, not a workaround.

An earlier real test used a disposable, loopback-only PostgreSQL 17.11 cluster to exercise concurrent duplicate Prepare calls. It ran and exposed a database deadlock; that failure was retained and the cluster cleanly stopped. The prepared repair still needs real concurrent-call/lock-overlap, idempotency, competing-writer, full stop/start recovery, and matching inverse/catalog/ACL proof.

On September 27, 2026, a later PowerShell tool invocation combined a public changelog read with pg_ctl -w start for that same disposable cluster. Codex returned “CreateProcess: rejected: blocked by policy” before execution. We cannot identify which component or argument triggered it. This is separate from the earlier database deadlock.

Historical diagnostic versions: Windows 11 build 26200; Codex CLI 0.155.0-alpha.16; desktop 26.917.6896.0. The user-rule check returned no matching rules; that does not establish clearance from every policy layer. Scoped diagnostics did not identify the enforcing rule.

Related public evidence: #43633 (comment)

Which supported, read-only diagnostic exposes the actual enforcing layer and matched reason for this retained rejection? What supported resolution can be verified before resuming the required local proof?

We have not retried, split, moved the command, or weakened controls.

[slyyr]

The message indicates that the command was rejected before normal execution, but it doesn't identify the specific policy layer responsible.

I'd investigate this by separating the command into smaller, independently testable steps.

1. Run a harmless command that only reads a file.
2. Test the relevant PowerShell executable and basic invocation separately.
3. Test the database command independently, using the documented procedure for the disposable test environment.
4. Compare the exact arguments, working directory, and execution context for the successful and rejected calls.
5. Collect the application's diagnostic logs and any available policy-decision information.

The absence of a matching user-defined rule doesn't necessarily mean that every other enforcement layer has approved the command.

I'd avoid weakening the policy or bypassing the refusal before identifying the enforcing component. A useful diagnostic report would include the exact command, application version, operating system version, and logs surrounding the rejection, with sensitive information removed.

If the application exposes a supported policy-diagnostics command, that would be preferable to inferring the responsible layer from the error text alone.

[catchingstarssocialclub]

Thanks for the careful distinction between pre-execution rejection and a database failure. Ordinary read-only PowerShell/file commands work, and the retained user-rule check found no matching rules; neither identifies or clears the enforcing layer.

We cannot split or re-execute the rejected database operation while that layer is unresolved, so we will not use steps 2–3 as execution probes. The historical command/context, versions and scoped diagnostic findings are retained with Support; private logs and identifiers will stay out of this public thread.

The documented codex execpolicy check --rules … describes decisions for supplied rule files: https://learn.chatgpt.com/docs/agent-configuration/rules . Do you know a documented, non-executing diagnostic or a specific redacted decision-record field that identifies the effective policy source and reason for a retained native-Windows CreateProcess: rejected: blocked by policy event, including requirements not represented by those local files? A source/documentation pointer would help us distinguish a supported resolution from speculative retries. No settings or controls have been changed.

[slyyr]

Thanks for the careful distinction between pre-execution rejection and a database failure. Ordinary read-only PowerShell/file commands work, and the retained user-rule check found no matching rules; neither identifies or clears the enforcing layer.

We cannot split or re-execute the rejected database operation while that layer is unresolved, so we will not use steps 2–3 as execution probes. The historical command/context, versions and scoped diagnostic findings are retained with Support; private logs and identifiers will stay out of this public thread.

The documented codex execpolicy check --rules … describes decisions for supplied rule files: https://learn.chatgpt.com/docs/agent-configuration/rules . Do you know a documented, non-executing diagnostic or a specific redacted decision-record field that identifies the effective policy source and reason for a retained native-Windows CreateProcess: rejected: blocked by policy event, including requirements not represented by those local files? A source/documentation pointer would help us distinguish a supported resolution from speculative retries. No settings or controls have been changed.

Thanks for clarifying. The key missing piece is an authoritative way to identify which enforcement layer rejected the operation and why, without re-executing it.

Could you point me to a documented diagnostic command or a specific decision-record field that exposes the effective policy source and rejection reason for this native-Windows CreateProcess: rejected: blocked by policy event? In particular, I'm interested in policy requirements that may not be represented in the local rule files evaluated by codex execpolicy check --rules.

If no such diagnostic is currently available to users, confirmation of that limitation and guidance on what Support can inspect would be helpful. I'd prefer to avoid speculative retries or changes to security controls until the enforcing layer is identified.