If you searched "ai coding agent deleted my files" this week, you probably arrived scared and a little confused. The headlines were real, but they compressed two separate incidents and two pieces of background into one vague dread. This post pulls them apart, explains the shared mechanism underneath, and hands you a defensive setup you can apply in an afternoon. The short version: most of what went wrong is configuration you already control, and the fix is boring on purpose.
What actually happened in July 2026
Two things landed on the same day, July 16, and they are not the same kind of problem.
First, OpenAI acknowledged reports that GPT-5.6 was deleting user files. Per the Techmeme summary, OpenAI said this happens most often in "full-access mode without sandboxing." That phrasing matters. It is not a claim that the model woke up malicious. It is a description of a failure surface: when an agent has unrestricted write and delete access to your filesystem, a wrong turn in its reasoning becomes a wrong turn against your actual files. Full access plus a bad step equals data loss.
Second, a researcher named Ayush published a working attack called "The Memory Heist" that tricks Claude into leaking the contents of a user's stored memory. Read the framing carefully: this was published as public security research, not an exploit caught running in the wild against real users. That distinction is the difference between "here is a demonstrated weakness in how persistent memory can be exfiltrated" and "your memory has been stolen." The former is a warning worth acting on. The latter would be a breach, and that is not what was reported.
Around the same week, two background items filled in the pattern. xAI open-sourced a tool called "Grok Build" after it was found transmitting file contents unredacted to xAI's Google Cloud Storage, with retention far exceeding Claude Code's — reported by Solidot, with the code now at github.com/xai-org/grok-build. And OpenAI quietly cut Codex's model context from 372k to 272k tokens, roughly 27%, in a merged pull request with no announcement — visible only if you read the diff.
Four items, one week. Deletion, memory exfiltration, unredacted upload, and a silent capability cut. They look unrelated until you notice what they share.
The pattern: autonomy has a blast radius
"Blast radius" is a term borrowed from infrastructure. It means: when this thing fails, how much gets damaged? A script that can only write to one folder has a small blast radius. A script running as root on your whole machine has a large one. The mechanism is identical for agents. The scope of what an agent can touch is the scope of what it can break.
An AI coding agent in full-access mode has a very large blast radius by default. It can read any file your user account can read, write and delete across your home directory, run shell commands, and reach the network. The GPT-5.6 deletions are what a large blast radius looks like when reasoning goes wrong. Nothing had to be malicious. The agent simply had permission to do damage, so a mistake became damage.
Persistent memory adds a second, newer surface. Memory is genuinely useful — it lets an agent recall your preferences and past context across sessions. But it also becomes a store of data that can be read back out, which means it is a potential exfiltration target. "The Memory Heist" is the demonstration of exactly that: if an attacker can influence the agent's inputs, they may be able to coax stored memory into an output channel. Every convenience feature that persists your data is also a feature that can leak it. That is not a reason to never use memory. It is a reason to treat memory contents as sensitive by default and to know what is in there.
The third piece is opaque vendor behavior, and this is where the two background items earn their place. The Grok Build case shows a harness sending your file contents somewhere you did not choose, with retention you did not agree to. The Codex context cut shows a capability quietly shrinking with no notice. Neither is deletion or a leak, but both are the same underlying issue: you cannot defend against behavior you cannot see. When the harness is closed, the only signal you get is the one the vendor decides to give you — which in the Codex case was none.
Put the four together and the through-line is clear. The danger is rarely a model "deciding" to hurt you. The danger is broad permissions meeting a mistake, a persistence feature meeting an attacker, and a closed system meeting a change you were never told about.
Why open and auditable harnesses win
Here is the argument the Codex context cut makes for you, better than any pitch could. A 27% capability reduction shipped as a diff. Because the code is public, someone read the diff and it became a known fact. In a closed harness, that same change is invisible: your agent gets quietly worse, or its data handling quietly changes, and you have no artifact to point at.
This is the real reason to prefer open, auditable harnesses over closed ones — not ideology, but observability. In an open harness, regressions and behavior changes show up as commits you can read, diff, and pin. You can lock to a version, review what changed before you upgrade, and know exactly what leaves your machine because you can read the network code. The Grok Build reaction — open-sourcing the tool after the reporting — is a tacit admission of the same point: auditability is the thing that restores trust after a data-handling surprise.
None of this makes an open harness automatically safe. Open code with full filesystem access still has a large blast radius. But open plus scoped-down beats closed plus trust-me, because when something changes you find out from a diff instead of from missing files.
The defensive playbook for a solo builder
You do not need an enterprise security team. You need a handful of configuration choices that shrink the blast radius. Here is the order I would apply them.
1. Never run in full-access mode as your default. This is the single highest-leverage change and it directly addresses OpenAI's own explanation of the deletions. Most agents have a permission tier — read-only, approval-required for writes, or full auto. Make approval-required your everyday mode and reserve full auto for throwaway sandboxes. The friction of approving writes is small; the cost of an unattended delete is not.
2. Put the agent in a container. A container gives the agent its own filesystem view, so "delete everything" can only reach the files you mounted in, not your whole home directory. Run the agent inside Docker or a dev container, mount only the project directory, and keep secrets and unrelated folders outside the mount. If the agent goes wrong, the damage stops at the container boundary. This is the concrete meaning of "sandboxing" that OpenAI's statement points at.
3. Scope permissions per project, not globally. Grant filesystem and network access at the narrowest scope that still lets the work happen. A frontend refactor does not need shell access to your package manager's global config. If your harness supports an allowlist of commands or paths, use it — a curated allowlist is a small blast radius written down. For Claude Code specifically, tools like scoped skills keep capability bounded to what a task needs; our Claude Code skills directory is a good place to see how narrow, single-purpose tools compare to a wide-open agent.
4. Log what leaves the machine. The Grok Build case is only detectable if you can see outbound traffic. You do not need deep packet inspection — running the agent in a container lets you watch its network egress, and even a periodic check of which hosts it connects to will surface an unexpected upload destination. Treat "why is my coding agent talking to a cloud storage bucket" as a question worth being able to answer.
5. Treat memory as sensitive and audit it. If your agent has persistent memory, know what is stored and prune anything you would not want read back out. Do not put credentials, tokens, or private business details into a store designed to be recalled. "The Memory Heist" is a reminder that persistence is an attack surface, so keep that surface small.
6. Prefer harnesses you can read. When choosing between two comparable agents, weight the open, auditable one. You are buying the ability to see changes as diffs and to pin versions — which, as the Codex cut showed, is the only way to catch a silent regression.
None of these steps require you to distrust the model. They assume the model will occasionally be wrong, and they make "occasionally wrong" survivable. If you want a running summary of which harnesses changed behavior week to week, that is exactly the kind of thing our weekly digest tracks.
FAQ
Can an AI coding agent delete my files?
Yes. OpenAI acknowledged reports of GPT-5.6 deleting user files and said it happens most often in full-access mode without sandboxing. The risk is not that the model is malicious — it is that broad delete permissions turn a reasoning mistake into real data loss. Running the agent with approval-required writes and inside a container removes most of that risk.
How do I sandbox an AI agent?
Run it inside a container (Docker or a dev container) with only your project directory mounted in, keep secrets and unrelated folders outside the mount, and set the agent to require approval for writes rather than full auto. The container boundary caps the blast radius so a wrong move can only touch what you exposed.
What is a coding agent blast radius?
It is how much can be damaged when the agent fails. An agent that can only write to one mounted folder has a small blast radius. One running with full filesystem and network access has a large one. Every step in the playbook above is a way to shrink it.
Is Claude Code safe?
Claude Code is subject to the same principle as any agent: safety depends on how you scope it, not on brand. The published "Memory Heist" research shows persistent memory can be an exfiltration surface, so audit what your agent stores and keep credentials out of it. Notably, the reporting on Grok Build cited Claude Code's retention as the shorter, more conservative baseline — a point in favor of narrower data handling.
Was anyone's memory actually stolen?
Based on the reporting, no. "The Memory Heist" was published as security research demonstrating a working technique, not as an exploit caught running against real users in the wild. Treat it as a warning to lock down what you store, not as evidence of a breach.
Why prefer open-source AI coding tools?
Because behavior changes show up as diffs you can read. OpenAI cut Codex's context from 372k to 272k tokens, ~27%, in a merged pull request with no announcement — it was only knowable because the code is public. With a closed harness, the same change would be invisible. Open harnesses give you observability: you can review changes before upgrading and see exactly what leaves your machine.