allod change cleanup never reclaims a worktree whose commits were relayed #134

New issue

Closed

opened 2026-07-30 07:50:08 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-07-30 07:50:08 +01:00

Contributor

A worktree whose commits reached the default branch through allod patch receive is never reclaimable: allod change cleanup refuses it permanently, and allod change list reports it as unpushed forever.

Reproduction, on a public org repository an agent cannot push to:

allod change begin -d <desc> allod/<repo>, commit, leave unpushed — the documented handoff state for a public change.
A human relays it with allod patch receive <vm>:<worktree> ~/work/allod/<repo> --push. The patch applies with git am, so it lands on master under a new SHA.
allod change cleanup <worktree> then refuses, and keeps refusing:

allod: worktree '/home/vnprc/changes/work-allod-memory-...' has unpushed commits; push or handle them before cleanup

Exit code is 1, so the refusal itself is signalled correctly.

The refusal's documented exit does not exist here: the branch cannot simply be pushed, because the repository's default branch is protected server-side — which is why the relay was used in the first place.

Evidence that the commits are in fact upstream. git cherry marks every commit on the branch as patch-equivalent to one already on master:

$ git -C <worktree> cherry origin/master HEAD
- 7691ae4 Label bug reports with a bug tag

and the branch's diff against origin/master is empty:

$ git -C <worktree> diff origin/master..HEAD --stat
(no output)

Observed on two worktrees relayed and merged today, in allod/memory and allod/tools. Both had to be removed by hand with git worktree remove plus git branch -D.

Scale: this is not one stale worktree. Every public-repo change an agent prepares ends in this state by construction, because the relay is the only way those commits can land and it always rewrites the SHA. Nine of twelve worktrees on the machine were already fully merged by the git cherry test, of which six still showed unpushed.

One further observation, offered as context rather than diagnosis: allod/tools issue #127 reports the same guard failing in the opposite direction, deleting a branch when it cannot tell whether commits are unpushed. Anyone changing the guard should look at both directions together, since a change that makes it more permissive to satisfy this report could widen #127.

A worktree whose commits reached the default branch through `allod patch receive` is never reclaimable: `allod change cleanup` refuses it permanently, and `allod change list` reports it as `unpushed` forever. Reproduction, on a public org repository an agent cannot push to: 1. `allod change begin -d <desc> allod/<repo>`, commit, leave unpushed — the documented handoff state for a public change. 2. A human relays it with `allod patch receive <vm>:<worktree> ~/work/allod/<repo> --push`. The patch applies with `git am`, so it lands on `master` under a new SHA. 3. `allod change cleanup <worktree>` then refuses, and keeps refusing: ``` allod: worktree '/home/vnprc/changes/work-allod-memory-...' has unpushed commits; push or handle them before cleanup ``` Exit code is 1, so the refusal itself is signalled correctly. The refusal's documented exit does not exist here: the branch cannot simply be pushed, because the repository's default branch is protected server-side — which is why the relay was used in the first place. Evidence that the commits are in fact upstream. `git cherry` marks every commit on the branch as patch-equivalent to one already on `master`: ``` $ git -C <worktree> cherry origin/master HEAD - 7691ae4 Label bug reports with a bug tag ``` and the branch's diff against `origin/master` is empty: ``` $ git -C <worktree> diff origin/master..HEAD --stat (no output) ``` Observed on two worktrees relayed and merged today, in `allod/memory` and `allod/tools`. Both had to be removed by hand with `git worktree remove` plus `git branch -D`. Scale: this is not one stale worktree. Every public-repo change an agent prepares ends in this state by construction, because the relay is the only way those commits can land and it always rewrites the SHA. Nine of twelve worktrees on the machine were already fully merged by the `git cherry` test, of which six still showed `unpushed`. One further observation, offered as context rather than diagnosis: `allod/tools` issue #127 reports the same guard failing in the opposite direction, deleting a branch when it cannot tell whether commits are unpushed. Anyone changing the guard should look at both directions together, since a change that makes it more permissive to satisfy this report could widen #127.

vnprc-agent referenced this issue

2026-07-31 00:52:23 +01:00

allod change cleanup cannot reclaim a worktree whose commits landed via allod patch receive #132