Can Transactional Undo Fix Claude Code Permission Fatigue?

A new research prototype, Aegis OS (arXiv:2611.08516), offers a third answer to coding agents that keep stopping to ask permission. The fix is not a smarter prompt dialog and it is not flipping on --dangerously-skip-permissions; it is making the agent’s work transactional, so most of what it does can be rolled back and therefore never needs to ask. Aegis OS builds exactly that: a copy-on-write shadow workspace where agents work unsupervised, with authorization prompts reserved for the moments work crosses into irreversible territory. It can all but eliminate permission fatigue, but only for the class of actions a transaction can undo. Everything that leaves the sandbox, every network call and external API mutation, still needs a gate, and the safest secret is the one the model never reads; the prototype’s own authors draw exactly that line. That split, reversible versus irreversible, is the decision this article equips you to make.

The fatigue problem, measured

Permission fatigue is not a vibe. The Aegis OS paper puts a number on the tradeoff operators face: “operators must choose between per-action confirmation prompts, which interrupt workflows on 45%–57% of tool calls in our benchmark trajectories and induce severe authorization fatigue, or unconfined execution (—yolo / —dangerously-skip-permissions), which exposes host files, SSH/cloud credentials, and API tokens to prompt injection and hallucination risks” (Aegis OS preprint). That 45–57% figure is self-reported from the team’s own benchmark trajectories, so treat it as the prototype’s motivation rather than an industry measurement, but the dilemma it describes matches what practitioners actually do. A community tool called cleat exists specifically because developers run Claude Code unattended with permissions skipped; it offers “full autonomous permissions, safely sandboxed in Docker” with per-project isolation so “Your host stays untouched.”

The obvious middle path, letting a classifier auto-approve routine actions, has now been measured too, and it does not hold up. An action-level stress test of Claude Code’s auto mode ran 128 sessions with deliberately ambiguous authorization scope and evaluated 253 state-changing operations, reporting an end-to-end false-negative rate of 81.0%: on this adversarial workload, four out of five scope-escalating actions were allowed. Even on the 160 actions the classifier actually evaluated, the reported false-negative rate was 70.3% with a 31.9% false-positive rate, meaning it both missed bad actions and blocked good ones.

The more structural finding is the coverage gap. The study reports that “36.8% of all state-changing actions fall outside the classifier’s scope,” and specifically that “All Edit/Write tool calls in our dataset have gate_decision: “allowed” with no corresponding classifier invocation in the auto mode debug log, confirming they are routed through Tier 2 without evaluation.” File edits bypassed the ML gate entirely. So the choice is not between annoying prompts and a smart approver. It is between annoying prompts, an approver that misses most of what matters, and no prompts at all.

Three strategies, three different guarantees

The 2026 literature gives platform teams three distinct control strategies, and they are not interchangeable:

• Pre-authorization gating. Evaluate each action before it runs, via rules, permission modes, or a classifier. This is Claude Code’s shipped model: a third-party analysis of Claude Code’s design describes seven permission modes from plan through acceptEdits to bypassPermissions, layering an ML classifier with optional shell sandboxing. Gating is the only strategy that judges an action and can stop an irreversible one before it happens; explicit egress policy under sandbox isolation also pre-empts irreversible exfiltration, but by blocking a channel outright rather than by judging actions. As measured above, classifier gating is weak at scope-boundary reasoning and has tool-path blind spots.
• Sandbox isolation. Contain the blast radius rather than judging each action. SWE-Agent and OpenHands isolate the whole agent environment in Docker containers, per the same design analysis. Isolation does not decide whether an action is authorized; it decides how much damage a bad action can do.
• Transactional rollback. Let the agent act freely inside a reversible state space, then commit or discard its work as a unit. Aider is the closest deployed analog: it “relies on Git as a safety net, making all changes reversible through version control.” Git reversibility is not a transaction boundary, though, and that distinction is where Aegis OS comes in.

A systematization of 39 execution-security papers from 2023 to 2026 makes a point that should shape how you read all three: isolation and access-control research are evaluated in isolation from each other. Papers measure their own mechanism and rarely compare strategies against the same risk classes. The stress test’s authors frame the relationship correctly: “Sandboxing and classification address orthogonal risks: sandboxes prevent unintended system damage, while classifiers (auto mode) gate authorized vs. unauthorized actions within the permitted scope.” Orthogonal risks mean layering, not substitution.

Inside Aegis OS: what the prototype actually does

Aegis OS is a Rust runtime, exposed over MCP and Google’s A2A protocol, that “shifts the authorization boundary from individual tool calls to transactional workspace boundaries.” The mechanism has three parts worth understanding separately.

