Windows desktop: read-only Docker/localhost diagnostics rejected before execution with opaque 'blocked by policy'

Codex App version

Exact desktop build not verified. Attempting Get-AppxPackage from the current shell failed to load the Appx module (0x80131539); this is a separate version-discovery failure, not the policy rejection.

Subscription

Not collected.

Platform

Windows desktop app, local PowerShell workspace, Docker Desktop using WSL2. Incident observed September 12/13, 2026 (local time/UTC).

Actual behavior

A delegated local Codex task reported that exec_command rejected a read-only diagnostic batch before process creation:

CreateProcess ... rejected: blocked by policy
Wall time: 0.0 seconds

The abbreviated error above is the available sanitized task report, not a full raw trace. No diagnostic process was started and no stdout was produced.

The submitted batch was described as: enumerate Docker containers using ProcessStartInfo with an 8-second bounded wait, probe localhost login/MCP health with 3-second timeouts, and read the date/first lines of a local coordination file. It did not request restart, deletion, disk repair, installation, or database writes. The exact full batch is not included because it has not been extracted and independently redacted; this is an observed workspace incident, not a clean minimal reproduction.

Ordinary local file reads still work in the coordinating task. The current coordinating context reports danger-full-access and approval_policy=never; this does not establish the delegated task's complete effective policy or override other controls.

Manual comparison

The user ran the following directly in their own Windows PowerShell:

docker ps -a
curl.exe --max-time 3 -I http://127.0.0.1:3000/login

This succeeded: the expected application services were running, PostgreSQL and the networking sidecar were healthy, and the login endpoint returned HTTP 200. The user also successfully ran a transaction explicitly marked READ ONLY to check aggregate database counts, migration state, and index validity.

These manual commands establish local service availability; they are not identical to the rejected compound batch and do not prove which token or operation caused the denial.

Expected behavior

Execute permitted diagnostics. If a policy must deny them, return an actionable, stable reason identifying the relevant policy layer/rule and a supported resolution. Please investigate whether this is an intended denial with insufficient diagnostics, a compound-command classification false positive, or a task-specific runtime issue. This report does not request disabling or bypassing safeguards.

Impact

The workflow stopped and required the user to execute checks manually and paste results. Repeated explanation and task coordination consumed additional time and tokens. No reliable token total or causal accounting is available, so no numeric usage claim is made.

Related reports and limits

Potentially related: #40060 (compound PowerShell process/URL classification), #41779 (local API launch), #45145 (browser launch/diagnostic denial). This report concerns read-only Docker/service inspection rather than starting a server/browser or deleting files. A shared root cause is not established.

The rejected batch was not reshaped or rerun through an alternate execution channel to evade the denial. Full conversations, client data, database contents, cookies, credentials, private hostnames, and local user paths are intentionally omitted. No disk or database corruption is attributed to this tool rejection.

Start at the exec_command policy check and the Windows CreateProcess rejection path; compare the compound PowerShell/process and URL cases in #40060 and #45145. Reproduce with the smallest read-only Docker and localhost diagnostics available, then verify that permitted commands run or that denials identify the policy layer or rule and supported resolution.