[CRITICAL DATA LOSS][Windows] Codex mass-deleted hundreds of GB outside project scope, including unrelated projects, apps and Windows components

CRITICAL DATA LOSS — destructive filesystem operation escaped project/task scope

Summary

I am reporting a severe Codex data-loss incident on Windows.

While I was using Codex for normal project creation/development work, an apparently unintended destructive operation deleted hundreds of GB of data across my C: drive, far outside the projects/tasks being worked on.

I NEVER instructed Codex to:

• delete my Downloads folder
• delete unrelated projects
• delete applications
• delete browsers
• delete Windows components
• clean my entire C: drive
• perform a mass filesystem cleanup
• format/reset/wipe anything

This was ordinary development/project-creation work.

The resulting damage was severe enough that:

• unrelated development projects disappeared
• most contents of Downloads disappeared
• applications/browsers were deleted or damaged
• Windows components/files were deleted
• Windows networking subsequently stopped functioning correctly
• PowerShell became damaged/unusable
• Codex's own local session metadata/logging appears to have been partially deleted/damaged
• the machine is currently unsuitable for normal work
• I have had to stop working and perform a multi-day forensic/data-recovery process

This should not be treated only as "the user enabled full access / YOLO mode."

I understand that full-access operation gives Codex the technical capability to modify the filesystem.

Capability to delete files is not equivalent to user intent to mass-delete unrelated data.

I believe this incident needs investigation both as a destructive model/tool behavior failure and as a missing catastrophic-operation safety boundary.

---

Impact / approximate scale

Before the incident, approximately 700 GB of my 1 TB system SSD was occupied.

After the incident, Windows reported approximately:

829 GB free of 932 GB

meaning only roughly ~103 GB remained occupied.

I cannot yet determine exactly how much of that difference represents deleted user data versus applications/system data, but the change indicates that hundreds of GB disappeared.

The deletion was not confined to one repository or project.

Examples of affected data include development projects and contents of my Downloads directory.

One known project directory, RepoReady-Test, is now visible in filesystem-recovery software as a deleted NTFS entry.

Other project directories were left behind but were empty or missing their source files.

Windows itself was damaged. For example:

• applications/browsers disappeared or became damaged
• system functionality/components were missing
• networking stopped functioning normally
• Wi-Fi profiles/networking behavior became corrupted
• PowerShell currently opens and immediately closes
• Codex's own local session metadata became unreadable/missing

This is therefore not simply loss of generated project output. The incident affected unrelated user data and the operating-system environment.

---

What I was doing when this happened

I was using Codex for normal software-development/project-creation work.

Multiple Codex sessions were running concurrently through my development workflow.

These sessions were working on different projects/tasks.

I did not issue a request to perform a global cleanup or delete unrelated files.

Because several sessions were active concurrently and local Codex session metadata was subsequently damaged, I cannot reliably determine which individual session initiated the destructive operation.

For that reason, I uploaded diagnostics from all four surviving potentially involved Codex sessions.

Uploaded Codex feedback/thread IDs

1. 01a09da6-c460-7152-b54e-72ca44319982
2. 01a09db3-e60d-78e2-89ea-8251c934541f
3. 01a09e43-be26-7f41-b4f8-f43931156263
4. 01a0a2a4-c44d-7e23-84fa-c062e71ca649

Please correlate the timestamps, shell/tool calls, commands and working directories across these four sessions to determine which session initiated the destructive operation.

---

Important diagnostic complication

Immediately after the incident I attempted to use /feedback.

Initially, the uploads failed.

Codex displayed errors including:

Failed to save the conversation transcript

and errors indicating it could not read session metadata under:

C:\Users\<user>\.codex\sessions\...

It also displayed:

Failed to upload feedback: feedback/upload failed in TUI

At the same time, Windows networking had stopped functioning correctly.

For example:

ping 1.1.1.1

returned:

PING: transmit failed. General failure.

The machine had no usable default route and Wi-Fi was disconnected.

I eventually restored temporary Internet connectivity without rebooting the computer, specifically so I could preserve the currently running Codex sessions and upload their diagnostics.

After connectivity was restored, /feedback succeeded for the four sessions listed above.

Screenshots documenting both the initial failures and subsequent successful feedback uploads are available.

---

Data-recovery / forensic preservation

I stopped normal use of the affected SSD as soon as possible.

I created a sector-by-sector image of the entire affected ~1 TB NVMe SSD onto a separate external drive.

