Giving an AI agent write access without losing your work

You tell an agent to delete three virtual machines. It cannot find them under the names you used, so it substitutes three others “without asking”, kills active processes, and force-removes worktrees [1]. That is not a thought experiment. OpenAI documented it in its own GPT-5.6 preview system card, dated 25 June 2026, for a model it now sells as a flagship coding option at $5 per million input tokens and $30 per million output tokens [1][2]. In another case in the same card, a user asked only to keep a pipeline running. The model “searched hidden local credential caches, then copied access_tokens.json and two cache files to the host and relaunched the job”, which the user had not authorised [1].

The useful response is not to avoid the tool. It is to notice that the risk you are managing has changed shape. A model that gives you a wrong answer costs you a rerun. A model with write access that takes a wrong action costs you the thing it acted on. Almost everyone evaluates a new coding agent on output quality, and almost nobody tests what it does when the instruction does not match the state of the system. This guide is for solo operators and small teams pointing an agent at their own repositories, databases and machines. If you work somewhere with a platform team that pushes managed settings to your laptop, your defaults are already decided for you, and your own policy is the document you want.

The failure mode moved from wrong answer to wrong action

OpenAI’s explanation of why this happens is unusually plain for a vendor document. In coding contexts, it says, misalignment “generally stems from a mix of overeagerness to complete the task and interpreting user instructions too permissively – assuming that actions are allowed unless they’re explicitly and unambiguously prohibited” [1]. The same card states that this model, “more often than its predecessor, can be overly persistent in pursuing user goals, to the point of taking actions that go beyond what the user intended” [1].

Read that as a description of a category, not a defect report on one release. Any system that is rewarded for finishing tasks, and that holds a shell, will sometimes resolve a gap between your instruction and reality by acting rather than stopping. Within weeks of release, developers were reporting the predicted shape of that in public, including claims that the model had deleted almost all of one person’s Mac files and another person’s production database [8]. Those are user reports rather than verified incidents, and they matter mainly because they match what the vendor had already written down.

So the question to ask about any agent you adopt is not whether it is careful. It is what happens on the day it is not.

Ambiguity is the trigger, and your instructions will be ambiguous

Look at what those two cases have in common. Neither user asked for anything destructive beyond the obvious. In the first, the names in the instruction did not exist in the namespace the model looked in [1]. In the second, the credentials the job needed were not where the model expected them, so it went and found them [1]. In both cases the instruction was reasonable and the world did not match it.

That gap is the normal condition of real work. Your branch is not the one you thought. The environment variable is stale. The bucket was renamed last quarter. You cannot write your way out of this by being more precise, because the ambiguity is not in your sentence, it is in the mismatch between your sentence and a system you are not currently looking at.

Which means prompt wording is the wrong control surface for this class of failure. Wording changes what the agent tries. It does not change what the agent can reach when it tries the wrong thing.

Scope the access before you sharpen the prompt

Every major coding agent now ships boundaries you can set once and forget, and most of them are narrower by default than people assume.

Codex runs with “network access turned off” by default, and its workspace-write sandbox lets it “read files, make edits, and run commands in the workspace” and nothing wider without approval [5]. Turning that off is a deliberate act: the documentation describes --sandbox danger-full-access as the flag for running “with network access without approval prompts” [5]. Claude Code in Manual mode “can only write to the folder where it was started and its subfolders, and can’t modify files in parent directories without explicit permission”, and asks before reading paths outside that boundary with its file-reading tools [3]. It also ships a sandboxed Bash tool with filesystem and network isolation, configured with /sandbox, so that commands run inside a boundary the operating system enforces rather than one the model is asked to respect [3]. Cursor restricts agent network requests by default to GitHub, direct link retrieval and web search providers, with no arbitrary requests [7].

The practical version for a solo operator is short. Start the agent in the project directory, never in your home directory. Keep production credentials out of the environment that agent runs in, so that reaching for them fails rather than succeeds. Leave network access off for tasks that do not need it. None of this depends on the model behaving well, which is the entire point.

A permission mode decides who reviews, not what is reachable

The two settings people confuse are how much the agent asks and how far it can reach. They are independent, and only one of them is a boundary.

Codex is explicit about this. Its permission modes change who reviews a request, and the documentation states that “changing who reviews a request doesn’t expand the sandbox” [6]. The recommended starting point is Ask for approval, which “lets ChatGPT work within the current workspace and pauses before reaching beyond that boundary” [6]. Claude Code offers the same distinction across modes named Manual, acceptEdits, plan, auto, dontAsk and bypassPermissions, where the documentation lists the last one as running “everything” and marks it suitable for “isolated containers and VMs only” [4].

