Claude Code 2.1.309: Sandbox and Permissions Get Locked Down

Claude Code 2.1.309, released on October 22, 2026, does not read like the usual changelog digest. It ships no flashy feature. Instead it closes about a dozen sandbox and permission holes in one go, and changes three defaults that a lot of people assume still work the old way. If you run Claude Code in bypass permissions mode, if sed -i is part of your toolkit, or if you call claude ultrareview from a script, this release is about you. The 2.1.308 right before it was a single line: "bug fixes and reliability improvements," with no public detail.

About a dozen sandbox and permission holes closed at once

The Bash sandbox isolates shell commands at the operating-system level: it limits which files and network hosts a command can reach, which is what lets Claude Code run many commands without asking you to approve each one. 2.1.309 fixes several ways around that isolation. On macOS and Linux, shell startup files such as .bashrc or .zshrc ran outside the sandbox before every command, so code placed there could run with no restriction at all. On macOS, a denyWrite rule aimed at a folder reached through a symlink did not apply to the folder's real location, which left a door open behind the closed one. A sandboxed command, or an auto-accepted edit, could modify the MCP config file passed with --mcp-config. In print and SDK sessions, a disabled MCP server could also reconnect through a later permission prompt. And when the sandbox is enabled but can't run, commands your settings exclude from it (excludedCommands) now ask before writing to the paths on its write list, and the unsandboxed fallback is refused there.

On the permissions side, the most telling fix touches the check that decides whether a Bash command needs your go-ahead before it runs: it trusted a variable set by a command whose redirect could fail to open, which could let a command through without the right check. Compound commands that change directory before running git slipped past the prompt a plain cd normally triggers. An Edit(path) deny rule that blocks writing to a file did not stop a Bash redirect aimed at that same file in some commands that also carried a subshell. Worktree-isolated sessions let through some locale-prefixed commands and some zsh arithmetic commands that the isolation guard is supposed to refuse. The changelog doesn't say how these holes were found or whether any were exploited. It does list two more fixes of the same kind: on Windows, some PowerShell Set-Location or cd commands targeting the current directory with extra arguments were auto-approved, and on Linux, the sandbox's write denies lifted when a background command outlived the session.

sed -i becomes a real Bash command, and falls out of /rewind's net

Until now, Claude Code treated sed -i as a simulated file edit with a preview before it ran, the same way it treats a call to the Edit tool. 2.1.309 changes that: sed -i now gets the standard Bash prompt and runs exactly as written, like any other shell command. The practical consequence is worth knowing before you run into it: the checkpointing page documents that /rewind does not restore changes a Bash command makes to a file Claude has not already edited with its own file tools. sed -i now falls into that case, where before 2.1.309 it was tracked like a normal edit and so could be rewound. If you relied on /rewind to undo a bad sed -i, that safety net is gone in this version: treat sed -i the way you'd treat rm or any other destructive command-line tool, by reading the command before approving it, and lean on git rather than /rewind to go back.

claude ultrareview now needs you to trust the folder

Ultrareview runs a deep code review in a cloud sandbox, with a fleet of agents that independently verify each finding before showing it to you. In an interactive session, Claude Code already asks you to trust a folder before it applies permissions.allow rules or extra directories that come from the repository, through the workspace trust dialog. The claude ultrareview subcommand, built to run from a script or CI with no interactive session, did not require that trust until now. 2.1.309 makes it mandatory: on a terminal, it asks (Trust <folder>? [y/N]); everywhere else, it now refuses outright with Error: Workspace not trusted instead of continuing on a folder that was never approved. For a script or CI job, you get two ways around it: add --trust-workspace to the command (it takes no value, so put your PR number or base branch before it), or set CLAUDE_CODE_DISABLE_ULTRAREVIEW_TRUST_CHECK=1 in the environment that launches it. If your pipelines already call claude ultrareview without either one, expect them to start failing on this version.

Bypass permissions mode now refuses dangerous rm and rmdir instead of waiting

In bypass permissions mode, Claude Code turns off most permission prompts but keeps a safety net for critical deletions, like rm -rf /Applications or rm -rf ~: the mode shows a prompt with a two-minute countdown in the terminal, and denies the command if the countdown runs out unanswered, so unattended sessions keep going. In the Desktop app and the VS Code extension, where there is no terminal countdown, 2.1.309 replaces the prompt with an immediate denial, along with a hint on how to rewrite the command. In practice, an unattended session in either interface no longer stops on a deletion prompt: the command is denied and the session keeps going.

The rest, briefly

2.1.309 also adds a log warning in the VS Code extension that says what to do when dictation or one of the extension's own requests fails certificate verification, useful behind a proxy that inspects TLS traffic. When Claude Code creates or reuses a worktree, git no longer fetches objects on demand, in an ordinary clone or in a partial clone with a Bash sandbox configured: such a partial clone now fetches them upfront. Disk-full handling is clearer, whether a Bash command gets cut off mid-run or Claude Code starts up on a full temp volume. In the VS Code extension, the wait after each edit before checking for new problems drops to 0.75 seconds in most cases, down from 1 to 1.5 seconds. The rest of the 62 fixes, which is most of them, touches peripheral surfaces: Claude Tag in Slack, cloud sessions, self-hosted runners, and a string of VS Code-specific details. None of it changes a daily habit unless you happen to be the one it affects.

What to take away

2.1.309 is not a feature release. It is a security cleanup, with four changes that actually touch how you work. The sandbox and permission system close about a dozen holes in one pass, sed -i falls out of /rewind's net by becoming a real Bash command, claude ultrareview refuses to run from a script on a folder that was never trusted, and bypass permissions mode now denies a dangerous rm or rmdir outright in the Desktop app and VS Code instead of asking for confirmation. If you automate reviews with claude ultrareview, check your scripts before they hit Error: Workspace not trusted. If sed -i is part of your quick-edit habits, know that /rewind no longer has your back.