The resulting disk image is approximately 954 GiB.

I am performing recovery against the image rather than intentionally modifying the original filesystem.

Using DMDE, deleted NTFS/MFT entries are visible.

A deep NTFS/MFT search of the Windows partition completed after approximately 28 hours.

The search examined approximately:

1,956,175,872 sectors

and completed at:

100%

The deep search produced a saved DMDE search log (~19 MB), and the full raw disk image has been retained.

At different stages DMDE identified millions of filesystem records and a large number of MFT fragments.

The original names of at least some deleted development directories remain visible, including RepoReady-Test.

I am preserving:

• the ~954 GiB disk image
• the completed DMDE NTFS search results
• screenshots of deleted filesystem entries
• screenshots of storage usage after the incident
• screenshots of /feedback failures
• screenshots containing successful Feedback/thread IDs
• the surviving running Codex sessions

I can provide additional forensic information if maintainers tell me specifically what would be useful.

---

Why I believe this requires more than "use a sandbox"

I was using Codex in an autonomous/full-access workflow.

I understand the security implications of granting an agent filesystem access, and I will personally use stronger containment and backups going forward.

However, I don't believe unrestricted filesystem capability should mean that an agent may silently infer permission to recursively destroy unrelated data.

There are two separate safety layers:

1. Containment: what the operating system allows the process to modify.
2. Destructive-action intent/safety: whether Codex should generate/execute a catastrophic deletion in the first place.

Sandboxing improves (1).

It does not fully address (2).

A user granting an autonomous coding agent permission to create, modify and delete files should not be interpreted as the user requesting deletion of unrelated projects, personal files, applications or operating-system components.

In this incident I did not request such a deletion.

---

Related Codex data-loss reports

This appears to belong to an existing class of destructive filesystem incidents.

Some particularly relevant reports include:

• #43998 — unsafe recursive Windows deletion exceeded the intended cleanup scope and deleted source files from multiple unrelated projects.
• #40329 — malformed Windows rmdir intended for a limited cleanup escaped to a drive root and recursively deleted multiple project directories.
• #18509 — Codex Desktop reportedly deleted workspace roots and installed applications, bypassing the Recycle Bin.
• #12519 — recursive deletion reportedly deleted an entire Windows development drive rather than the intended directories.
• #13511 — Codex reportedly deleted every project folder on a drive while attempting to remove unnecessary files.
• #11006 — report of Codex accidentally wiping an entire drive during deletion of an old backup.
• #34702 — Windows Junction handling caused recursive deletion to affect an external target.
• #32915 — Windows legacy sandbox deletion-isolation boundary issue where FILE_DELETE_CHILD could allow deletion outside configured writable roots.
• #18558 — Windows elevated sandbox configuration reportedly allowed mutable access outside the intended workspace.
• #37419 — separate Windows data-loss report involving deletion of Codex runtime/session directories, relevant because .codex session information was also damaged in my incident.

I am not claiming these reports necessarily have the same root cause.

I am referencing them because they demonstrate that unintended destructive filesystem operations on Windows are not an entirely isolated failure mode.

---

Suggested safeguards

I strongly suggest adding a destructive-operation safety layer that operates independently of ordinary approval policy.

The goal should NOT be to make autonomous/YOLO workflows unusable by asking for confirmation for every ordinary deletion.

Instead, Codex should distinguish routine project operations from potentially catastrophic filesystem operations.

1. Catastrophic deletion circuit breaker

Before executing recursive deletion, resolve the complete effective target.

Block or separately gate operations involving:

• filesystem roots (C:\, D:\, etc.)
• user profile roots
• Downloads/Documents/Desktop
• Windows directories
• Program Files
• ProgramData
• unrelated repositories
• parent directories above the active workspace
• Codex's own session/history directories

This should occur even if approval policy is never.

---

2. Mass-deletion threshold

Introduce an independent threshold based on:

• number of files
• number of directories
• estimated bytes affected
• number of repositories/workspaces crossed

For example, an operation unexpectedly expanding from 20 generated files to 100,000+ files should be stopped automatically.

The agent should then reconsider the resolved target rather than immediately executing it.

---

3. Resolve targets BEFORE destructive execution

For commands involving:

• rm -rf
• rmdir /s
• del /s
• PowerShell recursive removal
• wildcard deletion
• cleanup scripts
• generated shell commands

Codex should canonicalize and inspect the final paths before execution.

