›_ Codex Issues
Codex Issues / #12045

Critical: Unexpected deletion/rename activity in personal folder (D:\Content) during Codex session, suggesting fail-closed path guardrails

Resolved 💬 4 comments Opened Feb 17, 2026 by RightNiceGames Closed Feb 18, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Critical: Unexpected deletion/rename activity in personal folder (D:\Content) during Codex session, need fail-closed path
guardrails

Description
On February 17, 2026 (Swedish local time), approximately 10:53-11:00, I experienced unexpected mass deletion/rename activity under
D:\Content during a Codex-assisted session. This path contains critical personal known-folder data (Desktop/Downloads/
Documents targets) and had been stable for years. I recovered files via Shadow Copies and DMDE, but this caused high-risk
data-loss impact and significant downtime.

Suggesting product-level safeguards:

  1. User-defined protected-path deny list (hard block on write/rename/delete/move/ACL changes), fail-closed.
  2. Explicit per-command confirmation for destructive operations, with exact target paths shown before execution.
  3. Strict fail-closed behavior when sandbox/permission state is uncertain.
  4. Immutable command provenance log (timestamps, command, cwd, resolved target paths) for incident auditing.
  5. Preflight dry-run for write operations showing planned file changes and risk level before execution.
  6. Safer Windows defaults, including enforceable workspace-only write mode.

This incident reduced trust in default filesystem safety behavior. I can provide timeline details and forensic evidence if
needed.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 6 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #10037
  • #12008

Powered by Codex Action

etraut-openai contributor · 6 months ago

Sorry to hear you lost data. Can you provide more details about your configuration as requested in the bug report template? In particular, what codex product are you using (CLI, extension, app), which platform, which version? I'm guessing you're using Windows native (versus WSL) based on the path names. Did you have the Windows sandbox enabled? Were you running in "full access" ("yolo") mode?

RightNiceGames · 6 months ago

@etraut-openai Thanks for the follow-up.
I did some more research as to what happened.

Here are the requested environment details for the incident window on Tuesday, February 17, 2026.

  • Codex product: Codex CLI (not extension/app)
  • CLI version: codex-cli 0.101.0
  • Platform: Windows native (not WSL)
  • OS/platform string: Microsoft Windows NT 10.0.26100.0 x64
  • Terminal emulator: Windows Terminal 1.23.20211.0
  • Shell: Windows PowerShell 5.1.26100.7462
  • Session mode during incident: full access enabled (approval_policy: never, sandbox_policy: danger-full-access in session log)
  • Windows Sandbox app: not used for this session
  • Thread/session id: 019c6af3-b876-7a42-b148-cebe38c813ed

yes, unfortunately in yolo mode 😅

Additional context:

  • I exported and reviewed all function calls between 10:53 and 11:00 local.
  • Only workspace-scoped delete commands were observed in-session (targeting _tmp_zoom under D:\Projects\AI\workspaces\...).
  • No in-session command targeting D:\Content was found in that window.
  • USN evidence still shows a separate delete burst under D:\Content around 10:59:07.
  • In the available PowerShell logs (4103/4104) for the incident window, there is no command targeting D:\Content. The logged commands target workspace paths under D:\Projects\AI\... (not D:\Content).
  • Codex was not able to find the reason for these mass deletions since in-session commands only read, created and erased files under D:\Projects\AI\workspaces\... (not D:\Content).
  • Current evidence rules out the recorded Codex console commands for D:\Content.
  • It does not yet conclusively rule out human GUI deletion vs another external process.
  • We don't have full process lineage/command line for all processes (because 4688/Sysmon data isn’t available

Because of these circumstances, I am therefore aware that it's very hard to determine if it actually was codex that was responsible for this issue, but a targeted mass deletion like this has never happened before. I mean, it could have been that I deleted these folders in some way by mistake without noticing.

I am afraid this is going to happen a lot. Situations where something bad happens and you automatically blame the AI for it. Or perhaps there was some SYMLINK created in the working folder by mistake which caused the error (I happen to have a "Make folder junction" button in Total Commander). Idk man... Luckily I managed to retrieve the files via file recovery tools.

Thank you for taking you time with this.

Attachments:

bug_report_attachments_bundle.zip
non_shell_manifest.md
non_shell_manifest.csv
manifest.md
manifest.csv

etraut-openai contributor · 6 months ago

Thanks for the additional details.

We recommend against using "yolo" mode. It's designed for use in an isolated environment (VM or dev container). By default, codex provides safety mechanisms to prevent this, but when you choose "yolo" mode, you're disabling most of these safety mechanisms.