[Windows][Codex App] Exact user-authorized file deletion blocked by policy before PowerShell starts

Summary

On Windows, Codex Desktop rejects an explicitly authorized deletion of one exact local file before PowerShell starts, even with full-access settings enabled. The tool wrapper returns only:

rejected: blocked by policy
wall time: 0.0 seconds

No file was deleted.

This appears related to #34331, but is reported separately because it affects an ordinary single-file deletion outside a selected workspace, not only Git-ignored cache directories.

Environment (sanitized)

• Codex Desktop app version: 26.810.52044
• Windows
• sandbox_mode = "danger-full-access"
• Windows sandbox: elevated
• Filesystem profile: unrestricted
• The operator explicitly authorized deletion of one exact local PDF file

Reproduction

1. Ask Codex Desktop to delete one exact local file using an absolute path.
2. Codex successfully runs a read-only preflight such as Get-Item -LiteralPath ... and confirms the target is a single file.
3. Codex then attempts a direct PowerShell deletion using:

Remove-Item -LiteralPath $target -Force -ErrorAction Stop

1. The wrapper rejects the command before PowerShell starts with rejected: blocked by policy.

The same result occurred when attempting a small, explicitly enumerated cleanup of Codex cache/log/archive paths.

Additional observation: behavior varies across conversations

The deletion block is not fully deterministic from the operator's perspective. In some Codex Desktop conversations, similarly explicit local file deletions have succeeded; in other conversations, the same class of deletion fails before PowerShell starts with rejected: blocked by policy.

This suggests the effective policy may depend on per-conversation/task context, workspace registration, runtime state, or another hidden policy layer, rather than only the visible global settings (danger-full-access, elevated, and unrestricted filesystem profile). We have not identified a reliable condition that predicts when an exact, user-authorized deletion will be allowed versus rejected.

Expected behavior

I understand why Codex must block broad, unresolved, or recursive destructive commands. However, for an operator-authorized, exact, preflight-validated single-file path, it would be helpful to have one of these supported outcomes:

1. Allow the action when it is within an explicitly authorized boundary.
2. Show a one-time exact-path approval prompt.
3. Offer a recoverable delete (Recycle Bin) action.
4. Return a rule identifier and the matched reason, so users can distinguish intentional protected-path behavior from a false positive.

Questions

• Is deletion outside the selected workspace or below the user profile intentionally blocked in Codex Desktop even under danger-full-access?
• Is there a supported way to grant one-time, exact-path deletion permission without weakening global safety controls?
• Is this expected to be fixed as part of #34331?
• Is there a supported diagnostic view or API for the effective per-conversation/task execution policy?

No local paths, filenames, account data, credentials, or file contents are included in this report.