Skip to main content
  1. Articles/

Claude Code's Third Security Patch in Three Days

·837 words·4 mins·
Florent Clairambault
Author
Florent Clairambault
CTO & software engineer — writing daily about spec-driven development and agentic coding

Claude Code’s Third Security Patch in Three Days

Two days ago this blog covered v2.1.221-222 and its worktree isolation fix — the gap where subagents inside an isolated worktree session could still run destructive git commands against the main checkout. Today, per the official Claude Code changelog, v2.1.223 shipped with four more fixes in the same category: permission checks and sandbox boundaries that didn’t hold under specific conditions. That’s three releases in a row, three straight days, all clustered around the same underlying theme.

What v2.1.223 Actually Fixes
#

Reading the changelog entry by entry, the security-relevant items are specific about what was wrong, not just that something was fixed:

  • A Bash permission bypass via hidden commands. “A crafted command could hide parts of itself from permission checks” — meaning the text shown in the approval dialog didn’t necessarily match what actually executed. Paired with a second, related fix: commands padded with tabs or invisible Unicode characters could hide part of the command from the same approval dialog. Both point at the same failure class — an attacker (or a prompt-injected instruction) crafting a command string that displays as benign but executes as something else.
  • A workflow sandbox escape via dynamic import(). Workflow scripts — the JavaScript-like orchestration scripts this blog has covered as the mechanism behind multi-agent fan-out/pipeline patterns — could use import() to run code outside the sandbox they’re supposed to be confined to. That’s a real containment breach for a feature explicitly designed to run untrusted or semi-trusted orchestration logic.
  • A bypassPermissions policy gap. An agent definition’s bypassPermissions mode could ignore an org’s policy explicitly disabling bypass-permissions mode. In other words, an org that had turned off the ability to skip permission checks entirely could still have that protection overridden by how a specific agent was defined — the exact kind of gap that matters most for enterprise deployments relying on org-level policy as a hard floor, not a suggestion.

None of these come with a CVE number or a standalone security advisory; they’re changelog line items like everything else in the release. But taken together with v2.1.221’s zsh [[ ]] regex bypass and PowerShell quoted-path mishandling, and v2.1.222’s worktree isolation and PreToolUse auto-allow hook bypasses, the pattern across all three releases is the same shape of problem repeating: a boundary — permission dialog, sandbox, org policy — that looked intact but had a specific, findable way around it.

The Rest of v2.1.223
#

The release isn’t only security fixes. A few items worth flagging for teams running Claude Code day to day:

  • Owner wildcard entries ("owner/*") for strictKnownMarketplaces and blockedMarketplaces managed settings, letting admins allow or block every marketplace repo under a GitHub org in one rule instead of listing repos individually.
  • /review is now an alias of /code-review, which reviews the current diff or a specific PR (/code-review <level> <pr#>) — /code-review ultra triggers the deep cloud review this blog covered as /ultrareview back in April. Re-running /code-review with no level now reuses whatever level you last typed, rather than resetting to a default.
  • A /teleport hint in cloud sessions, surfacing claude --teleport <session id> as a way to pick a cloud session back up locally.
  • A warning when a workflow agent, forked skill, slash command, or resumed background agent requests a subagent model that’s restricted — the parent model now runs instead, with the substitution surfaced rather than silent.
  • CLAUDE_CODE_DISABLE_1M_CONTEXT now applies to every Claude model with a native 1M window, not a fixed list, holding sessions to 200K via auto-compaction with a startup warning if that compaction isn’t actually keeping the session in bounds.

Why the Cadence Is the Story
#

A single security fix in a point release is routine maintenance. Three releases in three days, each closing a distinct permission or sandbox gap, reads differently — not necessarily as evidence of degrading security posture, but as evidence of a tool whose attack surface is expanding faster than any one audit pass can cover. Claude Code now runs unattended background sessions that auto-commit and push, forked sessions that spin up their own worktrees, workflow scripts that orchestrate other agents, and org-level policies meant to be a hard ceiling on what any of that autonomy can do. Every one of those capabilities is a new place for a permission check to have an edge case, and this week’s three-release run found four more of them.

The honest read, consistent with how this blog has covered Claude Code’s prior three-bug postmortem back in May: shipping fixes at this cadence, with changelog entries specific enough to reconstruct exactly what was wrong, is what a healthy security response looks like for a tool operating at this level of autonomy — the alternative isn’t zero gaps, it’s gaps that don’t get found and fixed this fast. Teams running Claude Code against production code, especially with background or unattended sessions, should treat “check for updates” as a weekly habit right now, not an occasional one. Whatever’s driving this particular cluster of fixes, it isn’t done cheaply — and it isn’t done by accident.

Related