- Book: LLM Observability Pocket Guide
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
In mid-2013, nearly half the people who clicked past Google Chrome's certificate warning made up their minds in under a second and a half. Devdatta Akhawe and Adrienne Porter Felt measured it in Alice in Warningland, a field study of over 25 million real warning impressions from Firefox and Chrome telemetry. "47% of users who clicked through the warning made the decision within 1.5s," they wrote. The people who heeded it took longer: 47% of them left within 3.5 seconds.
Now think about the last permission prompt your coding agent showed you. How long did you look at it?
Here is my position. Approving every command is not a safety model. A prompt that fires all day becomes a prompt you dismiss, and the research on security warnings has said so for more than a decade. The fix is fewer prompts, so put the agent behind a sandbox, a short list of rules and a worktree per task. Then the few prompts that are left are the ones worth reading.
What 25 million browser warnings showed
Start with the good news, because the paper leads with it. Users "continued through a tenth of Mozilla Firefox's malware and phishing warnings, a quarter of Google Chrome's malware and phishing warnings, and a third of Mozilla Firefox's SSL warnings." The authors' conclusion is that warnings "can be effective in practice."
Chrome's SSL warning was the outlier. Users clicked through it 70.2% of the time. The authors offered two readings: "either users are not heeding valid warnings, or the browser is annoying users with invalid warnings and possibly causing warning fatigue." Certificate errors often come from misconfigured servers rather than attacks, and the paper says what that does to people: "The prevalence of a large number of such false warnings can potentially train users to consider all SSL warnings false alarms and click through them without considering the context."
They also found that "warning frequency is inversely correlated with user attention," and that people clicked through the more frequent certificate errors faster. Firefox's extra clicks didn't explain the gap between the browsers either: "we do not believe this is the cause of the rate gap."
So the warnings that worked were almost always right. The one that often fired on harmless misconfigurations had the worst click-through rate, and the authors suspect it trained people to click. Most of what a coding agent asks about is routine too: run the tests, install a package, write a file in the repo. The paper doesn't make this leap. I do: each routine prompt is a warning about something that turns out to be fine.
Your brain stops looking by the second time
A team at Brigham Young University looked at the brain itself. In a CHI 2015 paper, Bonnie Brinton Anderson, Anthony Vance and colleagues put people in an fMRI scanner and showed them security warnings over and over. They report "a dramatic drop in the visual processing centers of the brain after only the second exposure to a warning," with further drops after that.
Their countermeasure was a polymorphic warning that changes its appearance each time. It was "substantially more resistant to habituation than conventional warnings." A 2016 journal paper from the same team reports 25 participants in the scanner and 80 more tracked by mouse movement on their own computers.
A 2018 follow-up in MIS Quarterly stretched the timeline. It measured habituation across a five-day workweek with fMRI and eye tracking, then ran a three-week field study with permission warnings shown while people installed apps. For standard warnings, adherence dropped substantially over the three weeks. The authors also found that attention "recovers at least partially between workdays" when people aren't seeing the warnings.
Two things carry over to your terminal. Habituation starts almost at once, and it tracks how many times you see the same thing. You can't redesign your agent's prompt so it looks different every time. You can control how often it fires.
Coding agents are running the same experiment
Anthropic has published the agent version of these numbers. A March 2026 engineering post says "Claude Code users approve 93% of permission prompts," and that "over time that leads to approval fatigue, where people stop paying close attention to what they're approving." An August 7, 2026 post puts the figure at 97%.
The same August post describes a controlled study. Anthropic hired 1,053 paid testers through a research vendor. "Partway through each session, a single permission prompt was swapped for a clearly dangerous command." The testers "caught the dangerous command just 13.6% of the time (143 of 1,053)." Then comes the habituation curve: "they blocked about 17% of dangerous commands early in a session, dropping to about 5% after 50 or more prior prompts."
That is the browser result again, with a terminal instead of a certificate. Read it with the source in mind: Anthropic published the study alongside making its auto mode the default on most plans, so it supports a product decision. The testers "worked in a test environment set up specifically for the study," and they "knew they were being evaluated." Still, the direction matches warning research that came from browser telemetry and brain scanners, not from an agent vendor.
Auto mode is one answer: a classifier reviews actions instead of you, and in the same study it blocked 89% of the dangerous commands. Anthropic says it "does not eliminate risk" and still recommends reviewing high-stakes production changes yourself. Whether or not you use it, the cheaper move is to delete the prompts that never needed to exist.
Ask less, so the asks get read
Each of these removes a whole class of prompt.
Sandbox the shell. Claude Code's sandbox is a boundary the operating system enforces around the shell commands Claude runs. It's off by default; run /sandbox in a session to turn it on. It runs on macOS, Linux and WSL2; on native Windows, Claude Code runs commands unsandboxed. In auto-allow mode, "Claude Code approves a command automatically, with no prompt, when the command runs inside the sandbox." Anthropic's October 2025 post on sandboxing says that "in our internal usage, we've found that sandboxing safely reduces permission prompts by 84%."
Codex takes a similar approach. In a version-controlled folder it recommends its Auto preset, workspace-write with on-request approvals, so "commands allowed by the sandbox can run without approval," and network access stays off unless you enable it.
Keep the prompts you actually want. Claude Code evaluates permission rules "in order: deny, then ask, then allow." Deny what should never happen. Put the few actions you want to see every time under ask. The sandboxing docs say content-scoped ask rules like Bash(git push *) "still force a prompt even for sandboxed commands." That's the design you want: the push prompt is rare, so it gets read.
A project .claude/settings.json along those lines:
{
"permissions": {
"allow": ["Bash(npm run *)"],
"ask": ["Bash(git push *)"],
"deny": ["Read(./.env)", "Read(./secrets/**)"]
},
"sandbox": {
"enabled": true,
"allowUnsandboxedCommands": false,
"filesystem": {
"denyRead": ["~/.ssh", "~/.aws"]
},
"network": {
"allowedDomains": ["registry.npmjs.org"]
}
}
}
The docs explain each line. Sandboxed commands can read "most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials" by default, hence denyRead. The sandbox wraps shell commands only, and the built-in file tools follow "permission rules instead," hence the Read deny rules. allowUnsandboxedCommands: false turns off the retry outside the sandbox when a command fails. And a Bash deny rule matches command text, not the program: the docs show Bash(rm *) stopping rm -rf build/ but not /bin/rm -rf build/. Rules shape the prompts. The sandbox is the boundary.
Codex's recommended Auto preset, written out in config.toml:
sandbox_mode = "workspace-write"
approval_policy = "on-request"
Give every task its own worktree. A linked worktree is a second working folder on its own branch, attached to the same repository:
git worktree add -b agent/fix-login ../fix-login
cd ../fix-login
Start the agent there. Claude Code's sandbox lets shell commands write to the working directory by default, so the agent's writes land on one branch you can throw away. The sandbox doesn't cover Claude's own file edits, which still prompt by default. The worktree is what makes it reasonable to start the agent in the acceptEdits permission mode, which accepts file edits for the session without asking. Then you review one diff at the end instead of approving each edit as it happens. That trade only works if you actually read the diff. Commits work from inside the worktree too: a linked worktree keeps them in the main repository's .git folder, and the sandboxing docs say the sandbox allows writes to that shared folder in this case, while hooks/ and config inside it stay write-denied.
Where Hermes fits, and where it doesn't
I build Hermes IDE, so weigh this section with that in mind.
Hermes doesn't make prompts rarer. Every agent runs its own interface in a real terminal, so the sandbox, the rules and the approval prompts are the agent's own. What Hermes changes is where the prompts that remain end up. Every session shows one status (working, needs approval, asked you, done, error or idle) and says when that status is a guess. The attention inbox counts the agents blocked on you, and ⌘I (Ctrl+Shift+I on Windows and Linux) jumps to the one that has waited longest. You answer in that agent's own terminal. Hermes never answers a permission prompt for you and never types into a terminal on its own. Notifications fire when an agent is blocked or done, and never for the session you're already looking at.
That inbox is the part that matters here. When prompts are rare, the risk shifts from rubber-stamping to never seeing the prompt at all, because it's sitting in a background terminal. An inbox fixes that without answering anything.
⌘N (Ctrl+Shift+N) starts each task on its own hermes/ branch in its own worktree.
Hermes 2.3.4's New task sheet: Claude Code on a new hermes/ worktree in Accept edits mode, with a preview of the command it will run.
A worktree is not a sandbox. It keeps tasks off each other's files, but a command running in it can still reach your home directory and the network unless the agent's own sandbox stops it. Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux. It isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor. Download it or read the source on GitHub.
Count your prompts
A yes you give without reading isn't a review, however many times you give it.
Tomorrow, count the prompts your agent shows you, and how many of them you actually read. If the second number is a lot smaller, the first one is too high.
Which command do you still want your agent to ask about every single time? Tell me in the comments.
If this was useful
Asking less moves your review from before a command runs to after it: what the agent ran and what it touched, and what that cost. That after-the-fact record is what the LLM Observability Pocket Guide is about. It covers picking the tracing and eval tools that let you answer those questions for an LLM system. If you run several agents, Hermes IDE is where the prompts that are left wait for you.
Top comments (0)