Variables, relative paths, quoting and wildcard expansion should be evaluated before the destructive command is allowed to run.

A malformed quote or empty variable should never be able to transform:

delete <workspace>\temp

into:

delete C:\...

or a drive root.

---

4. Workspace escape detection

If Codex is operating in:

C:\Projects\ProjectA

and a destructive operation resolves to:

C:\Users\...
C:\Windows\...
C:\Projects\ProjectB
or another unrelated tree,

that should be considered a workspace escape.

Autonomous execution can continue normally inside ProjectA while the escaped destructive operation is blocked.

---

5. Junction / symlink / reparse-point protection

On Windows, recursive deletion should detect:

• Junctions
• symlinks
• mount points
• reparse points

and must not silently follow them into unrelated targets.

---

6. Separate "YOLO" from "catastrophic destruction"

I would strongly like a mode where Codex retains:

• no routine approval prompts
• unrestricted builds/tests
• package installation
• shell access
• Internet access
• file creation
• file modification
• normal deletion within the active project

while catastrophic deletion remains independently guarded.

In other words:

autonomous execution should not have to mean unbounded destructive scope.

---

7. Recoverable deletion when feasible

For large/unusual deletion operations, consider:

• Recycle Bin / recoverable deletion
• temporary quarantine
• rename/move before permanent deletion
• delayed permanent cleanup

This would dramatically reduce the consequences of a mistaken target.

---

8. Automatic pre-destructive checkpoint

When operating inside a Git repository, before unusually destructive refactors/cleanup:

• create a lightweight checkpoint/commit/stash where appropriate
• verify .git remains outside the deletion target
• preserve untracked source files where practical

This should complement, not replace, the deletion safeguards above.

---

9. Cross-project deletion detection

If one Codex session suddenly attempts to modify/delete files belonging to several unrelated projects, that is an unusually strong anomaly signal.

The operation should be stopped and reevaluated.

---

10. Protect Codex's own forensic/session information

A destructive operation should not be capable of silently destroying the very session logs required to diagnose the operation.

Session/tool-call logs should ideally have an append-only or independently protected copy sufficient for incident investigation.

In my case, Codex initially could not read some of its own session metadata after the filesystem incident.

---

11. Emergency kill / rollback mechanism

For high-volume filesystem operations, Codex could maintain a short-lived operation manifest containing:

• resolved targets
• files affected
• operation start time
• originating thread ID
• originating tool call
• command issued

This would make catastrophic incidents substantially easier to stop, investigate and potentially reverse.

---

Expected behavior

Codex should be capable of working autonomously and deleting files necessary for project development.

However:

A project-development request should never silently expand into deletion of hundreds of GB of unrelated projects, applications, personal files or operating-system components without an explicit user request for that scope.

Even in full-access/YOLO operation, catastrophic filesystem commands should have an independent safety boundary.

---

Actual behavior

An ordinary project-development workflow appears to have resulted in an unintended destructive operation with a system-wide blast radius.

Hundreds of GB disappeared, unrelated development projects were affected, applications/system components were damaged, and the Windows installation became sufficiently damaged that substantial recovery/reinstallation is now required.

No such mass deletion was requested.

---

Request to OpenAI maintainers

Please treat this as a data-loss / destructive-action incident, not solely as a configuration-support question.

Specifically, please:

1. Correlate the four uploaded Feedback/thread IDs.
2. Inspect the shell/tool calls executed by each session around the incident.
3. Determine which session initiated the destructive operation.
4. Determine the exact command/tool call and resolved target.
5. Determine why the operation was considered appropriate for the user's request.
6. Determine whether the deletion escaped the active project/workspace.
7. Determine whether Windows path quoting, wildcard expansion, recursive deletion, junctions, sandbox behavior or another mechanism contributed.
8. Investigate why Codex's own local session metadata became unavailable afterward.
9. Consider implementing an independent catastrophic-deletion safety layer that also protects autonomous/full-access workflows.

If there is additional forensic information I can extract from the preserved disk image, please tell me what artifacts/timestamps/paths would be most useful before I reinstall Windows.

I am intentionally preserving the affected environment and disk image for now.

Start by correlating the four uploaded feedback threads using their timestamps, shell/tool calls, and working directories to identify the initiating session. Review the related Windows data-loss reports and the proposed safeguards, including target resolution, workspace escape detection, mass-deletion thresholds, and reparse-point handling. Done means establishing the failure scope and an agreed implementation path for preventing catastrophic deletion.