Windows desktop Full access: forced test-file cleanup denied with opaque blocked by policy and no review path #45403

Summary

On Windows, the desktop permission menu offers Full access under “How should ChatGPT actions be approved?”, described as “Unrestricted access to the internet and any file on your computer”. However, an explicitly authorized cleanup of agent-created test files using PowerShell Remove-Item -LiteralPath ... -Force is rejected before execution with only blocked by policy, and no approval/review option.

The dangerous-command safeguard appears intentional. This report concerns the misleading permission-mode expectation, opaque rejection, and absence of an actionable recovery path in the error. It does not request removing safeguards.

Environment

• Windows, PowerShell 7, desktop app
• Bundled executable reports codex-cli 0.153.4; desktop app version not collected
• Selected UI mode: Full access
• Effective session settings: approval_policy = never, sandbox_mode = danger-full-access
• Inspected user execution rules contained allow rules, no explicit forbid rule

Observed behavior

The agent created two 8 GiB files for an application copy-cancellation test. Cleanup was authorized. Both a guarded cleanup command and a subsequent command naming only those two files were rejected before process creation. The narrower command had this shape (paths anonymized):

Remove-Item -LiteralPath 'F:/project/artifacts/test/source/test.bin','F:/project/artifacts/test/destination/test.bin' -Force

Tool error ended with rejected: blocked by policy. No matching rule, explanation of Full access limitations, or review action was supplied. Files remained on disk.

Minimal reproduction proposal

Use a disposable file in a test workspace, select Full access, and request cleanup using Remove-Item -LiteralPath <test-file> -Force.

The original cleanup rejection was observed. This smaller reproduction is proposed from the matching source/tests and has not been rerun; no alternate deletion mechanism was used to bypass the rejection.

Source evidence for the bundled version

1. has_force_delete_cmdlet classifies a delete cmdlet plus -Force in the same command segment as dangerous, with an explicit test for Remove-Item test -Force:
   https://github.com/openai/codex/blob/rust-v0.153.4/codex-rs/shell-command/src/command_safety/windows_dangerous_commands.rs
2. PowerShell dangerous matches map to DangerousCommandMatch::Other:
   https://github.com/openai/codex/blob/rust-v0.153.4/codex-rs/shell-command/src/command_safety/is_dangerous_command.rs
3. A dangerous match with AskForApproval::Never returns Decision::Forbidden; the Other rejection reason is only blocked by policy:
   https://github.com/openai/codex/blob/rust-v0.153.4/codex-rs/core/src/exec_policy.rs

This explains how full filesystem access and disabled approval prompts can still produce a hard rejection. It is not apparent from the UI wording.

Expected behavior

• Clarify in Full access help that some command safety checks can still deny actions outright.
• Report the actual matched rule and why the current approval mode cannot request review.
• Give an actionable, supported route to a user-reviewed decision where policy permits, instead of an unexplained dead end.
• Clarify whether users should select Ask for approval or Approve for me to recover from this specific condition.

Related reports

Related: #43905 (same CLI version, Full access blocked) and #10827 (earlier never/full-access behavior). This report adds the Windows PowerShell cleanup trigger, exact desktop menu wording, and matching version-specific source chain.