Follow Discord
Sweep 12 Nov 2026 · 23:00Z Build v2.1.323 540 read Stable v2.1.311 Latest v2.1.323 Next v2.1.323 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.323 ·

New launch-folder read block, and ExitWorktree respects it and returns to the launch folder

A new permissions.blockFileToolReadsOutsideWorkingDirectories setting limits file reads, and ExitWorktree now respects these blocks and recovers to the launch folder

Group of 5 Use it now Notable No documentation found New Features
JSON All of v2.1.323
Use it nowTier: how much it should matter to you
5Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
PermissionsArea: what it touches
New FeaturesKind: in v2.1.323,
What probably matters to youSection of the release

Unclear How this setting relates to the older read restriction already in Claude Code is not stated.

What

A new setting, permissions.blockFileToolReadsOutsideWorkingDirectories, keeps the file tools from reading outside the folders Claude Code was launched with. Before, only blockReadsOutsideWorkingDirectories existed. ExitWorktree, the tool Claude uses to leave a worktree (a separate working copy of your project), changed alongside it.

  • New setting: if CLAUDE_CONFIG_DIR, HOME, CLAUDE_CODE_REMOTE_MEMORY_DIR or similar environment variables change while Claude Code is running without --settings declaring them, the file tools are refused Claude Code's own files and every added folder, and the error names the variables. Read denials now say this setting blocks the read, and leave out the /add-dir hint.
  • Status fields: session info gains four internal fields, outsideFileToolReadsBlocked, outsideFileToolWritesBlocked, outsideBlocksCountLaunchFoldersOnly and launchEnvLeftOwnFilesInPlace. They report whether permissions.blockFileToolReadsOutsideWorkingDirectories, permissions.blockReadsOutsideWorkingDirectories or permissions.blockWritesOutsideWorkingDirectories is in force. The sandbox's read rules now also take the new setting into account.
  • ExitWorktree refusals: it refuses to leave when permissions.blockFileToolReadsOutsideWorkingDirectories is set and the folder it would return to is outside the launch folders. It refuses remove when permissions.blockWritesOutsideWorkingDirectories is set and the worktree is outside the launch folders or was made by a WorktreeCreate hook. The message begins "The session stays in the worktree:".
  • ExitWorktree safety: the call stops if the worktree session changed while it ran, and keep and remove now share one restore routine.
  • ExitWorktree recovery: when the original folder is gone, the session returns to the launch folder if possible, and the result gains returnedToLaunchDir and tookToLaunch. The permission anchor (the folder permissions are measured from) now stays put with the message "the anchor check refused". Before, it stayed put when it strictly contained the live launch anchor.
  • ExitWorktree hint: a new when-to-use note says to use it only when you ask to leave a worktree that an earlier tool put the session in, and "do not call it on your own initiative". The tool's stock description, captured under this release, is unchanged at 1,923 characters.

Why

In a locked-down setup, Claude can no longer use ExitWorktree to land outside the folders it was launched with, and a tampered environment makes file reads fail closed. If the original folder was deleted, the session goes back to where it started, and Claude should stop leaving worktrees unless you ask.

Read from
How sure we are
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubtHow this setting relates to the older read restriction already in Claude Code is not stated.
Anthropic's release notes agreeFixed a case where the Write and Edit tools could write to a path covered by a Read deny rule

See this entry in the whole of v2.1.323 →

Feedback