First, isolation. Each agent runs inside a kernel-enforced OS sandbox, macOS Seatbelt or Linux Bubblewrap with a default-deny --tmpfs $HOME setup that keeps credentials out of the agent’s filesystem view, with a microVM control-plane interface also described. Second, a copy-on-write shadow workspace. The host repository is cloned via APFS clonefile on macOS (the paper reports 0.7–6.3 ms fork times) or Linux ioctl(FICLONE) reflinks with optional Btrfs subvolume snapshots. Third, the transaction itself. The paper’s step two is the payoff: “Step 2 — Green-Zone Speculation (0 Prompts): Inside its shadow workspace, the agent freely edits files, runs compilers and tests inside a kernel OS sandbox, coordinates with peer agents over A2A/IPC, and queries allowlisted APIs using opaque secret placeholders ($AOS_SECRET_*).” Zero prompts, because nothing in the green zone is irreversible: files are shadow copies, secrets are placeholders resolved by the runtime rather than raw values the model can leak, and the sandbox constrains what execution can reach.

At the end of the transaction, work either commits to the host repository (a boundary crossing that still requires authorization) or is discarded. Commit is not free: the paper reports that type and metadata checks via rustc --emit=metadata or incremental cargo check add tens to hundreds of milliseconds at commit time, while full integration suites on large monorepos take seconds to minutes. You are trading mid-task interruptions for end-of-task verification cost.

Crucially, the authors do not claim rollback replaces authorization: “our key insight is that authorization prompts should not guard speculative intermediate actions inside an isolated state space; they should guard irreversible boundary crossings into the host repository or untrusted external networks.” The prototype’s headline promise, eliminating authorization fatigue, reduces to eliminating prompts on reversible work. That is still a large win if the 45–57% interruption estimate is anywhere near right, but it is a bounded claim, and the boundary deserves scrutiny.

What rollback cannot undo

Rollback theory puts hard limits on undo. Work on checkpoint-based rollback recovery establishes the causal-consistency constraint: “an action cannot be undone until all the actions that causally depend on this action have been already undone… we cannot undo the sending of a message until its reception (and the subsequent actions) have been undone.” Once a message leaves and is received, you cannot retract the fact of its receipt. The same logic applies to everything downstream of a network call: an external API mutation, a posted comment, an exfiltrated file. You can roll back your side of the world, not the other side’s.

Secrets sit in a third category: a credential the model has already read into its context is compromised the moment it is read, regardless of whether any file changes are later reverted. This is why Aegis OS’s $AOS_SECRET_* placeholder design matters more than its fast forks; the runtime, not the model, holds the raw secret. The production analogue already exists: a zero-trust healthcare deployment of nine autonomous agents layers gVisor kernel isolation, credential-proxy sidecars “that prevent agent containers from accessing raw secrets,” and Kubernetes NetworkPolicy egress allowlists, shipping controls aimed at exactly the channels rollback cannot touch.

SideKernel’s sandbox taxonomy names the two directions of containment. The south boundary protects the host from the agent; the north boundary is “preventing exfiltration of sandbox data to the internet (or other external networks/endpoints), as well as using the sandbox as a launch point for outbound offensive operations…” The north boundary is the irreversible channel. No transaction boundary contains it; only egress policy, allowlists, and credential proxies do. SideKernel also notes that container isolation is weaker than microVM isolation, which matters when you choose the sandbox that backs your transaction: a rollback wrapped around a porous cage inherits the porosity.

There is one more counterweight. A multi-agent study across eight LLMs found that blocking scope violations and preventing harm are different guarantees: “a runtime authorization layer blocks the crossings and, when the task is winnable, prevents most of the harm, but a residual channel—an agent misreporting its own task’s state to disadvantage a peer—survives enforcement…” Even perfectly enforced boundaries leave harm channels that no boundary mechanism addresses. Re-architecting permissions, transactionally or otherwise, does not automatically reduce harm.

The control-strategy matrix

Mapping each strategy to the risk classes it actually mitigates, based on the evidence above:

One nuance the table compresses: the stress test cites Anthropic’s own sandboxing infrastructure as reducing permission prompts by 84% in Claude Code. That figure is a secondhand citation inside the paper, not vendor-verified, but if it is roughly accurate, sandboxing alone may capture most of the fatigue win without any transactional machinery. Rollback’s distinctive contribution is not prompt reduction (a cage gets you that) but a clean, fast path back to a known-good state after the agent did something wrong inside the cage.

Auditing any “undo for agents” claim

Transactional runtimes will keep arriving. When one does, these are the questions that separate a real transaction boundary from a git commit with better marketing:

1. Where is the transaction boundary? What exactly is captured in the reversible state space: files, process state, environment? A git checkpoint covers tracked files only; a CoW shadow fork covers the workspace; neither covers what the agent sent elsewhere.
2. How does it handle nested and cross-process actions? Agents spawn subprocesses, peer agents, and IPC. Rollback theory requires causal consistency: dependents must be undone first. Ask whether checkpoints propagate across processes or whether a forked process orphans state.
3. What is the crash-recovery story? Crash-recovery research shows restore time depends on checkpoint granularity: coarse checkpoints mean redoing long stretches of work, fine ones cost runtime overhead. Every transaction scheme inherits this tradeoff; ask where the checkpoints are.
4. What escapes the rollback? Network calls, external API mutations, secrets read into context. If the answer is “nothing escapes,” the claim is wrong by construction.
5. What does commit cost, and who verifies? Aegis OS reports tens to hundreds of milliseconds for incremental checks and seconds to minutes for integration suites. A commit gate that takes minutes re-creates the fatigue problem at a different point in the workflow.
6. Whose evaluation is it? The 39-paper survey records a transactional sandbox reporting 100% interception and 100% rollback success “in its own evaluation.” That is a different system from Aegis OS, self-reported, and not independently replicated. Discount self-benchmarks accordingly.

