Recording, not claiming. Found by the domain:cli seat (session session_019bmVFqoQPq63zhKrxdYG1r) while collecting a dev report on #10112. Filed unassigned and unlabelled for triage routing.
Measured
On the agent container, git push origin --delete <branch> fails with:
send-pack: unexpected disconnect while reading sideband packet
Retried 3× with exponential backoff; failed every time. Ordinary pushes from the same container, in the same session, succeed — so this is not general loss of connectivity to origin, it is specifically the delete refspec.
Observed on branch claude/issue-10112-plugin-dev-source-alias, which a measurement-only dispatch created and then had nothing to put on: it still sits on origin at 6076abff8 (= origin/main at the time) with zero commits of its own.
Why this is a repo-protocol problem, not just a container annoyance
The transport failure itself is infrastructure. Its consequence lands on a check this repo documents and depends on: AGENTS.md prescribes
git ls-remote --heads origin | grep issue-<n>
as the in-flight pre-check an agent runs before claiming, to see whether someone else is already working a card.
An abandoned zero-commit probe branch answers that check as in flight. So:
- a card whose dispatch correctly ended in
premise_still_valid: false and no PR leaves behind a branch that says the opposite; - the next agent to consider that card sees a positive in-flight signal, and the documented response to a positive is to back off;
- nothing expires the signal, because the only thing that would clear it is the delete that cannot run.
The failure direction is the bad one: it does not cause two agents to collide, it causes a live card to look taken and be skipped indefinitely. That is silent — there is no red anything — and it gets worse monotonically, one abandoned probe at a time. Measurement-only dispatches are exactly the kind that produce these branches, and this lane has deliberately been running more of them.
Not claimed
⛔ Not diagnosed. Whether the delete refspec is refused by the agent proxy, by a server-side hook, or by branch protection is unexamined. I observed the failure and its shape, not its cause.
⛔ Not surveyed. How many such orphan branches already exist on origin is unmeasured — git ls-remote --heads origin | grep '^.*claude/issue-' cross-referenced against open PRs and card states would answer it, and would also size the problem. Nobody has run it.
⛔ Not established as universal. One container, one session, one branch name, three attempts. Whether every agent container behaves this way, or whether ordinary pushes and deletes differ for some other reason, is unknown.
Possible directions (triage, not a recommendation)
- Find out why delete refspecs specifically fail, and fix the transport — this is the only direction that restores the documented cleanup step.
- If deletes cannot be made to work, change the in-flight pre-check so a zero-commit branch with no PR does not read as in flight (a branch at or behind
origin/main with no open PR carries no work). - Or sweep periodically: a scheduled job that deletes
claude/issue-* branches with no commits ahead of main and no open PR, from somewhere that can delete.
The middle option is the one that survives the transport never being fixed, and it is a change to a check this repo owns rather than to infrastructure it does not.
Recording, not claiming. Found by the
domain:cliseat (sessionsession_019bmVFqoQPq63zhKrxdYG1r) while collecting a dev report on #10112. Filed unassigned and unlabelled for triage routing.Measured
On the agent container,
git push origin --delete <branch>fails with:Retried 3× with exponential backoff; failed every time. Ordinary pushes from the same container, in the same session, succeed — so this is not general loss of connectivity to origin, it is specifically the delete refspec.
Observed on branch
claude/issue-10112-plugin-dev-source-alias, which a measurement-only dispatch created and then had nothing to put on: it still sits on origin at6076abff8(=origin/mainat the time) with zero commits of its own.Why this is a repo-protocol problem, not just a container annoyance
The transport failure itself is infrastructure. Its consequence lands on a check this repo documents and depends on:
AGENTS.mdprescribesas the in-flight pre-check an agent runs before claiming, to see whether someone else is already working a card.
An abandoned zero-commit probe branch answers that check as in flight. So:
premise_still_valid: falseand no PR leaves behind a branch that says the opposite;The failure direction is the bad one: it does not cause two agents to collide, it causes a live card to look taken and be skipped indefinitely. That is silent — there is no red anything — and it gets worse monotonically, one abandoned probe at a time. Measurement-only dispatches are exactly the kind that produce these branches, and this lane has deliberately been running more of them.
Not claimed
⛔ Not diagnosed. Whether the delete refspec is refused by the agent proxy, by a server-side hook, or by branch protection is unexamined. I observed the failure and its shape, not its cause.
⛔ Not surveyed. How many such orphan branches already exist on origin is unmeasured —
git ls-remote --heads origin | grep '^.*claude/issue-'cross-referenced against open PRs and card states would answer it, and would also size the problem. Nobody has run it.⛔ Not established as universal. One container, one session, one branch name, three attempts. Whether every agent container behaves this way, or whether ordinary pushes and deletes differ for some other reason, is unknown.
Possible directions (triage, not a recommendation)
origin/mainwith no open PR carries no work).claude/issue-*branches with no commits ahead ofmainand no open PR, from somewhere that can delete.The middle option is the one that survives the transport never being fixed, and it is a change to a check this repo owns rather than to infrastructure it does not.