{"version":"2.1.323","anchor":"git-sandbox-path-analysis-extended-to-git-bundle-create-an","canonical_anchor":"git-sandbox-path-analysis-extended-to-git-bundle-create-an","heading":"Sandbox guards git worktrees, glab settings and git output paths more tightly","tier":"notice","area":"Sandbox","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323\/e\/git-sandbox-path-analysis-extended-to-git-bundle-create-an","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323","markdown":"### Sandbox guards git worktrees, glab settings and git output paths more tightly\n\nThe sandbox write-blocks .git\/worktrees and glab settings, checks paths for git bundle create and git worktree add, and tells Claude how to cope\n\n**Unclear.** The feature check behind this was not identified, so whether the new checks are active is unknown.\n\n**What**\n\nThe sandbox is the restricted environment Claude Code can run shell commands in, limiting which files they may change. A worktree is an extra working copy of a git repository, and git keeps its records of them in `.git\/worktrees`. This release tightens what the sandbox protects and changes what Claude is told about it.\n\n- Git output paths: the git argument checker now understands `bundle create` and `worktree add` with their options, and treats their path arguments as output paths to check, as it already did for `clone` and `init` (`--separate-git-dir` is among the options). This is behind a feature check, and so is the handling of `--end-of-options`.\n\n- `.git\/worktrees`: the worktrees rule is now a plain write block on `.git\/worktrees` (its tracker is renamed from `unlistableWorktreesDenyApplied` to `worktreesDenyApplied`), with a new guard on a link placed at `.git\/worktrees` (`worktreesLinkGuardApplied`). Windows junctions, a kind of folder link, are followed.\n\n- glab: writes to glab's per-repository settings folder are blocked (`glabConfigDenyApplied`).\n\n- Re-linked write grants: write permissions whose link was changed later are checked again (`lateSymlinkWriteGrantVetApplied`).\n\n- Links to other computers: a warning says Claude Code will not look at, create or write-protect a link that points to another computer.\n\n- macOS: the sandbox profile builder gains `allowWithinDeny`, which carves exceptions inside write-blocked paths. The daemon's blocked folders are now set up at startup.\n\n- Switches: the glab, link-guard and re-linked-grant rules are driven by feature flags. Nothing has been read about `tengu_russet_hawthorn`, `tengu_vast_meteor`, `tengu_ancient_pond` or `tengu_stalwart_quince`.\n\n- Bash prompt: the sandbox section gains two notes. One says the repository's `.git\/worktrees` is read-only in the sandbox, apart from this session's own worktrees, so `git worktree add`\/`move`\/`remove` fail partway. The other says that on macOS a sandboxed command can only see and signal processes it started, so an empty `lsof -i :3000` does not mean the port is free. Each has a variant telling Claude to retry outside the sandbox and one telling it to ask you to run the command. The worktree note is skipped when the sandbox mode is \"relaxed\" and on Windows. Before, only the macOS open\/osascript Apple Events note existed.\n\n- Background sessions: the worktree guard text no longer suggests `git worktree add`. It tells Claude to enter a worktree it made earlier with the worktree tool, using its `path`.\n\n**Why**\n\nThese git commands can no longer be used to write outside the paths the sandbox allows, and worktree records and glab settings are protected from sandboxed writes. Claude is also told why worktree commands fail partway and why a macOS port check can look empty, so it can retry outside the sandbox or ask you instead of drawing the wrong conclusion.\n\n- Area: Sandbox\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: yes"}