What you can ship today

No mainstream coding agent ships transactional semantics natively (the Aegis authors describe current CLIs as mutating the live host working tree in place without transactional rollback); Claude Code’s shipped model is still gating plus optional sandboxing. Aegis OS, though, is no longer paper-only: its repository offers brew-based install, an enforced runtime started with aegis-os run -- claude and marked ”✅ Verified on Linux (bwrap —bind-fd) & macOS Seatbelt across claude, opencode, agy, hermes,” a 64GB isolated cloud sandbox tier, a separately listed paid cloud console (Pro, $29/mo), and the open-source implementation and benchmark suite. The decision-relevant evidence sits in the October 2026 preprint: the authors report that “Across 1,500 tool calls in 50 controlled trajectories and 28,087 tool calls across 52 real coding-agent session logs, Aegis OS reduces human confirmation prompts by 94.19%–99.88% (controlled) and 90.7%–97.9% (real sessions, lowering IPR from 53.31% under per-mutation prompting and 28.54% under prefix allowlists to 1.12%)” (Aegis OS preprint). The paper also reports that across 80 end-to-end adversarial attacks in eight categories, the attack success rate fell from 100.0% to 0.0% on both macOS and Linux, and that a nine-row ablation (eight components plus the full system) shows switching off any one re-opens the exact category it guards.

All of those results are self-reported, the repository’s enforced-runtime benchmarks included, and the paper’s own validity section names their limits: the real-trace corpus comes from a single engineering organization; the 80 attacks were constructed to test the eight threat categories, so the unconfined baseline succeeds 100% by construction and the ablation diagonal is partly by design; and the Linux numbers were measured inside a virtual machine on the same host as the macOS runs. Everything here about current Claude Code behavior comes from third-party papers rather than Anthropic documentation, so verify permission modes and any checkpoint or rewind features against vendor docs before acting on them.

What ships now: Docker cages that grant full autonomy inside the cage (SWE-Agent, OpenHands, cleat), microVM isolation on the macOS side (SideKernel, a research sandbox), git-based reversibility (Aider), the layered production pattern from the healthcare fleet (kernel isolation plus credential proxies plus egress allowlists), and Aegis OS’s enforced runtime, installable today. That fleet’s experience adds one more honest data point: of its four layers, the prompt-integrity layer was the most brittle. The stress test’s own measurements point in the same direction, without ranking anything: an 81.0% end-to-end false-negative rate on scope-escalating actions, and Edit/Write calls that bypassed classifier evaluation entirely.

The verdict

Spend your prompts only on irreversible boundary crossings. Keep hard gates or egress policy on network calls, external API mutations, and secret access, and move everything else into a reversible, sandboxed workspace: git-style checkpoints or Docker cages today, or Aegis OS’s installable enforced runtime if its self-reported evaluation holds up beyond the authors’ own benchmark. Rollback complements sandboxing and gating; it replaces neither, and a Claude Code handbook’s framing of instruction, permission, sandboxing, and OS isolation as four distinct control layers, of which only two are enforced, is a fair warning against treating any single mechanism as sufficient.

So, can transactional undo fix permission fatigue? For the fatigue itself, yes, plausibly: prompts disappear from the work that never needed them. For the security problem underneath the fatigue, no: the risks that mattered most were never the file edits. They were always the calls that leave the machine, and no transaction can call those back. Design your permissions accordingly.

Frequently Asked Questions

How do I install and run Aegis OS with Claude Code today?

Aegis OS, though, is no longer paper-only: its repository offers brew-based install, an enforced runtime started with aegis-os run -- claude and marked ”✅ Verified on Linux (bwrap —bind-fd) & macOS Seatbelt across claude, opencode, agy, hermes,” a 64GB isolated cloud sandbox tier, a separately listed paid cloud console (Pro, $29/mo), and the open-source implementation and benchmark suite.

What are the limitations of the Aegis OS evaluation results?

All of those results are self-reported, the repository’s enforced-runtime benchmarks included, and the paper’s own validity section names their limits: the real-trace corpus comes from a single engineering organization; the 80 attacks were constructed to test the eight threat categories, so the unconfined baseline succeeds 100% by construction and the ablation diagonal is partly by design; and the Linux numbers were measured inside a virtual machine on the same host as the macOS runs.

What specific actions cannot be undone by transactional rollback?

Rollback theory puts hard limits on undo. Work on checkpoint-based rollback recovery establishes the causal-consistency constraint: “an action cannot be undone until all the actions that causally depend on this action have been already undone… we cannot undo the sending of a message until its reception (and the subsequent actions) have been undone.” Once a message leaves and is received, you cannot retract the fact of its receipt. The same logic applies to everything downstream of a network call: an external API mutation, a posted comment, an exfiltrated file. You can roll back your side of the world, not the other side’s.