Claude Code's Permission Prompt Isn't a Security Boundary

Version 2.1.223 of Claude Code, released August 6, patches four ways an agent could slip a command past the permission prompt you thought was guarding your machine. Read the entries and a pattern jumps out: a Bash command that hides part of itself from the checker, tabs and invisible Unicode that hide text from the approval dialog, workflow scripts escaping their sandbox through dynamic import(), and an agent definition whose bypassPermissions mode ignored the org policy that was supposed to disable it.

Four distinct fixes, one root cause. And it's the same root cause behind the fixes in 2.1.222, 2.1.221, 2.1.219, 2.1.216, and 2.1.214 before it. If you're granting an agent autonomous file and shell access on the strength of that permission dialog, this release is a good moment to stop and reconsider what the dialog actually protects.

The prompt is a parser, and parsers lose

The permission system's job sounds simple: before running a command, decide whether it matches a rule you allowed or denied. The trouble is that "does this command match Bash(git commit:*)" is a question about what a shell will do, and Claude Code answers it by inspecting the text. That gap is the whole vulnerability class.

You can see it in every recent fix. In 2.1.219, zsh could smuggle commands inside [[ ]] regex conditionals the analyzer read as inert text. In 2.1.214, file-descriptor redirect forms that bash parses one way and the analyzer parses another; commands over 10,000 characters that the checker gave up on and auto-approved anyway. In 2.1.216, compound statements with redirects nested inside && lists. Now in 2.1.223, a command that hides part of itself from the check outright, plus tabs and zero-width characters that render the approval prompt lying about what you're approving.

None of these are exotic. A long-standing issue, closed as "not planned," lays out the cheapest version: the matcher leans on startsWith(), so git -C /path commit sails past a git commit block, and echo ok && rm -rf build never triggers the prompt for rm. Options before the subcommand, operators between commands — no exploit payload required, just shell syntax the string comparison doesn't understand. The 2.1.223 fixes are more sophisticated bypasses, but they live on the same fault line: the checker and the shell disagree about what the command is.

This is not a knock on the engineers shipping the patches — it's the nature of building a security boundary out of text inspection over a language as gnarly as shell. You are, in effect, reimplementing a bash parser inside your allowlist, and you will be reimplementing it forever, because the attacker (or a confused model) only needs one construct you got wrong.

What actually changed, and what it's worth

Take the four fixes on their own terms. The Bash and Unicode fixes close specific evasion tricks; useful, incremental. The workflow-sandbox import() fix matters more if you run workflow scripts from untrusted sources, because sandbox escape means code you never approved runs with your process's reach. The most consequential for teams is the fourth: an agent definition using bypassPermissions could override an organization policy that had explicitly disabled bypass mode. If your security team pushed a managed setting turning bypass off fleet-wide, a crafted agent file could have quietly ignored it. That's not a clever evasion — that's a control that didn't do the one thing it was configured to do.

That last one is the tell. The others are cat-and-mouse; this one is a policy-enforcement gap, and it's the kind of thing that erodes trust in the whole managed-settings story that enterprises are betting on.

What this means for how you run it

The honest takeaway isn't "patch and relax." It's that the permission prompt is a usability and mistake-prevention feature, not a containment boundary — and Anthropic's own docs frame OS-level isolation as the real defense. Treat the dialog like a linter, not a firewall.

Concretely, if you let Claude Code run with reduced friction:

• Update to 2.1.223 or later and verify it. Check the running build, not the installer you remember; the CI box and the laptop drift. Everything below assumes the fixes are actually loaded.
• Put the real boundary at the OS. Run anything approaching bypassPermissions inside a container, VM, or the built-in sandbox with sandbox.filesystem and network egress control on. That's what survives a parser bug; an allowlist rule is not.
• Set bypass policy from managed settings and confirm it holds now that 2.1.223 fixes the agent-definition override. Don't assume a disabled control is enforced — test that a bypass agent actually gets refused.
• Don't lean on prefix allowlists for real denials. Bash(git commit:*) and friends are advisory. If a command must never run, block it at the sandbox or the host, where git -C and && can't route around it.
• Scope autonomy per surface. Interactive sessions, background agents, workflow scripts, and worktree-isolated subagents have each had their own bypass fixed recently (the destructive-git-against-main-checkout fix landed just one release earlier, in 2.1.222). Restore autonomy one surface at a time and watch each.

The uncomfortable part: nothing in 2.1.223 changes the architecture. The next version will very likely patch another string-matching gap, because that's what this design generates. The teams who stay safe won't be the ones tracking every changelog entry — they'll be the ones who never trusted the prompt as a wall in the first place, and put a container around it instead.