- Book: Prompt Engineering 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
The exploit was one line of JSON.
"chat.tools.autoApprove": true
A prompt injection planted in a source file told GitHub Copilot to write that line into a VS Code settings.json. With it set, the agent stopped asking before it used its tools, and the injected instructions could run shell commands on the developer's machine. The researcher behind Embrace The Red reported it to Microsoft in June 2025, and it was fixed as CVE-2025-53773 in that August's Patch Tuesday. The write-up lists where such an injection can sit: "a source code file, web page, GitHub issue, tool call response, or other content."
Later that month, the s1ngularity malware shipped inside compromised Nx packages on npm. Wiz's analysis says it looked for AI CLIs on every machine it landed on and ran them as claude --dangerously-skip-permissions, gemini --yolo and q chat --trust-all-tools.
Both attacks started by switching off the question. My position: once your coding agent stops to ask, only you should answer. That rules out wrappers, hooks that say yes unless a denylist matches, and scripts that watch the terminal and send y.
The prompt is where injected text meets your shell
A coding agent reads text you didn't write all day: READMEs, issues, docs pages, tool output. Any of it can carry instructions. In May 2025, Invariant Labs showed a malicious GitHub issue in a public repo hijacking an agent connected to the GitHub MCP server and getting it to leak data from the user's private repositories. The trigger was a normal request to look at open issues. Their note on why it works: "many users already opt for an 'Always Allow' confirmation policy when using agents, and stop monitoring individual actions."
The vendors put the same warning in their own docs. Claude Code's permission modes page says bypassPermissions "offers no protection against prompt injection or unintended actions," and to use it only "in isolated environments like containers, VMs, or dev containers without internet access." OpenAI's Codex docs label --yolo "Dangerous full access": no sandbox, no approvals, not recommended.
So the prompt is where attacker-controlled text becomes a command on your machine.
Yes, you click "Allow" without reading. Anthropic measured it
Anthropic has the best evidence against this position. Its engineering post on auto mode says "users accept 93% of" manual prompts. Its August announcement puts the figure at 97%. In a controlled study with 1,053 paid testers, "human review caught just 13.6% of dangerous commands, while auto mode caught 89%." Human block rates fell to "about 5% after 50 or more prior prompts."
If you say yes to everything, you are an auto-approver with a slower reaction time.
Look at what the study measured, though: one dangerous command hidden among routine prompts, and detection dropping as the prompts piled up. That describes a volume problem, so cut the volume: fewer prompts, and real attention on the ones left.
Approval fatigue is real. Handing the button to a machine outside the agent doesn't fix it.
Where the line goes
Two different things get called auto-approval, and they deserve different answers.
The first is policy inside the agent, deciding what needs asking at all: allow and deny rules, a sandbox, and the vendors' own reviewers. Since v2.1.283, auto mode is Claude Code's starting mode in the terminal and VS Code, per the docs. Codex has auto-review, opt-in through approvals_reviewer = "auto_review". Both reviewers are built into the agent, and Anthropic's is designed with injection in mind: its classifier "sees only user messages and the agent's tool calls," never tool results, and a separate probe scans tool outputs.
Both fail toward you. Claude Code escalates to you after 3 blocks in a row or 20 in a session, and Codex interrupts the turn after 3 consecutive denials or 10 in the last 50 reviews.
Their makers also publish the misses. Anthropic calls a 17% false-negative rate on real overeager actions "the honest number" and says auto mode "is not a drop-in replacement for careful human review on high-stakes infrastructure." OpenAI says auto-review is not "a deterministic security guarantee" and "can still make mistakes, especially in adversarial or unusual contexts."
You can argue about those numbers. At least they're published.
The second thing is a tool outside the agent answering a prompt the agent already decided to show you: a script that reads the screen and sends a keystroke, or a hook that returns "allow" for everything a denylist doesn't catch. That's where I draw the line.
- The prompt in front of you is what's left after the agent's own policy passed. Rules didn't cover it, and the reviewer, if there is one, handed it back. An outside tool that answers it approves exactly the set the agent flagged as uncertain.
- Denylists don't hold. In July 2025, Backslash Security found four ways past Cursor's auto-run denylist, among them Base64 encoding, subshells and quote tricks like
"e"cho, and called the denylist, as it was then implemented, "woefully inadequate." Its advice: "use the allowlist setting instead." - The approver's config is a file, and the Copilot bug shows that a file the agent can write is a file an injection can write. Claude Code treats this as a real risk:
.vscode,.gitand.claudeare protected paths, allow rules don't pre-approve writes there, and in Manual mode they always prompt.
Fix the fatigue by routing, not answering
Start by cutting prompts at the source, inside the agent. In Claude Code, allow the boring commands and deny the dangerous ones in .claude/settings.json. The rule syntax follows the permissions docs:
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)"
],
"deny": [
"Bash(git push *)",
"Read(./.env)"
]
}
}
Deny rules block in every mode, including bypassPermissions. Treat pattern rules like these as a speed bump: the permissions docs list git -C . push origin main as a variant the push rule misses, so pair them with a sandbox.
In Codex, the sandboxing docs pair these two settings for lower-risk local automation:
sandbox_mode = "workspace-write"
approval_policy = "on-request"
Commands the sandbox allows run without asking, writes stay in the workspace, and network is off by default. Only what crosses the boundary reaches you.
If you want an agent fully hands-off, put it somewhere it can't hurt you: a container or VM running the agent's full-access mode, as both vendors document, or the vendor's own reviewer if you accept its published miss rate. For CI, Claude Code's --permission-mode dontAsk with --allowedTools denies anything not on the list instead of asking.
Then route what's left. The 5% block rate came after 50 or more prior prompts. If you run three agents, you get three streams, each interrupting you in a different terminal. Put them in one queue and take the oldest first. Sit down to answer them on purpose, read each command, and say no when you don't recognize it.
One queue, oldest first, a human at the front.
What Hermes does with a permission prompt: nothing
I build Hermes IDE, so weigh this section with that in mind. Its design principles put this rule in writing: "Observe, never answer. Hermes reads agent signals but never answers a permission prompt or a question on your behalf." And: "Hermes never types into a terminal on its own; the only allowed write is one visible line you trigger yourself."
What it does instead is the routing part. By default each agent runs in a real terminal (an opt-in Agent view for Claude renders the conversation instead), and every session shows one status: working, needs approval, asked you, done, error or idle, with a note when the status is a guess. The attention inbox counts the agents blocked on you. ⌘I (Ctrl+Shift+I on Windows and Linux) jumps to the one that has waited longest, and you answer in that agent's own session, in its own words. Notifications fire when an agent is blocked or done, and skip the session you're already looking at.
What it doesn't do: Hermes doesn't sandbox agents or enforce permission rules of its own. A terminal session runs exactly as it would in any other terminal, so the agent's own sandbox and rules are what limit an approved command. Set those up first. Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux. It is not affiliated with Nous Research, Anthropic, OpenAI or any agent vendor. Download it or read the source.
Where do you draw the line? Is a vendor's built-in reviewer fine with you but a third-party yes-script not, or do you run everything in a container and skip prompts entirely? Tell me in the comments.
If this was useful
Prompt injection is the reason the permission prompt matters, and my Prompt Engineering Pocket Guide covers prompt injection alongside system prompts and context engineering. If you run more than one agent, Hermes IDE puts every prompt that's waiting on you in one place, and leaves the answer to you.
Top comments (0)