Approval Fatigue: Move the Boundary, Not the Approver

This is a decision-gate problem, and the gate fails quietly. Anthropic measured it on their own engineers: sandboxing Claude Code's bash tool cut permission prompts by 84% in internal usage. Before the sandbox, five out of six approval clicks were noise: prompts for operations that a defined boundary could have answered automatically. A human asked to make that many meaningless decisions stops making decisions at all. Then they reach for the flag that ends the asking. The gate fails open one inattentive click at a time.

Every prompt spends attention the next prompt needs

Claude Code's default is a permission-based model: read-only until the user approves each modification or command. Anthropic's own writeup names the failure mode plainly: constantly clicking approve "can lead to 'approval fatigue', where users might not pay close attention to what they're approving, and in turn making development less safe."

The control degrades with use. A permission prompt is only a control if the human reads it, and reading rate falls as prompt volume rises. This is the same dynamic as review capacity, one decision gate over: the gate doesn't fail open all at once, it fails open one inattentive click at a time, and the audit log still shows "approved by human" on every line.

The race to the bottom is organizational, not personal

The 2025-era YOLO-mode stories were about reckless individuals. By 2026 the community had named it as a velocity dynamic. From a March 2026 r/ExperiencedDevs thread titled "Race to the --dangerously-skip-permissions bottom":

"I think many organizations with focus on velocity will end up in a race to the bottom to Claude's --dangerously-skip-permissions or equivalent. Auto-piloting approvals without reading the code are barely an improvement, and I am noticing myself it's getting pretty hard to stay motivated to pay much attention to what the agent is asking."

When AI usage is a KPI and prompts are friction, the prompts lose. The same community window produced "let go for not using enough AI" threads (see Mandates and Measurement). An engineer under velocity pressure, facing dozens of prompts per session, is not making a security decision when they disable permissions. They are responding rationally to a control that was already dead. The race-to-the-bottom thread itself scored low and was mod-removed; it is one practitioner naming the dynamic well, not a survey.

The community's fix recreates the violation one level up

The most telling reply in that thread proposed a workaround: "delegate the permission decision to another agent. I have one set up (Claude) that whenever permission is asked... will evaluate... and approve or deny based on that."

An agent approving another agent's permission requests is the segregation-of-duties violation with extra steps. The permission prompt exists because the requesting agent is not trusted to authorize its own actions. Routing the decision to a second instance of the same model, configured by the same person, prompted from the same context, doesn't add an independent check; it adds a plausible-sounding rubber stamp. A commenter in a parallel regulated-SDLC thread caught the end state: "let AI review the AI generated code so now nobody is responsible anymore." AI reviewing AI can work, but only when the reviewer is a genuinely separate gate with its own criteria and its own record, not a fatigue-removal device (see Author, Never Approver).

The fix that holds: move the boundary, not the approver

Anthropic's sandboxing answer is the right shape because it changes what a prompt means instead of who clicks it. The sandbox enforces two boundaries at the OS level (Linux bubblewrap, macOS Seatbelt):

Anthropic is explicit that you need both: "Without network isolation, a compromised agent could exfiltrate sensitive files like SSH keys; without filesystem isolation, a compromised agent could easily escape the sandbox and gain network access." Inside the boundary, the agent acts freely and no one is asked anything. Prompts now fire only at the boundary, which makes each one rare, anomalous, and worth reading. That is the 84%: not fewer controls, fewer decisions, each carrying more signal. The same logic extends to their cloud product, where credentials never enter the sandbox at all and a proxy validates every git push against the configured branch. Those boundaries are environment work, not gate work: see Sandboxing and Egress Control for how the perimeter is built.

The peer benchmark already circulates in practitioner threads. From a r/devops governance discussion: "Nvidia... you can only use Claude code/Codex with full auto-allow/yolo if you use specific virtual machines in their server farms. If Nvidia isn't letting their employees run yolo mode on their local laptop, then neither should any other company." The unsafe part was never the flag, it was the laptop underneath it: YOLO mode inside a disposable, isolated, credential-free VM is a reasonable operating mode.

One gap: the 84% figure is Anthropic's own internal measurement, and the corpus contains no independent replication of prompt-reduction rates or of how approval attention decays with volume.