[Bug] Claude Code creates feature branches that track protected branches, bypassing review gates

Bug Description
Claude Code created a worktree/branch that tracked origin/main, leading to an unreviewed direct push to main (and an auto-deploy) Severity High. A feature change reached the default branch with no pull request and no review, which then triggered the repo's Continuous Delivery pipeline and published production build artifacts. The review gate was bypassed entirely. Environment - Claude Code version: 2.1.215 - Model: Claude Fable 5 - OS: macOS (darwin) - Git: 2.50.1 (Apple Git-155) - Push performed via: IDE git integration ("Push"/"Sync" button) What happened 1. I asked Claude Code to create an isolated worktree/branch for a change, per a team rule that branches start from the latest origin/main. 2. Claude ran, in effect: git worktree add <path> -b <branch-name> origin/main 3. Because the start-point was a remote-tracking ref (origin/main), git set the new branch to track it: branch.<branch-name>.remote = origin branch.<branch-name>.merge = refs/heads/main 3. Claude did not pass --no-track and did not flag that the branch would track main. 4. I committed on the branch and pushed from my IDE. The IDE pushes the current branch to its configured upstream ref — which was refs/heads/main. main fast-forwarded to my commit. No prompt, no PR, no warning. 5. The push to main triggered the "Continuous Delivery" workflow, which rebuilt and published the fleet's machine images (multiple cloud targets, standard + debug variants) to the production artifact path. Expected behavior - Branches/worktrees Claude creates for its own workflow should not silently track main. Basing a branch on origin/main for content must not also set main as the push target. The correct form is --no-track (or branching from a local ref). - Claude should recognize that a feature branch tracking a protected branch is almost never intended, and either refcitly. - There should be a guardrail against actions that can update main/master. Actual behavior - Claude used the tracking form with no --no-track, creating a feature branch whose upstream was main. - Nothing in the product warned that a subsequent push could land on main. Impact - Unreviewed commit on the default branch. - CD triggered automatically → production images rebuilt and published. - Standard PR review/approval process bypassed with no friction or audit prompt. Repro git worktree add /tmp/wt -b my-feature origin/main git -C /tmp/wt config --get branch.my-feature.merge # -> refs/heads/main (branch now tracks main) # commit on my-feature, then push from an IDE / any client that pushes to the tracked upstream # -> the commit lands on refs/heads/main Suggested fixes 1. When Claude creates branches/worktrees, default to --no-track (or branch from a local ref), so a branch never inherits main as its upstream from the start-point. 2. Add a guardrail: warn or block when creating a branch/worktree that would track a protected branch (main/master), push to one. 3. Consider surfacing the resulting upstream to the user at creation time ("this branch will track origin/main") so the footgun is visible. Broader, root-cause defect: the permission model is broken This incident is a symptom. The underlying problem is the permission model. - Aut…
Note: Content was truncated.