Skip to main content
onext technology
AI 14 October 2026 - 7 min read

Before you give a coding agent permissions, decide how you will undo what it does

Much is said about what an agent may do and little about how to undo what it has already done. Inside the repository almost everything has a way back; outside, not always.

Bernat López
Founder and CEO of onext
Oak board on a carpenter's workbench at dusk, with a thin pencil line and an unused chisel beside it: what can be erased and what cannot, as when undoing what a coding agent does

The Claude Code documentation has a page on checkpoints, the feature that lets you rewind what the agent has edited. The most useful part of that page is not how to use them, but the section on limitations.

There you read, for instance, that checkpoints do not track files modified by shell commands, and that they are not a replacement for version control. It is an honest way of saying something that holds for any tool: rewinding has a perimeter, and what the agent does outside it does not come back with a keyboard shortcut.

Hence the thesis of this piece: before you widen a coding agent's permissions, decide how each thing it will be able to do is undone. The agent acts alone where the change is reversible; where it is not, a person decides.

What can be rewound today

According to its documentation, Claude Code saves a checkpoint before each message that starts a turn, keeps the 100 most recent in the session and lets you go back to any of them with /rewind or by pressing Esc twice. You can restore the code, the conversation or both.

The perimeter is written on the same page:

  • Shell commands. Files deleted, moved or copied with rm, mv or cp are not recovered by rewinding. Only edits made with the agent's own file editing tools are tracked.
  • Subagents. In general, rewinding does not restore what they edit; the documentation says to use git to revert it.
  • External changes. What is touched outside the session, by hand or from another session, is normally not tracked.
  • History. Checkpoints are for recovering a session, not the project's history: that is still what git is for.

Limit All of this lives inside the repository. A database, a cloud service or a sent message is outside Claude Code's checkpoints.

The reversibility map

Before granting a new permission, a simple map helps: where the agent will be able to act, whether that can be undone, with what, and who decides in each case.

Where the agent acts Can it be undone? With what Who decides
Editing files with its own tools Yes, within the session Checkpoint and git The agent can act alone
Commits on a dedicated branch Yes Revert the commit or discard the branch The agent acts; review decides what gets merged
Files touched with shell commands Only if they were in git git; anything unversioned is lost A person, before commands that delete
Development or test database If there is a copy that can be restored Prior copy or disposable environment The agent, only if the copy exists
Shared or production data Often not, or not fully Backups, if they exist and have been tested A person
External services: sending, publishing, charging, opening a ticket No Nothing: at most, a later correction A person

The first row and the shell command limitation come from the Claude Code documentation; the rest of the table and the "who decides" column are onext's own reading

The rule

The agent acts alone where the change can be undone. Where it cannot, a person decides, before and not after.

The rule does not ask whether the agent is good, but how much a mistake costs. An error undone in a minute is a small cost, even if it repeats. An error with no way back can be expensive even if it happens only once. That is why the line is drawn by reversibility, not by trust.

Permissions first, reversibility after

Permissions answer what the agent is allowed to do; we explain this in your agent's security lies in its permissions, not in the prompt. Reversibility answers what happens when, with those permissions, it gets something wrong. Both questions are asked together: a permission whose effect cannot be undone is the one that deserves human approval.

That approval cannot depend on the model reading an instruction like "be careful with the database". What must be enforced goes into controls that apply themselves, as we explain in Claude Code for teams: context is not control. And the map has to be reviewed every time a new tool is connected: every MCP server adds actions outside the repository, and many have no way back, as we explain in MCP servers: the integrations nobody governs.

Reverting is also a skill

DORA, Google's research programme on software teams, published a model with seven capabilities in September 2025 that amplify the benefits of AI. One of them is strong version control: according to its analysis, frequent use of rollback features boosts the performance of AI-assisted teams. Its recommendation is direct: as AI increases the velocity of changes, version control becomes a critical safety net, and teams should become highly proficient in using rollback and revert features.

In other words, being able to undo is not enough: the team has to know how to do it quickly and without drama. It is one of the parts of the safety net to check before bringing in an agent, as we explain in before the agent, the safety net.

Five decisions before widening permissions

  1. List the places where it will be able to act. Repository, terminal, databases, cloud and every connected integration.
  2. Write down how each one is undone, and test it once. A backup nobody has restored is not yet a way back.
  3. Take what has no way back out of the agent's reach. Or leave it behind a person's approval.
  4. Give it a dedicated branch and disposable environments. What it does there is thrown away whole if it goes wrong.
  5. Review the map with every new tool. One more server or integration changes what the agent can break.

The dedicated branch does not remove review: whatever the agent wants to bring into the main branch still goes through someone who understands what the change does and why, as we explain in reviewing AI-generated code.

The market already sells it as a service

On 5 October 2026, LTM announced BlueVerse AgenTraceIQ, an offering to adopt AI agents securely that, according to its press release, "enables rapid restoration of systems, data, configurations, and repositories following unintended or destructive actions". It includes Rubrik Agent Cloud for Claude Code.

That such a product exists says the problem is real and that large companies already face it. But much of it is solved with what the team already has: git, branches, disposable environments and tested backups. What no tool solves is the email already sent or the shared data that had no copy. That is decided beforehand, and a person decides it.

Where onext fits in

In AI-Accelerated Development, a person decides where there is risk. The first step is a free diagnostic, and if the diagnostic shows no difference, there is no Quick-start. If you want to review what your team's agent can touch today and how each thing is undone, it is a good conversation to start with.

Frequently asked questions

What is a checkpoint in Claude Code?

It is a copy of the state of the files that Claude Code saves before each message that starts a turn. With /rewind, or by pressing Esc twice when the input is empty, you can go back to that point. It only covers edits made with its file editing tools, and the documentation itself makes clear that it does not replace version control.

Do checkpoints undo what the agent does with shell commands?

No. The Claude Code documentation says so explicitly: it does not track files modified by Bash commands such as rm, mv or cp. If those files were in git with no pending changes, git can recover them; if they were not under version control, there is no copy to go back to.

What about changes made by subagents?

In general, rewinding does not restore their edits, and the documentation recommends using git to revert them. The exception is a forked skill running in the foreground, because it edits during your own turn.

Which actions of an agent cannot be undone?

Those that leave the repository without a prior copy that can be restored: deleting data without a tested backup, changing the configuration of a shared service, sending a message, publishing something or triggering an operation in an external system. There, at most, you correct it afterwards.

Does this mean an agent should not have terminal access?

Not necessarily. It means that, before giving it that access, it is worth knowing which commands can destroy something with no way back, and keeping them out of its reach or behind a person's approval.

Do you need to buy a restore tool to use agents?

There are already services that restore systems, data and repositories after destructive agent actions. But much of the problem is solved with what the team already has: git, a dedicated branch for the agent, disposable environments and tested backups. What cannot be undone is not fixed by any tool: a person decides it beforehand.

Sources

Bernat López
Written by
Bernat López
Founder and CEO of onext

Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.

LinkedIn →

Does your team know what it can undo if an agent gets it wrong?

Let's talk about how your team works today and where a person should decide.

See how we work

What we build stays with your team.