[Windows][Codex App] Path-bound deletion of ignored cache directories is rejected with a generic policy block under danger-full-access

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex 26.715.7063.0

Bundled/local CLI observed in the same environment: codex-cli 0.145.0-alpha.20.

What subscription do you have?

ChatGPT Pro (20x)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64
Windows 11 Pro, build 26200
PowerShell 7.6.3

What issue are you seeing?

Codex App rejected an explicitly authorized, path-bounded cleanup of local
Git-ignored cache directories before the PowerShell process started.

The task was running with:

sandbox_mode: danger-full-access
approval_policy: never
filesystem profile: unrestricted
workspace: an explicitly selected local workspace owned by the operator

Before attempting deletion, the agent created a pre-delete manifest and
validated nine exact directories across two registered Git worktrees:

• basenames were exactly __pycache__ or .pytest_cache;
• every resolved target remained below its explicitly named worktree root;
• all nine paths were confirmed by git check-ignore;
• git ls-files found zero tracked members in every target;
• protected path segments (.git, .runtime, .loci, tmp, sandbox) were

rejected;

• no other process command line referenced any exact target;
• aggregate scope was 9 directories, 191 files, 8,819,141 bytes;
• rollback was regeneration through normal compilation or tests.

Only after those checks, the command would have called:

Remove-Item -LiteralPath $resolvedExactTarget -Recurse -Force -ErrorAction Stop

The tool wrapper rejected the entire command before execution:

rejected: blocked by policy
wall time: 0.0 seconds

No target was deleted and no shell-side validation ran. The response contained
no rule ID, matched risk feature, approval path, or indication of whether the
block came from recursive deletion, multiple exact paths, PowerShell syntax,
dynamic-but-resolved targets, or another policy layer.

I agree that Codex must block unresolved variables, workspace roots, user-profile
roots, drive roots, and broad destructive commands. This report is about the
opposite failure mode: a fully evidenced, operator-authorized, recoverable local
cleanup cannot proceed or request a narrower one-time authorization.

What steps can reproduce the bug?

Observed once in Codex App on Windows. I did not retry or reshape the rejected
command because the repository policy requires stopping after a host-policy
denial.

A safe disposable-repository reproduction would be:

1. Create a temporary Git repository containing .gitignore with

.pytest_cache/ and __pycache__/ entries.

1. Create one ignored cache directory with a disposable file.
2. Run Codex App locally with sandbox_mode = "danger-full-access" and

approval_policy = "never".

1. Explicitly ask Codex to delete only that exact ignored and untracked cache

directory.

1. Require Codex to resolve the canonical path, prove containment, run

git check-ignore, prove zero tracked members, and materialize a rollback
receipt before deletion.

1. Observe whether the command is rejected before PowerShell starts with the

generic message blocked by policy.

The actual observation used nine targets, but the minimal one-target case
has not yet been run because retrying after denial was intentionally avoided.

What is the expected behavior?

Codex should preserve strong protection against broad or unresolved recursive
deletion while providing one of these outcomes for a fully bounded local action:

1. Allow the operation when the operator explicitly authorizes exact canonical

paths inside the selected writable workspace and the agent proves that the
targets are ignored and untracked.

1. Surface a one-time, exact-path approval that cannot widen to parent paths,

sibling paths, workspace roots, user-profile roots, or drive roots.

1. Offer a recoverable deletion primitive (Recycle Bin/trash) with a manifest

and restoration receipt.

1. If denial remains mandatory, return a stable policy/rule identifier and the

matched risk characteristic so the action can be safely redesigned or a
false positive can be reported without guessing.

approval_policy = "never" should not turn an otherwise approvable local
operation into a generic, non-actionable failure. A documented exact-path grant
or recoverable-delete mechanism would keep the safety boundary while preserving
operator control over their own workspace.

Additional information

• Existing-issue search found reports of destructive deletion being too

permissive, including #32684. Those incidents justify strong recursive-delete
protection. This report asks for a narrow safe path that does not weaken those
protections.

• No matching open issue was found for this exact false-positive shape using

searches for execpolicy false positive Windows, blocked by policy false
positive, approval never command rejected, and Remove-Item Recurse Force
blocked.

• No credentials, customer data, private file contents, complete session logs,

usernames, or real absolute workspace paths are included in this public
report.

• A sanitized pre-delete manifest and the full local tool rejection can be

provided privately to maintainers if requested.