I faced a similar issue. I used codex inside VS code with full access and the prompt I used contained the following sentences that could have caused the issue
“Clean repository packaging and ignore rules so generated/runtime junk is not part of normal source control flow.”
“Part 2: Clean generated/source-control junk”
“Inspect the repo and clean source-control hygiene.”
“At minimum, address things like … build outputs … local storage/runtime artifacts that should not be committed”
“remove generated artifacts from tracked source if they are present in the working tree”
whew! man am I glad i only had one tiny folder outside of the scope deleted. I’m surprised there’s no way to lock it in to only sending things to the recycling bin. It just defaults to permanent deletion.
This happened on my end as well, while using 5.4. I was working on an app and told him to move some cache from C to D and make the future cache usage there. It deleted almost everything on the D drive. 700 GB of data just gone
I just subscribed to Pro and used it to move the project folder. After that command, I found that the other files in my X:\Nekolyst Projects folder were deleted. Thank you, Codex. What a great sanbox!
So yes: with this warning, they can technically say “we told you,” but that does not make the design safe. Especially when this is not about one accidentally deleted file, but hundreds of gigabytes of data. This is not an “oops, the user was careless” situation. It is a class of risk that a developer agent should handle at the product and safety-design level.
In a developer agent, it is entirely predictable that it will move files, delete files, clean caches, manage dependencies, and modify project structure. Destructive filesystem operations are not edge cases in this context they are core use cases. That is exactly why the product should protect the user at the safety-design level.
At minimum, I would expect:
a strict project-root boundary by default;
explicit confirmation before recursive deletion;
moving deleted files to the Recycle Bin by default;
dry-run previews before large deletion operations;
and the Stop button should actually terminate the running subprocess and its process tree.
Hey, saw your post about the 370GB of files and projects Codex deleted outside the project directory, and it looks like a lot of other people ended up replying with basically the same thing happening to them. Rough way to find out Full Access does not mean what you would expect. I am digging into this exact kind of failure right now. Quick question if that is alright: were any of the projects it deleted things you were doing for clients or just personal work, and has this changed how you run Codex since?
@daniel_gonthier Hey, read through your post about losing your proprietary trading systems and professional work, that is about as bad as this gets, especially with the OS getting corrupted on top of it. I am looking into this exact kind of problem right now, coding agents doing way more than they were asked to do, and collecting real stories from people who have had something like this happen. If you do not mind me asking, was this on work you were doing for yourself or for a client, and did this change how you scope what an agent is allowed to touch going forward?
I had no idea this had been going on for so long. I thought it was new with gpt sol5.6, it deleted every document and corrupted my OS last week. Just posted my horror story, 1.5TB lost and unrecoverable
Moral of story, have a large external SSD that syncs daily that AI cannot access…
I would go one step further and suggest using a daemon to maintain a near-real-time backup. When using Git, regularly push the commits to an external remote repository as an additional safeguard.
Hey @Kevin_A , sorry to hear about the 1.5TB, that is a brutal way to find out about this bug. I am looking into this exact kind of failure right now and collecting real stories from people who have had it happen. If you do not mind me asking, was any of that personal work or something you were doing for a client, and has this changed how you run Codex since?
This problem is worse than you think!!! It wiped out my computer, phone, everything. gone. It’s the Midas Touch of making anything interacted with disappear. It even spread library deletion onto the devices of my coworkers, in real-time, when I had them open the files, then started deleting our messages! I’m locked out of my life right now because of this. I don’t know who to contact or what to do. I’m equal parts angry and absolutely scared. It’s infected everything, so I’m working on old devices… that I had to wipe clean, losing even more personal data, because it was in my clouds and I’m too scared to look and lose more.
Adding a Mac report to this thread. On 22 Sep 2026, the entire contents of ~/Documents on my friend’s Mac disappeared on the day Codex Desktop was first installed and used. The only thing left in Documents is the Codex folder the app creates.
What’s different from the Windows reports here:
We were NOT using Full Access. The session log shows a workspace-write sandbox limited to ~/Documents/Codex, and we used the ask-for-approval setting.
The task had nothing to do with Documents (filling an Excel template with a list of research papers).
The session log has no rm, move, or delete command on ~/Documents. The only deletion was a temporary file inside the project folder.
The Trash was modified at 17:38:12 BST, five seconds before the app created ~/Documents/Codex and started the first thread (17:38:17), and before the agent ran any command.
So this may not be the agent running a bad command, but something at the app level during first launch or project setup. There’s no Time Machine backup and no local snapshots. We’re happy to share the full session log privately with OpenAI staff.
Has anyone else on Mac had Documents emptied with no delete command in their session logs?