Two new Claude Code releases landed since my v2.1.304 write-up. v2.1.306 is tiny. v2.1.305 is a long list, and a handful of entries matter if you run agents unattended or manage Claude Code for a team. Everything here comes from the official changelog. I did not install either release, so treat this as a reading of the notes, not a field test.
The sandbox setting you should leave off#
The headline security item in v2.1.305 is a new setting, sandbox.allowNestedUserNamespaces. The changelog describes it as letting sandboxed Linux commands create user namespaces, and it carries a blunt warning: doing so “can bypass the sandbox’s file protections.”
Why would anyone want that? Some tooling needs unprivileged user namespaces to work at all. Rootless container builds, some browser test runners and certain package build steps create their own namespaces. Inside a locked-down sandbox, those commands fail. Rather than telling people to disable the sandbox entirely, Anthropic added a narrow, explicit opt-in.
That is the right design, and also a trap. The sandbox is what makes autonomous runs defensible: a denyRead rule on ~/.ssh only means something if a child process cannot rebuild its own view of the filesystem. Once a command can create a user namespace, the file protections are no longer a reliable boundary.
My advice:
- Leave it off by default. The default is the safe state.
- If one specific job needs it, scope it to that job’s settings, not your user-level config.
- Treat a job with this flag on as unsandboxed for file-protection purposes, and run it in a disposable container or VM instead.
This is the same lesson spec-driven teams keep relearning. Your spec says what the agent may touch, but only the enforcement layer makes it true. Every flag that loosens enforcement belongs in the same review as a change to the spec.
Unattended retry mode notices when your limit is lifted#
If you run Claude Code headless against a subscription plan, you know the failure mode: you hit a usage limit, the retry watchdog waits until the reset time, and the job sits idle even if the limit was lifted earlier. v2.1.305 adds CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS, which makes unattended retry mode notice a limit that was lifted before its scheduled reset.
The changelog does not state a default interval or an allowed range, so set it deliberately and check the behavior in your own pipeline. A value of a few minutes is the obvious starting point, but polling too aggressively against a limit that is genuinely still active gains you nothing. This pairs with the watchdog wait cap added in v2.1.301, and together they make overnight batch runs less likely to sit idle for hours after the limit has cleared.
Managed MCP: allowedMcpServers no longer filters some stdio servers#
This one is easy to miss and could surprise admins. v2.1.305 “changed allowedMcpServers to stop filtering managed-mcp.json stdio servers that use ${VAR} only in env; use deniedMcpServers to block them.”
Read that carefully. If you manage a managed-mcp.json with stdio servers and your allowlist previously kept some of them out because their env block referenced variables, that filtering no longer happens. A server you believed was excluded may now load. If your policy is “block this server,” the changelog tells you to say so explicitly in deniedMcpServers.
Action items for admins:
- Open your
managed-mcp.jsonand list stdio servers whoseenvuses${VAR}. - Compare them against your
allowedMcpServersentries. - For any you want blocked, add them to
deniedMcpServersbefore rolling out v2.1.305.
Two neighboring items point the same way. A cloud- or SDK-provided MCP server is no longer replaced by a same-named server from your settings, which removes a quiet shadowing path. MCP consent dialogs are also less likely to accept a stray Enter keypress, which is a small but real defense against accidental approvals. Together with the exact-server matching tightened in v2.1.299, MCP policy is getting steadily stricter. It is still worth re-auditing after each release.
Provider and gateway fixes#
Several fixes matter mostly to enterprises routing through cloud providers:
- Tool search rejection. On Vertex, Bedrock and other providers, every request could fail when tool search was rejected. Claude Code now retries without it. Combined with v2.1.304’s change to turn tool search on by default behind a custom
ANTHROPIC_BASE_URL, with a retry on a 400 or 422 from the gateway, gateway users get a more forgiving fallback path. /effortand/autocompactcasing. They did not apply when the model name differed by letter case or carried a[1m]tag. If your settings pinnedOpus-5.5[1m]and your effort level never changed, this was why.- Worktrees in bare repositories started from local HEAD rather than the default branch, and unchanged subagent worktrees were not cleaned up. If you run parallel agents in worktrees, this affects both correctness (the wrong base) and disk hygiene.
- Wrong model named after fallback. Claude could name the wrong model for a subagent’s work after a fallback switch. That is a transcript and audit issue, not a behavior one, but anyone reconciling cost by model should know it existed.
- Compaction notices. Cloud sessions and teammates are now told when compaction dropped the oldest messages. An agent that does not know its context was trimmed will confidently act on a stale picture, so this is worth having.
- Workflow resume no longer re-runs completed
pipeline()andparallel()agents. For long multi-agent workflows, re-running finished work is pure waste.
Small things worth knowing#
- Full-disk Bash errors now say the disk is full and that nothing ran, instead of a raw
ENOSPCpath. /usagewarnings are one-line fixes naming their source, and pressingfapplies them, including in VS Code and/doctor.- Startup warnings no longer print above the logo. They go to the debug log, and no-op permission rules show as warning rows. That second part is useful: a permission rule that does nothing is the kind of thing you want to see, because it usually means your guardrail isn’t doing what you think it is.
- The
/artifactsdelete confirmation changed again: 1 or Enter keeps, 2 deletes, Esc cancels, andy/nno longer work. If you have muscle memory or scripts expectingy, they will not delete anything. - Self-hosted runner users get three fixes, including a regression since 2.1.296 where repository access failed when a git credential helper read settings through
GIT_CONFIG.
v2.1.306#
The newest release has two fixes: a false “Not logged in” error from claude -p in cloud sessions started without the session’s environment variables, and API errors mislabeled as “prompt is too long,” triggering needless compaction, in sessions with many MCP tools. The second is the more interesting. If you run a large MCP fleet and saw unexplained compaction, this may be the explanation. Compaction costs tokens and loses context, so it is a bug worth fixing.
Take#
None of this is a headline feature, and that is the point. The pattern across v2.1.299 to v2.1.306 is an agent runtime being hardened for unattended, enterprise use: stricter MCP matching, fail-closed hooks, better limit handling and explicit escape hatches with warnings attached. That is the trajectory you want from the tool you hand your repo to.
The practical to-do list is short. Keep sandbox.allowNestedUserNamespaces off. Re-audit managed MCP servers against deniedMcpServers before you update. Set the retry recheck variable if you run overnight jobs. And remember what I couldn’t verify: the changelog gives no default for the recheck interval, and I did not test any of these behaviors myself.
