Feature Request: Branch Cleanup Passes Should Propagate to `git push origin --delete`

Observed on: the underlying events span Claude Code CLI 2.1.149 → 2.1.160 (2026-05-27 through 06-03, per per-session version metadata in my own logs). Filing against current CLI 2.1.217.

Summary

When a session (or an end-of-session hygiene routine) deletes a local branch that's already merged, it deletes the local ref only. If the branch also exists on origin, the remote copy is left behind indefinitely unless something else removes it. On repos where GitHub's delete_branch_on_merge is off — the default on every repo checked in this account (~55) except one — local hygiene never actually resolves the visible mess on GitHub; it just moves it out of sight locally. Filed as a feature request, not a bug: delete_branch_on_merge is a repo-owner-controlled setting Claude Code doesn't control and shouldn't override unasked, but its own cleanup habits could compensate for it being off by default, the way gh pr merge --delete-branch does at merge time.

Evidence

This isn't a guess at a pattern — it's reconstructed directly from the CLI's own JSONL session transcripts (I keep a local archive of every session I've run, ingested into a queryable database, so I can pull the actual tool-call sequence rather than rely on memory). On "Repo A" (the same repo as the companion report, #80132), that record shows at least three separate local-cleanup passes over about a week, each with its git/gh commands and their real output visible in the transcript:

• 2026-05-27 (CLI 2.1.149): git worktree prune run twice mid-session — only clears metadata for already-vanished directories, no real effect on live-but-done worktrees.
• 2026-05-28 (CLI 2.1.149): a manual "which worktrees are dangling" session found and removed 2 stale worktrees/branches.
• 2026-06-03 (CLI 2.1.160): a large pass deleted 33 merged branches locally + removed 5 worktrees, then 11 more (remote-tracked) branches locally + 2 more worktrees — all via local git branch -D/git worktree remove, no accompanying git push origin --delete for any of those ~44 branches. Only the final 3 branches of that same session were deleted with an explicit local-then-remote sequence, framed in the session's own description as a distinct, deliberate step ("Delete the 3 merged session branches (local + remote)") — implying the preceding ~44 were not treated the same way.

Net effect: despite three real cleanup passes across a week, the repo's GitHub branch list still showed 52 branches (25+ confirmed stale/merged) a month and a half later, because the local deletions never had a remote counterpart.

What's Being Asked

When a cleanup step deletes a local branch that has a matching remote-tracking ref (origin/<branch>), default to (or explicitly offer, with confirmation) also running git push origin --delete <branch> — so a "clean up merged branches" pass is complete end-to-end instead of only ever touching the local half.

Related (checked to avoid duplicate-closure)

Searched for existing coverage of delete_branch_on_merge, push origin --delete, and stale-branch propagation; found nothing overlapping. Distinct from the worktree-lifecycle cluster (#26725, #75911, #77609, #77661, #78978, #74708) — those are all about worktree directories/leases/hooks; this is specifically about local git branch cleanup not reaching the matching remote ref.