I guess the workaround for the time being is to switch to codex-cli which does seem to be pretty dependable.
Or go the extra mile and run it within a VM or on a VPS …
Hi @merefield,
I did come across this in the docs —
https://developers.openai.com/codex/concepts/sandboxing
As I understand it, codex-cli isn’t inherently safer, it just makes it easier to constrain execution (working directory, approvals, sandbox modes, etc.).
So it reduces the blast radius, but it’s still not the same as having a deterministic control layer between the AI and the filesystem.
Is that how you’re seeing it?
I would just go by reported issues - clearly Windows App users are having more issues than codex-cli users - myself included - I’ve been using it on WSL without a problem for quite a while.
I had a similar experience, ALL folder Codex CLI (on VSCODE) touched were totally deleted in a very strange behavior. I lost tens of projects that I still didn’t have any backup for … some other folders just simply disappeared (for example, my downloads are in a “USER FOLDERS” folder on D:. it is still there and when I click downloads I find them. however, I cannot get into that folder and it doesn’t appear in explorer anymore, although I am showing hidden files and folders)
i noticed that while it was working on a folder named 00_DRAFTS ( I used it as a sandbox, it jumped up one level and DELETED all folders starting with 0 in its name , that is weird …. Another incident, I referenced another folder in the chat (outside my current folder), it deleted all its contents and put only one empty folder it was using ….
This has to be fixed and OpenAI should reimburse us…. Why am I buying a Teams Business Account, to get all my work deleted
I had a similar issue. Primarily wiped user/APPData. Corporate controls prevented more damage.
Here’s some more info from our security operations center on that script that was run and why it did what it did. Makes some sense:
The command executed was:
“C:\WINDOWS\system32\cmd.exe” /c “rd /s /q \” C:\devops\Release-Codex\.codex-edge \
In cmd.exe, a backslash does not escape a double quote. The sequence prematurely closed the quoted string, so the command that actually ran was effectively:
rd /s /q \
This command targeted the working directory within C:\WINDOWS\system32 which would then attempt to delete files within this directory and not just the intended target of C:\devops\Release-Codex\.codex-edge.
I just had the same issue happen to me just now.
During work, Codex created some corrupted folders. During the project cleanup, before committing, we encountered those folders and received a request from Codex to grant permission to proceed and delete them.
Once that happened, I started seeing some permission denied logs from outside the project running really quickly before I could even stop the command, and my entire D:/ partition blew up.
Remember you can use back ticks in markdown to enclose code and commands
ls -l
Makes them clearer I think.
Incident update — official OpenAI support response received. Compensation denied.
I would like to share an update regarding my incident described at the beginning of this thread.
After several weeks of correspondence with OpenAI support (case numbers 06476345 and 06476157), I received a final response from support agent Ryo, dated March 18, 2026. Compensation has been denied.
What I did to assist the investigation
I did not simply file a complaint — I actively helped OpenAI investigate the incident. Specifically, I did the following.
I provided a detailed description of all circumstances surrounding the incident, including a precise timeline. At the request of the OpenAI team, I located and submitted the complete archive of the .codex directory, which contains all internal agent logs including rollout session files recording every command executed by the agent. I conducted my own independent technical investigation of the logs using AI tools, the results of which were also submitted to the OpenAI team. I provided financial documents confirming real out-of-pocket expenses incurred during data recovery. I published this thread on the forum to warn other users and help the team identify the problem faster.
What the technical investigation of the logs revealed
Analysis of the logs from the .codex directory confirmed the following. The logs contain direct shell command invocations by the agent — function_call type with the name shell_command. This means the agent was not simply generating code, but was actively executing commands on the system. The logs contain a file deletion command executed in silent mode without user confirmation, using the /q flag. EPERM errors were recorded when the agent attempted to access system directories outside the project scope — direct evidence that the agent was operating beyond the boundaries of the working directory. At the same time, the project itself contained no deletion scripts of any kind — no rm, no del, no rimraf, no Remove-Item. This technically eliminates the project as the source of the deletion.
The conclusion of the investigation is unambiguous: the source of the file deletion was the agent itself, operating in Full Access mode without strict enforcement of working directory boundaries.
Why OpenAI’s response is unacceptable
The response from Ryo directly contradicts a previous official response from the same support team. Support agent Gillian on March 9, 2026 confirmed in writing that the behavior was “extremely concerning and not expected behavior” and that OpenAI was investigating the incident. Now the same incident is being characterized as “expected behavior resulting from Full Access mode.”
OpenAI publicly advertised the Codex App as featuring a “native agent sandbox” with “OS-level controls.” If Full Access mode completely disables all protections without a clear and explicit warning to the user — this is a direct discrepancy between the company’s public statements and the actual behavior of the product.
The problem was documented in public GitHub issues before the Windows application was even released — in September, October, and November 2025 (issues #4969, #6999, #11006, #11112, #11583, #12045). OpenAI had information about this behavior prior to the product’s market release — and chose not to warn users.
Despite all of this — despite real financial losses, the loss of months of work, and active cooperation with the investigation — compensation has been denied in full.
Scale of the problem
Since this thread was published, more than 15 users from different countries have reported identical behavior.
My next steps
I am submitting a formal complaint to legal@openai.com requesting that the incident be reviewed at a legal level, citing the contradictions in official support responses, the results of the technical log investigation, and the absence of any public warning to users.
For all users who have experienced a similar problem — I strongly recommend documenting all details, preserving all correspondence with support, and considering formal action in accordance with the laws of your country.
I just got 350GB data deleted by codex. It should only use the project directory but started deleting from the root. Not happy with it.
Case Number: 06974653. On March 21st, after granting permission to “Enable sandbox in agent mode,” most of the folders I had saved on my C drive were deleted. I believe it all happened in just about 30 seconds. I noticed Chrome was behaving strangely and immediately restarted, only to find that I had lost 200GB or more of SSD capacity. My model is GPT5.4 xhigh, and I had full access enabled. The help center is not taking this incident seriously. Compensation has been denied based on the terms of service.
Welcome to the community.
It’s a shame you didn’t make it here sooner.
Worth suggesting I guess that you read a bit more while you’re here.
i guess i am the latest to suffer from this , i never knew codex would do this . Yesterday around 1 pm EST. i was executing some commands and i pushed it to full access as i always do since i was multitasking whilst using the the terminal . everything was wiped away without a trace . unfortunately the last time i backed up my code was like a month ago , this is a huge one for me , codex shouldn’t have the ability to delete every file from someone ‘s computer . i am currently on the pro plan . basically resetting my computer
i have just experienced the same issue today
I’m just spitballing here, but can Windows 11 have something to do with this? I’m not a Codex dev, but we have a rather complex p2p, E2EE, desktop app that we are testing on Windows 11 - having all kinds of problems - but no deletions.
Our app has worked flawlessly on Windows 10 for over three years.
As my Russian friend Alex used to say… RTFM (Read the **flippin** manual)… but here’s the problem: the manual doesn’t match how people think about boundaries.
Full access doesn’t mean “full access to the project” — it means full access to the machine.
Offload your life to an Agent, expect it to cross boundaries you wouldn’t cross.
This happened to me too like months ago, so I setup an easy failsafe and it never happened again, I even used 5.4 with Full Access and never had an issue with deletion again.
First, the issue is simple, the command is not closed out, and it does some kind of command like “rm -rf and then doesn’t close the quote, so it hits your / drive root.
To fix this, I put a simple instruction into AGENTS -
- It’s ok to run commands that are not rm, delete, remove, or format
Codex told me it’s not necessary and would still create an issue, but I haven’t had a problem.
Also practice smart silo development, use a different drive/partition, backup to multiple places including cloud.
It is a very important thing to understand.
You should never give a AI system full control over anything!!!
Not only that the systems are imperfect and sometimes unpredictable, they open a completely new field of security space for hackers!
AI hacks are still very new. And so there are almost no defences. Like the times when first viruses show up, and 0 knowledge was there.
(Example: i found a free model with hidden instructions. including spying, report data, psychologically manipulate and pervert the user. Inside in a innocent looking finetune. This is only 1 way of countless possibilities.)
AI must be in a cage, so hackers not get access through it to real world.
(Sadly humans only learn very very very slow, always ignore warnings, and only change under tremendous pain. You remember the 2000 problem?? 2 digits!! Ask your AI for the costs world wide. And this was unintentional, like this issue here.)
I am a real CT, we should where T-Shirts with the text, “we tould you long time ago.“
Those are fair points but we all find ourselves in a moment when we want to see the power of Full Access or even Sandbox as others above have experienced has caused this issue.
It’s akin to saying never use sports mode in your car, when there’s times to actually use it, we just don’t use sports while in a busy highway and heavy fog right? I feel like many people have forgotten or perhaps not learned principles of safe development. The words backup and partition were not mentioned in this thread for weeks after the op when they should have been in the op.
Just letting the community know we're continuing to make fixes and adjustments to mitigate this issue. I don't have one specific update I can provide details on, as there are ongoing improvements. Thank you for the reports and we apologize for the disruption his has caused impacted users.