When the Command Itself Deceived the “Approve” Button: Claude Code Closes a String of Agent-Permission Loopholes Three Days Running
Commands could be hidden using invisible characters that never appeared in the approval dialog. Here's a rundown of the agent-permission loopholes Claude Code patched in succession across v2.1.221–223 from August 4–6, and the moves you can make right now in unattended setups.
The “Invisible Characters” That Never Show Up in the Approval Dialog
The safety design of a coding agent ultimately rests on one thing: a human hitting “approve.” Tools like Claude Code pop up a confirmation dialog—“Is it OK to run this command?”—before executing a shell command or writing a file, and they only proceed once the user grants permission. But the fix shipped on August 6 in Claude Code v2.1.223 revealed that this last line of defense may have been getting deceived.
Anthropic’s published changelog notes a fix for a bug where “commands padded with tabs or invisible Unicode characters could hide part of the command from the approval dialog.” In other words, the string the user was seeing in the approval dialog diverged from the command that actually ran—a hole where, if you looked only at the visible portion and clicked “allow” because it “looked fine,” the hidden part would run right along with it. Techniques that exploit characters humans perceive as identical (confusable characters) have been flagged before, and this fix belongs to that same lineage.
Three Days, Three Consecutive Permission Fixes
What stands out is that this wasn’t a one-off patch. From v2.1.221 on August 4 through v2.1.223 on the 6th, three releases in a row closed loopholes in permission checks and isolation. Here are the main ones:
| Version | Loophole closed |
|---|---|
| v2.1.221 (Aug 4) | Hidden commands could run inside zsh [[ ]] regex conditionals / paths containing quotes slipped past inspection on Windows / workflow scripts could execute code outside the sandbox via dynamic import() |
| v2.1.222 (Aug 5) | Sessions and sub-agents supposedly isolated in a worktree could run destructive git commands against the main checkout / a PreToolUse auto-allow hook in background processing could bypass tool restrictions |
| v2.1.223 (Aug 6) | Tabs and invisible Unicode could hide part of a command from the approval dialog / bypassPermissions in an agent definition ignored the organization’s “disable policy” / worktree isolation gaps were re-applied across all file-editing and Bash sessions |
None of these are flashy new features—they’re humble “plumbing patches.” But what they share is this: the constraints supposedly imposed on the agent (approvals, the sandbox, working-directory isolation, organizational policy) were not taking effect under certain conditions. That same week, it had been almost exactly a month since the “automatic mode”—in which the agent decides on its own to run things without going through approval—rolled out to all users. The more we hand judgment over to the machine, the more it matters that these “checkpoints” reliably hold.
What Can Happen When the Checkpoints Fail
Coding agents act on cues drawn from externally loaded content—web pages, skill files, MCP server metadata, and the like. If the approval dialog can be deceived, there’s room for malicious instructions to be waved through as “approvals that look safe.” If a destructive git command can leap out of an isolated workspace and reach the main one, that can lead to unintended changes or the destruction of history. Observers have noted that risks like these grow the more you hand an agent broad permissions and run it unattended. It’s worth keeping in the back of your mind as a structural weakness lurking behind the convenience.
On the other hand, it’s a positive sign that these holes were closed at a brisk pace not as reports of external attacks but as entries in the developer’s own changelog, disclosed in concrete detail. The very transparency of the fixes is itself useful input when deciding how to fold an agent into your work.
What You Can Do Now
If you’re running an agent in production, the first move is to update Claude Code to the latest version (v2.1.223 or later). Beyond that, if you’re running unattended within an organization, it’s worth confirming that the disable policy for bypassPermissions is taking effect as intended. If you want to manage marketplace allow/block rules across your whole organization at once, the owner/* wildcard added in v2.1.223 is available. Running things by “just looking at the approval dialog and clicking” is best treated on the assumption that blind spots like this exist—the solid approach is to lean toward a design that narrows the permissions themselves.
References: Claude Code changelog (official) / Releasebot: Claude Code Updates / Claude Code Changelog (August 2026) / TechTimes: Claude Code Seals Bash and Unicode Bypass Gaps / GitHub Issue #29489: Unicode confusable characters can bypass permission rule matching
