Claude Code Just Patched Four Ways Its Permission Prompts Could Be Silently Bypassed
The permission prompt in Claude Code is the thing standing between "the agent wants to run this command" and "the agent ran this command." Claude Code 2.1.223, released August 6, patched four separate ways that boundary could be quietly walked around, and none of them are edge cases you'd only hit on a weird config. One of them means the command displayed in the dialog you're reading right now might not be the full command that actually executes. If you're running Claude Code against anything with real credentials or write access, this is the changelog entry worth reading slowly instead of skimming past.
What actually shipped
Four fixes in 2.1.223 sit specifically in the permission and approval layer, not scattered across general bug fixes elsewhere in the tool. Straight from the official changelog:
- A Bash permission bypass where a crafted command could hide parts of itself from the permission check
- Permission prompts padded with tabs or invisible Unicode characters, which could hide part of the command from the approval dialog you're looking at
- Workflow scripts using dynamic
import()to run code outside the workflow sandbox - A permission gap where an agent definition's
bypassPermissionsmode ignored an org policy that disabled bypass mode
Same release also added owner-wildcard entries for marketplace allow/block lists, a warning when a restricted subagent model silently falls back to the parent model, and a /teleport hint for continuing cloud sessions locally. Those are useful, but they're not the reason to stop and read this one. The four items above are.
Why the Unicode one is the scary one
Claude Code's entire safety pitch for agentic coding rests on one sentence: the agent shows you the command before it runs, and you decide. That only works if what you're shown is what actually executes. The Unicode fix closes a gap where tabs or invisible characters could pad a command so that part of it never rendered in the approval prompt. You'd see a command that looked fine, click allow, and something you never saw would run alongside it.
This is different in kind from most Claude Code bugs. A crash or a stuck spinner costs you time. A permission-display gap costs you the one signal you're relying on to catch a dangerous action before it happens. I click through a lot of these prompts fast, because most of the time the command really is what it looks like: npm install, a git commit, a read-only grep. The problem is that "most of the time" is exactly the assumption an attack like this is built to exploit. You train yourself to trust the dialog, and the dialog is the thing that got quietly padded.
Worth noting: this isn't the first time invisible Unicode has shown up in a Claude Code permission fix. A July 20 release (2.1.216) already fixed PowerShell permission validation mishandling invisible Unicode in commands. The August 6 fix covers the same category of trick, but in the Bash approval dialog itself rather than in a platform-specific validator. Two related fixes about seventeen days apart is a pattern, not a one-off.
The bypassPermissions gap matters even solo
The fourth fix is easy to shrug off if you're a team of one: "org policy" sounds like a Fortune 500 problem. It isn't. If you've ever set up a bypassPermissions-mode agent for yourself, for a client, or inside a CI pipeline, and you were relying on a policy setting to mean "no bypass mode, full approval required, no exceptions," that setting could have been silently not applying to certain agent definitions. The fix means the enforcement layer now actually matches what the policy says. Before it, the policy and the behavior could disagree, and you'd have no obvious way to notice, because everything would look locked down until an agent definition quietly ignored it.
For a solo operator who does contract work or manages access for a client, this is the kind of gap that turns into a very bad conversation. "I told the agent not to bypass permissions" and "the agent didn't bypass permissions" turned out to be two different claims.
Part of a pattern, not an outlier
This is the second Claude Code release in a matter of days that closes a real security gap around agent autonomy. On August 4, version 2.1.221 added mode: "mask" for sandbox credential files on Linux and WSL, so a sandboxed command reads a sentinel copy of your .env file instead of the real one, with the actual value substituted back in only when a request leaves through the sandbox proxy (I wrote about that one in detail). Two days later, 2.1.223 closes four gaps in the approval layer itself. Neither of these is Claude Code being unusually leaky compared to other coding agents. What they actually show is how fast the attack surface grows once you give an agent write access, network access, and a permission system that has to correctly parse arbitrary shell syntax, arbitrary Unicode, and arbitrary org configuration, all at once, every single time. Every one of those parsing surfaces is a place a gap can hide, and the pace of fixes just reflects how many surfaces there are.
What I'd actually do
Update to 2.1.223 today if Claude Code touches anything with real credentials, a production database, or write access to a repo you care about. That part is simple and free.
The part that takes actual time: if you or a client have bypassPermissions configured anywhere, go check it again. Don't assume the org policy you set up months ago is still the version in effect. Open the agent definitions you're running, confirm which ones use bypass mode, and confirm the policy you think blocks it actually applies to each one post-update. Fifteen minutes, and it closes the gap between "I have a policy" and "the policy is enforced."
The honest counter-take: none of this means agentic coding tools are unsafe to use, and I'm not switching to reviewing every command by hand. The realistic risk profile for most solo operators is still dominated by mundane stuff, a bad rm, a leaked key in a log, not a nation-state-grade Unicode padding attack aimed specifically at your side project. But "I have permission prompts on" and "I've actually reviewed what this agent can do" are not the same claim, and this release is a decent reminder of the gap between them. Treat the prompt as the security boundary it actually is, not a formality you click through on the way to the interesting part.
Author
Lukas
@lukcombinator