pr-hijack-via-stale-worktree-branch-reflisted

Diagnose and recover from accidentally overwriting another session's open PR when `git push -u origin <branch>` in a long-lived worktree silently replaces the remote branch ref. Use when ANY of the following appears: (1) you ran `git checkout -b <branch> origin/main` and `git push -u` and git reported `* [new branch]` even though the branch already existed upstream, (2) `gh pr create` then errors with `a pull request for branch "<branch>" into branch "main" already exists` pointing to a PR you didn't author, (3) `gh pr view N --json commits` on that PR shows YOUR commit instead of the one the title/body describes, (4) you discover your worktree's session-start git status banner was stale (showed branch X but actual branch was Y). Pattern surfaces when a prior session in the SAME worktree opened a PR on a generically-named feature branch, then reset the worktree's local refs without cleaning the remote. Recovery requires `git push --force-with-lease` — a destructive op requiring explicit user authorization. Si
wan-huiyan/agent-traffic-control · ★ 2 · Code & Development · score 79

Install: claude install-skill wan-huiyan/agent-traffic-control

# PR-Hijack via Stale Worktree Branch Ref ## Problem In a long-lived git worktree (especially `.claude/worktrees/<name>/` patterns created by a parallel-session harness), a same-named local branch can be created via `git checkout -b X origin/main` even when branch `X` already exists upstream with an open PR. Pushing that local branch with `git push -u origin X` succeeds — git reports `* [new branch]` — and silently replaces the remote ref. The result: - The remote branch ref now points at YOUR commit - The open PR (call it #N) on that branch now lists YOUR commit - PR #N's title and body still describe the ORIGINAL author's work - The original author's commit is orphaned on the remote but still reachable in YOUR local reflog (because the worktree's reflog captured it earlier) - `gh pr create` fails with `a pull request for branch "X" into "main" already exists` and surfaces PR #N — which is now an artefact of two unrelated commits The hijack is silent on both sides: git's push output doesn't warn, gh doesn't either, and the PR's web view shows a perfectly plausible (but wrong) state. ## Context / Trigger Conditions Surfaces when ALL of: 1. You are working in a worktree (typically `.claude/worktrees/<name>/`) that has been used by a previous session 2. The session-start git status banner shows a branch name that does NOT match `git status -sb` once you actually run it (stale banner) 3. A prior session in the same worktree opened a PR on a generically-named