Windows: read-only health-check launch and full-wrapper execpolicy diagnostic rejected with opaque "blocked by policy"

Summary

Codex Desktop on Windows repeatedly rejects an explicitly authorized, read-only database health-check launch through exec_command with only:

exec_command failed: CreateProcess { message: "Rejected(... rejected: blocked by policy)" }

The tool reports a wall time of 0.0 seconds. The health-check process does not start, so there is no Python/SQLite exception or query result explaining the rejection.

Please identify the enforcing policy/rule and the supported resolution. We are not requesting a bypass or a blanket allow rule.

Environment

• Windows desktop package: OpenAI.Codex 26.901.4073.0 (read from Get-AppxPackage).
• OS: Microsoft Windows NT 10.0.26220.0.
• PowerShell: 7.6.5.
• Python: 3.12.10, verified by a successful hidden-process version probe.
• Incident and diagnostics: September 8, 2026, Asia/Taipei (UTC+08).
• Existing local Git project, canonical Windows working directory.
• Actual task logs record approval_policy=Never and sandbox_policy=DangerFullAccess.
• User config defaults differ: sandbox_mode="read-only", approval_policy="on-request". The task log is reported separately from those defaults, not assumed to inherit them.

Observed reproduction in the affected task

1. Obtain the existing local dashboard's data-root path using a read-only HTTP health request.
2. Prepare a hidden Python child with System.Diagnostics.ProcessStartInfo, UseShellExecute=false, CreateNoWindow=true, and redirected stdout/stderr.
3. Pass arguments separately with ArgumentList:
   -B system/tools/dashboard_data_lifecycle.py health --data-root <existing-data-root>.
4. Submit through exec_command.
5. Receive the above pre-execution policy rejection.

The script's health branch was inspected: it opens source SQLite databases with mode=ro and PRAGMA query_only=ON, and inspects schema/index/query plans. No migration, maintenance, deletion, deep-integrity scan, or equipment command was requested. The rejected retry omitted --output, so no report-file write was requested either. The same script contains other maintenance subcommands, but none was invoked; whether that matters to the rejection is unknown.

This is a repeated failure in the existing workspace/task, not a verified clean-project or universally reproducible minimal example. Private database files and application source are not attached.

Diagnostic controls and limits

• Hidden Python launch with only --version: succeeded, exit 0.
• A separate hidden Python diagnostic reading the local Codex log database with SQLite mode=ro and PRAGMA query_only=ON: succeeded. The bounded query used the existing thread/time index. Thus, Python child creation and SQLite reads are not universally blocked.
• User default.rules: 32 allow entries, zero prompt/forbidden entries.
• codex execpolicy check against that user rule file and the inner Python argument list returned {"matchedRules":[]}, exit 0. This does not establish the decision for the full shell wrapper or all effective policy layers.
• A later attempt to evaluate the full rejected shell command as data with execpolicy check (not execute the health check) was itself rejected by the execution tool. Therefore, no complete-wrapper policy-check result is available.
• No extra rules were found in the project/ancestor and common ProgramData locations inspected. This is not proof that no remotely managed policy exists.
• Accessible application/task logs confirmed effective task permissions, but did not expose the specific denying rule, reason code, or actionable approval item.

No security rules were modified, and the blocked health-check operation was not rerouted through another execution channel.

Impact

An authorized nightly data-quality/indexing workflow cannot verify its source databases. It must leave its completion checkpoint unchanged and report partial coverage. A generic rejection provides no way to distinguish intended protection, a command-shape limitation, or a false positive.

Requested clarification

1. Which component made this rejection, and which rule/reason code applies?
2. Can the error expose a safe diagnostic/correlation ID and the relevant reason without disclosing internal policy?
3. Why can the non-executing rule diagnostic containing the command text also be rejected?
4. What supported, narrowly scoped approval or remediation is available for this read-only operation?
5. If this is expected behavior, please document it; if it is a false positive, please advise how to provide a privacy-safe minimal reproduction.

Related reports: #41779 and #43629. Similar symptoms do not establish the same root cause.

Privacy

This report omits internal IPs, share names, user paths, task/session identifiers, credentials, resident/guest data, raw database contents, and full conversation/log uploads.

Start with the reported exec_command rejection, the codex execpolicy check command, and system/tools/dashboard_data_lifecycle.py's health branch. Compare the successful --version, SQLite diagnostic, and inner-argument checks with the rejected full wrapper. Done means identifying the enforcing component and reason or correlation ID, then documenting a supported narrow remediation or privacy-safe minimal reproduction.