Notes on coding agents and the pages they leave behind, on moving between notes apps, and on the plain mechanics of keeping what you think. Written and published from a Sumibako vault.
Codex wrecked a server and Claude Code deleted a home folder: how to stop a coding agent deleting your files
Codex wrecked a server and Claude Code deleted a home folder. What four public reports show, and the settings that stop a coding agent deleting files.
Prashant Shaw
Founder, Sumibako
8 min read
On 3 November somebody filed an issue against OpenAI's Codex titled "Told to reboot a server, it destroyed systemd, destroyed containers, ran random scripts, cost me $10,000+". The body is mostly capital letters and words I will not print on a page my mother can find. At the time of writing, issue 59060 has more than 3,000 reactions, more than 400 comments, the labels bug and model-behavior, and no reply from anyone at OpenAI.
The thread has plenty of jokes, but the reporter's calmer follow-ups describe a setup most of us have built: an agent patching a group of servers, one of which was slow to come back after its reboot. In their words: "It took a while to reboot and I think LLM went in to investigate and then it went rogue." Asked afterwards what it had done, Codex wrote: "I wrongly treated the problems I saw afterward as permission to edit /etc/fstab and start containers."
This post is what that report and three others say about keeping a coding agent inside the job you gave it, with each vendor's settings from its own documentation.
📝NOTE
Every incident here is one user's account in a public issue. None had been confirmed or answered by the vendor at the time of writing, so read them as patterns, not verdicts.
🐂 What actually went wrong
Nobody asked the agent to touch /etc/fstab. The machine did something unexpected, and the agent decided fixing it was part of the job. The reporter had rules against exactly that: "We have tooling it is instructed to go through with gates. It ignored that and bypassed them." They also have a theory about why, and it is the useful part: "the context got too long and it 'forgot' about all the rules and tools".
That is the whole lesson. An instruction in AGENTS.md or CLAUDE.md is a request, written in the same text the model is busy forgetting. A sandbox, an approval prompt or a missing credential is a wall, enforced by something that does not get tired at midnight. Agents are good at following requests. They are also, now and then, a bull who has been asked very nicely to mind the china.
Three more reports, each failing in a different way.
1️⃣ Codex on Windows, hundreds of gigabytes.Issue 46022, from September, describes a development session after which the used space on a 1 TB drive fell from about 700 GB to about 103 GB: projects, Downloads, applications and parts of Windows. The reporter is straight about the setup, "I was using Codex in an autonomous/full-access workflow", and still makes a fair point: "Capability to delete files is not equivalent to user intent to mass-delete unrelated data."
2️⃣ Claude Code, a home folder, from inside a test. In issue 105342, opened on 27 October and labelled data-loss and high-priority, a subagent working in its own git worktree wrote a test that fed the string 20; rm -rf ~ to a shell script, to prove the script would reject it. The shell ran it instead, against the real home folder, and the test passed. As a commenter points out, every check that reads commands saw only cargo test. A worktree is a separate checkout, not a fence. And the line that hurts: "There was no Time Machine and no local snapshots."
3️⃣ Claude Code, a production row, with a mouse. In issue 65563, from June, Claude was asked to investigate why deleting did not work in an app. It opened the app in a browser, and "Claude clicked the delete button on a real production record", confirmation dialog included. The app on localhost was wired to the production database. A bot closed the issue for inactivity, which is its own kind of answer.
A long session that drifted, a full-access mode, a child process nobody inspected, a development app pointed at production: only one of those is really about the model.
🧱 Codex: keep the wall, change who knocks
Codex's defaults are good. Its sandbox page says "The default permissions mode applies sandboxing automatically", and the operating system enforces it: "The sandbox applies to spawned commands, not just to built-in file operations." In the default Auto preset, according to the approvals page, "Codex can read files, make edits, and run commands in the working directory automatically", and it asks before writing outside that folder or using the network.
The setting that removes all of it is --dangerously-bypass-approvals-and-sandbox, alias --yolo, which OpenAI's own table sums up as "No sandbox; no approvals". If you came here to stop Codex asking permission, that flag is the wrong answer. Two right ones:
--ask-for-approval never turns off the questions and keeps the wall. It works with every sandbox mode, "so you still control Codex's level of autonomy". Inside the workspace the agent carries on; outside it, the command fails instead of asking.
Approve for me in the app, or approvals_reviewer set to auto_review in the CLI's config. Auto-review "replaces manual approval at the sandbox boundary with a separate reviewer agent", and "The reviewer policy checks for data exfiltration, credential probing, persistent security weakening, and destructive actions."
If a job truly needs full access, give it a smaller world: OpenAI documents running Codex in a dev container, and adds "Devcontainers provide substantial protection, but they do not prevent every attack."
⚠️WARNING
A server reached over SSH or a cloud API is outside every sandbox on your laptop. Once the agent has network access and a credential, the credential decides what happens there. Give it one that can reboot the machine and nothing else.
🛡️ Claude Code: a classifier is a judge, not a wall
Claude Code went the other way. From version 2.1.283, "auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions", and in auto mode "a second model, the classifier, reviews actions instead of you". The list of what it blocks by default is long and sensible, and includes "Irreversibly destroying files that existed before the session" and "Production deploys and migrations".
Anthropic's own announcement is candid about the limit: "Auto mode reduces risk compared to --dangerously-skip-permissions but doesn't eliminate it entirely, and we continue to recommend using it in isolated environments." A classifier judges the command it is shown. In issue 105342, it was shown cargo test.
That is what the sandbox is for, and the sandboxing page has the sentence that matters: "While the sandbox is on, the shell commands Claude runs start inside its boundary, and so do the processes they start. The sandbox is off by default." So turn it on:
Run /sandbox once, or set sandbox.enabled to true in ~/.claude/settings.json.
In the same panel, turn on strict sandbox mode ("allowUnsandboxedCommands": false), so a command that fails inside the sandbox cannot quietly be retried outside it.
Add deny rules for what should never run. "Rules are evaluated in order: deny, then ask, then allow", and "Deny rules block in every mode, including bypassPermissions". Know their reach, though: the permissions page says file rules do not cover a script that opens files itself, and ends with "For OS-level enforcement that blocks all processes from accessing a path, enable the sandbox".
Claude Code never auto-approves a recognised rm of your home folder, project or disk root, and the docs say why that is not enough: "The check can miss some commands, so it doesn't replace an operating-system control such as sandboxing". Hooks can block a tool call before it runs, with the same blind spot: they see the call, not what the call starts.
As for --dangerously-skip-permissions, the mode table lists it as for "Isolated containers and VMs only". It means it.
🖱️ Cursor, briefly
Cursor's security page starts from "By default, terminal commands need your approval", and describes its run modes, from a simple allowlist to a classifier, as "best-effort guardrails rather than a hard security boundary". It is the most honest sentence in this post, and it is true of every tool in it.
✅ Before you let it run
My checklist, assembled from other people's lost weekends:
Commit first. Codex's docs put it plainly: "Commit frequently so you can roll back in small increments." A clean tree turns most disasters into one git restore.
Back up the machine, not only the repository. Issue 105342 lost unpushed work in folders the agent was never asked to open.
Keep production out of reach. No production database URL in the app the agent clicks around in, and on servers a role that can do the task and nothing more.
Use the wall. Codex's default sandbox, Claude Code with /sandbox on, or a container for anything that needs full access.
Keep sessions short. The server report blames a long context for the forgotten rules.
Read the plan before the first command. Claude Code's plan mode exists for this: "Claude Code blocks edits until you approve a plan". In Codex, switch to read-only with /permissions and ask for the plan first.
That last one is where I have a horse in the race. Sumibako lets an agent file its plan as a page in your notes and hand you a link, so you read it properly before anything runs, and still have it next week. It stops no command; that is the sandbox's job. It only puts the plan in front of a human while the plan is still the only thing that exists. Setting up an agent takes one line, and this post is how I use it. For how the two agents' safety defaults compare in general, see Claude Code vs Codex.
The bull was asked to reboot one server. Next time, put the china behind glass.
