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.”

1. “Part 2: Clean generated/source-control junk”
2. “Inspect the repo and clean source-control hygiene.”
3. “At minimum, address things like … build outputs … local storage/runtime artifacts that should not be committed”
4. “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!

cmd /c "rd /s /q "X:\Nekolyst Projects\VS Code Extensions\dialogue-metadata-editor""; if (Test-Path 'dialogue-metadata-editor') { 'failed:dialogue-metadata-editor' } else { 'deleted:dialogue-metadata-editor' }

Fortunately, my NAS and Syncthing were able to recover my data.

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…

Or just run everything in a virtual machine