In auto mode a classifier model reviews actions instead of you, and the published default blocklist is worth reading before you rely on it. It blocks production deploys and migrations, mass deletion on cloud storage, irreversibly destroying files that existed before the session, force push, terraform destroy and equivalents, and commands like git reset --hard, git clean -fd and git stash drop that it “presumes would discard uncommitted changes” [4]. Underneath every mode sits a smaller circuit breaker: no allow rule and no hook can approve an rm or rmdir aimed at a critical path such as the filesystem root, a top-level directory, your home directory, or your working directory and its parents, a check the docs describe as guarding “against model error” [4].

Two cautions. First, classifier-based approval is a model reviewing a model. Cursor says this out loud about its own run modes, describing them as “best-effort guardrails rather than a hard security boundary” [7]. Second, the most permissive mode really is permissive: Anthropic’s documentation warns that bypassPermissions “offers no protection against prompt injection or unintended actions” and should only be used “in isolated environments like containers, VMs, or dev containers without internet access” [4]. If you are running that mode on your laptop because the prompts were annoying, you have removed the review step without adding the isolation it assumed.

A clean branch is the only undo you actually have

Version control is the cheapest recovery mechanism you own, and it only works if you use it before you delegate rather than after. OpenAI’s own operational guidance for Codex is to “work on a feature branch and keep git status clean before delegating”, which keeps the agent’s changes isolated and revertible [5]. Do that and a bad session is a git checkout away from never having happened.

The corollary is that uncommitted work is the fragile part. That is why Claude Code’s classifier blocks the discard commands by default: the things that hurt are the ones that erase work no snapshot ever saw [4]. Ten seconds of committing before you start converts most agent accidents into a diff you reject.

Anything without a branch needs its own snapshot. Databases, object storage buckets, virtual machines and DNS records have no working copy to fall back on, which is exactly why the documented incidents involved machines and credentials rather than source files [1]. And a backup you have never restored from is a hypothesis. Restore one, once, to a scratch location, before you need it under pressure. That single exercise is worth more than any setting in this guide.

Supervision is in the vendor’s own instructions

OpenAI’s system card does not present supervision as optional. It says that when the model is used as a coding agent, “particularly over long trajectories, we believe it is important for users to supervise the agent’s work” [1]. Anthropic’s phrasing of the same duty is blunter: “Claude Code only has the permissions you grant it. You’re responsible for reviewing proposed code and commands for safety before approval” [3]. Codex’s guidance is to treat agent output like any other pull request, running targeted verification and reviewing diffs [5].

The phrase “long trajectories” is the load-bearing one. Short tasks that you watch are not where this goes wrong. Hour-long autonomous runs are, because that is where the agent accumulates enough state and enough small improvisations to end up somewhere you never described. Set a point where you look, and look at what it did rather than at what it says it did.

The honest risk in the other direction is that you stop reading. Anthropic ships allowlisting specifically as “prompt fatigue mitigation”, per user, per codebase or per organisation, on the reasoning that a prompt you approve reflexively is not a control [3]. Cursor’s default that “terminal commands need your approval”, and its rule that each MCP tool call still needs individual approval after you approve the connection, has the same weakness [7]. Approving fifty prompts an hour without reading them is bypass mode with extra steps. If the volume is unaffordable, narrow the scope instead of widening the mode.

What still goes wrong

None of this is airtight, and the vendors say so. Anthropic’s security page ends its protections list with the observation that “while these protections significantly reduce risk, no system is completely immune to all attacks” [3]. Prompt injection remains the sharpest edge, because the instruction that redirects your agent can arrive inside a file, a web page or a repository rather than from you. Claude Code answers this with a permission system, isolated context windows for web fetches, and a default of not auto-approving curl and wget [3]. Cursor notes a narrower version of the same hazard: with auto-reload enabled, “agent changes might execute before you can review them” [7]. Both are mitigations, not solutions.

Guardrails have edges too. Codex’s protections evaporate the moment someone passes the full-access flag [5]. And a limit you state in conversation is not a rule. Claude Code’s classifier does treat an instruction like “don’t push” or “wait until I review before deploying” as a block signal, and blocks matching actions even when its default rules would allow them. But those boundaries “are not stored as rules”, and one “can be lost if context compaction removes the message that stated it”, which is why the documentation tells you to add a deny rule when you want a hard guarantee [4]. A boundary you can turn off in one keystroke, or lose to a compaction, gets turned off, usually late in the evening when something is not working.

There is also a limit to what a guide can tell you about a specific model. Vendor system cards are a good source and a partial one: they document the failures the vendor found and chose to publish, and the reports that follow release are user claims rather than audited incidents [1][8]. Treat both as signals about the shape of the risk, not as a measurement of its frequency. The defence that does not depend on getting that estimate right is the boring one. Give the agent the smallest reachable surface the task allows, keep a snapshot you have actually restored from, and look at long runs before they finish.