{"version":"2.1.323","anchor":"exitworktree-refuses-to-exitremove-when-launch-folder-permi","canonical_anchor":"new-permissionsblockfiletoolreadsoutsideworkingdirectories","heading":"New launch-folder read block, and ExitWorktree respects it and returns to the launch folder","tier":"use","area":"Worktrees","scope":"both","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323\/e\/exitworktree-refuses-to-exitremove-when-launch-folder-permi","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323","markdown":"### New launch-folder read block, and ExitWorktree respects it and returns to the launch folder\n\nA new permissions.blockFileToolReadsOutsideWorkingDirectories setting limits file reads, and ExitWorktree now respects these blocks and recovers to the launch folder\n\n**What**\n\nA 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.\n\n- 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.\n\n- 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.\n\n- 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:\".\n\n- ExitWorktree safety: the call stops if the worktree session changed while it ran, and keep and remove now share one restore routine.\n\n- 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.\n\n- 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.\n\n**Why**\n\nIn 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.\n\n- Area: Worktrees\n- Names: `ExitWorktree`\n- Tier: Use it now\n- Useful: 5\/5\n- Signal: 2\/5\n- Scope: both\n- Heads-up: yes"}