---
title: "Claude Code v2.1.305 and v2.1.306: A Sandbox Escape Hatch, a Smarter Retry Watchdog, and a Managed-MCP Behavior Change"
date: 2026-10-21
tags: ["claude-code","sandbox","mcp","changelog","security","autonomous-agents"]
categories: ["Guides"]
summary: "Claude Code v2.1.305 adds an opt-in sandbox.allowNestedUserNamespaces setting, a usage-limit recheck for unattended retry mode, and a change to how allowedMcpServers treats managed stdio servers. v2.1.306 is two fixes. Changelog-only analysis: I did not run either release."
---


![Claude Code v2.1.305 and v2.1.306: A Sandbox Escape Hatch, a Smarter Retry Watchdog, and a Managed-MCP Behavior Change](/images/claude-code-v2-1-305-306-nested-namespaces-retry-watchdog-managed-mcp.png)

Two new Claude Code releases landed since my [v2.1.304 write-up](/posts/claude-code-v2-1-304-auto-mode-setup-mod-tool-check-resume-warning/). 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](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md). 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:

1. Open your `managed-mcp.json` and list stdio servers whose `env` uses `${VAR}`.
2. Compare them against your `allowedMcpServers` entries.
3. For any you want blocked, add them to `deniedMcpServers` before 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.
- **`/effort` and `/autocompact` casing.** They did not apply when the model name differed by letter case or carried a `[1m]` tag. If your settings pinned `Opus-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()` and `parallel()` 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 `ENOSPC` path.
- `/usage` warnings are one-line fixes naming their source, and pressing `f` applies 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 `/artifacts` delete confirmation changed again: 1 or Enter keeps, 2 deletes, Esc cancels, and `y`/`n` no longer work. If you have muscle memory or scripts expecting `y`, 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.

## Sources

- [Claude Code CHANGELOG, v2.1.304 to v2.1.306](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)

