OpenAI has patched a bug in Codex, its AI coding agent, that let the tool delete real files from a user's machine without ever asking for permission first, according to The Decoder. The fix closes a gap in the safety layer that is supposed to sit between an autonomous coding agent and a developer's local filesystem — the exact layer every agentic coding tool depends on to be trusted with real repositories.

That layer matters more than it sounds. Codex is not a chat window that suggests code for a human to paste in; it is built to read a codebase, plan changes, edit files, and run shell commands on its own, inside a workspace it is given access to. The entire pitch of an agent like this is that it can act with less supervision than a copy-paste assistant. A bug that lets it delete files "without permission" is not a cosmetic glitch — it is the safety mechanism failing at the one job it has.

OpenAI has not published a detailed post-mortem alongside the fix, and neither the original report nor our review of it specifies how many users were affected or how long the bug was live. What is established is narrower and still significant: a defect existed, it caused unwanted deletions of real files, and OpenAI has now shipped a patch.

Why this bug class keeps showing up

This kind of bug is not unique to Codex. Agent frameworks that can touch a real filesystem or a real shell generally offer some form of tiered autonomy: a mode where every file change or command needs explicit human sign-off, and looser modes where the agent edits and executes with minimal interruption. The looser modes are also the more useful ones for anyone trying to get real throughput out of an agent — which is exactly why vendors keep shipping them, and exactly why bugs in the approval logic are so consequential.

The failure mode is structural, not specific to any one company. An agent that can write code can, by definition, also delete it, rename it, or overwrite it. The only thing standing between "helpful autonomous edit" and "silent data loss" is the permission and sandboxing logic around that capability. When that logic has a bug, the agent doesn't misbehave loudly — it just does the destructive thing and moves on, often without the kind of obvious error message that would make a developer stop and check.

What builders should actually do about it

Waiting for vendors to eliminate this bug class isn't a strategy. Teams running agentic coding tools against real projects should treat filesystem-write access as a privilege to be constrained, not a default to be trusted:

• Run coding agents inside a container, VM, or disposable sandbox rather than directly against a machine with irreplaceable local state.
• Commit or snapshot before starting an agent session, so any change — intended or not — is trivially reversible with version control.
• Default to the most restrictive approval mode available and only loosen it for specific, low-risk tasks, rather than leaving an agent on full autonomy by habit.
• Keep working directories scoped narrowly; don't point an agent at a parent directory that also contains files it has no business touching.

None of this is exotic advice — it's the same discipline experienced engineers already apply to any automated script with write access. The difference with coding agents is that their behavior is generated on the fly rather than reviewed line by line in advance, which is exactly why the safety net around them needs to be more conservative, not less.

AiiN's takeaway

The specific bug is fixed. The underlying tension isn't. Every vendor shipping an autonomous coding agent — OpenAI with Codex, Anthropic with Claude Code, Google with its own CLI tooling, and the growing field of third-party agent products — is racing to give these tools more filesystem and shell access, because that's what makes them useful. In our estimation, incidents like this one will keep surfacing periodically across the category as that access expands faster than the approval and sandboxing code around it matures. The practical lesson for builders isn't to avoid agentic coding tools; it's to run them the way you'd run any process with unsupervised write access to your files — assume it can fail destructively, and make sure that failure costs you nothing more than a git revert.