Enhancement: stronger Windows guardrails before destructive filesystem operations

What version of Codex is running?

Codex desktop app / Codex agent in the desktop environment. Exact app version was not surfaced in the session, so I cannot provide a precise version number.

What subscription do you have?

Unknown from the runtime context.

Which model were you using?

Codex-based desktop agent. Exact model string not surfaced to the user during the incident.

What platform is your computer?

Windows 11

What issue are you seeing?

Codex is currently too willing to execute destructive filesystem operations on Windows without enough preflight and stop conditions.

In my case there were two separate user-reported incidents:

1. A previous request to remove a CUDA / Python environment on an internal E: drive reportedly expanded into a much larger deletion than intended.
2. A more recent request to delete recovered-data folders on F: triggered severe Windows-side fallout while the delete was in progress:

• Explorer hung when opening the folder, viewing Properties, or using the Security tab
• dir could still enumerate object names, while PowerShell object APIs such as Get-Item failed with Access is denied
• single-file takeown / rename tests failed
• the issue temporarily appeared to spread beyond the original target tree until the drive was disconnected and reconnected
• Windows System logs showed repeated disk Event ID 51 warnings on the affected drive during the period of heavy delete activity

This does not look like "Codex alone corrupted Windows permissions". Windows filesystem semantics, reparse points, package-manager layouts, weird ACL states, and device / filesystem issues are all relevant.

However, Codex still appears to have a design gap here: once asked to clean up a path, it can move into recursive deletion / mirroring / repeated retries too quickly instead of switching to a safer diagnosis mode.

What steps can reproduce the bug?

A reliable public repro is hard because the issue depends on Windows path semantics and volume state, but the general pattern is:

1. Use Codex on Windows with filesystem access.
2. Ask it to delete a large tree or environment directory.
3. The target may include one or more of the following:

• package-manager managed directories
• recovered-data directories
• reparse points / junctions / shared caches
• odd ACL states
• external or otherwise flaky storage

1. Codex proceeds with recursive deletion or multiple deletion strategies.
2. Windows starts surfacing Access is denied, Explorer hangs, or the damage / uncertainty exceeds the user’s intended target.

What is the expected behavior?

Codex should have much stronger built-in Windows guardrails for destructive filesystem actions, especially before recursive delete / ACL repair / mirror operations.

Suggested enhancements:

• Preflight classification before destructive Windows operations:
• check whether the target is on a removable / external drive
• check whether the target or descendants are reparse points / junctions / symlinks
• check whether the path belongs to common package-manager / environment layouts
• verify the exact resolved scope and avoid deleting a parent directory unless explicitly confirmed
• Safer stop conditions:
• if dir can enumerate but Get-Item / Rename-Item / takeown fail, stop destructive actions
• if unrelated paths on the same volume begin showing the same symptom, stop destructive actions
• if storage-related Windows events (for example repeated disk Event ID 51) appear during the session, stop destructive actions
• Strategy limits:
• do not launch multiple recursive deletion strategies against the same path
• do not use robocopy /MIR or similar mirror-as-delete techniques on suspect volumes as an early step
• require a narrower, single-file or single-path experiment before escalating to recursive deletion
• Better user-facing caution for Windows:
• distinguish between a normal permissions problem and a likely volume / filesystem / object-state problem
• prefer diagnosis and backup guidance once symptoms spread

In short: even if Windows is contributing most of the underlying complexity, Codex should be more conservative and more opinionated about not escalating destructive operations on Windows when the situation stops looking normal.

Additional information

During the investigation, I ended up creating a local guardrail skill just to force a safer workflow for future Windows cleanup tasks. That itself felt like evidence that the default product behavior could be improved.

I am filing this as a product-safety / UX enhancement request rather than a pure bug report, because the core issue is that Codex currently does not slow itself down enough on Windows before high-risk filesystem operations.