worktree: a lane that hosted shared-workspace subagents can never be reaped on demand

[obra]

What happened

After PR #1604 merged (squash), its worktree lane could not be reaped. The lane (mobile-repo-line) was clean, fully landed, its remote branch deleted, nothing running — but manage_worktree remove --force refused:

manage_worktree remove: live work under <lane>: 034Q0FmS… (subagent, retained — idle), 034Q0Fpx2… (subagent, retained — idle), 034Q0FtI… (subagent, retained — idle), 034Q0FwG… (subagent, retained — idle)

The four blockers were the simplify-code review delegates: read-only, shared-workspace subagents (no isolation="worktree"), completed, and stopped via job_stop. Their retained sessions list the lane as their working directory, and that is the whole blocker.

Repro

1. A root session creates a managed lane (manage_worktree create) and enters it.
2. It spawns shared-workspace delegates (the default) whose cwd is the lane; they complete their task and go retained-idle. job_stop them — the stop reports already_idle · stopped_by_parent, and the sessions stay retained (resumable terminal history).
3. Exit the lane; land its work (e.g. squash-merge a PR and delete the remote branch), so the lane is clean and merged.
4. manage_worktree remove <name> --delete-branch --force refuses on live work, with no dispose hint and no force cascade.

Root cause

The refusal is correct per the guard's design; the dead-end is in the cascade's coverage:

• liveWorkUnder (agent/session_tools_worktree.go, ~L885) labels stopped shared-workspace children (subagent, retained — idle) — deliberately honest, so a model removing a clean merged lane gets a signal it can act on.
• retainedIdleDelegateIDs (~L1010) resolves those blockers to disposable delegates through delegateController.ownedStableWorktreeSnapshots — a map that only worktree-isolated delegates appear in. A shared-workspace child has no stable worktree descriptor, so resolution fails closed (ok=false).
• Both the dispose hint (disposeHintForRetainedIdle, ~L1043, returns "" when resolution fails → generic refusal) and remove's force cascade (~L2255: forceCascadeDlgIDs is only recorded when retainedIdleDelegateIDs(live) succeeds) therefore never arm for shared-workspace children.

So the "legitimate way forward" the retained-idle label exists to provide (the comment at ~L970: labeling such a child "running" would "dead-end a model trying to remove a clean, merged lane") does not exist for this configuration. The label was fixed; the shared-workspace case still dead-ends.

What does not work (verified this session)

• job_stop does not de-retain: an idle delegate's stop is already_idle, and retained means resumable history, by design. No exposed tool deletes retained session state; doctor_evener is read-only.
• Admission-time reclamation (max_retained_terminal) is capacity-driven only. A minimal probe delegate admission did not trigger it; the four subtrees stayed retained.
• manage_worktree dispose only retires a delegate's own isolation lane; shared-workspace children have none.

The lane stays unreapable until capacity-driven reclamation happens to remove those quiescent retained subtrees, after which remove/prune succeeds. The lane is inert and harmless in the meantime — this is a hygiene dead-end, not a correctness bug.

Fix direction

The guard's fail-closed posture is right for other sessions' lanes and foreign children. The gap is the caller's own lane hosting the caller's own shared-workspace children. Suggested: let the force cascade resolve a blocker that is

• owned by the calling session,
• retained-idle (not running or driving),
• shared-workspace, and
• whose recorded working directory is under the lane being removed,

and dispose it through the same sanctioned cascade (the child holds no live work; its lane is the target itself, owned by the caller). Everything else — running shells, driving children, other sessions' lanes — keeps failing closed exactly as today.

Two side observations from the same session, no action implied:

• manage_worktree's repeated-identical-call fuse blocked the third identical remove attempt and forced an approach change — that worked as intended.
• git merge on this host needs an explicit --no-ff (merge.ff=only is set repo-wide); worth knowing when bringing PR branches up to date under strict branch protection.

[obra]

Two more occurrences, both today, from one session that ran follow-up lanes this way.

Two managed lanes each hosted a shared-workspace (non-isolated) subagent, both merged, both clean, neither removable:

• followup/native-preflight-relative, PR fix(native): canonicalize EVENER_NATIVE_DIR before cd (#1675) #1684 merged as 7fb903068 — manage_worktree remove (with delete_branch, force) answers live work under …: 034QEvjlCOiWyc8r8V1aqd (subagent, retained — idle), both before and after the delegate was stopped.
• followup/skillguard-synthetic-paste, PR test(web): drive the skillguard clipboard milestone without the OS clipboard (#1662) #1689 merged as cf9b2fe69 — same, live work under …: 034QSqQRoI2THNKAFff5ON (subagent, retained — idle).

What I tried, so the next person does not repeat it:

• job_stop on the delegate first: it reports already_idle · stopped_by_parent · was idle, and the block persists unchanged.
• manage_worktree dispose id=<dlg_…> is not available for this shape: it answers delegate dlg_… is not worktree-isolated, which is correct, since the delegate shared the parent's lane rather than owning one.
• prune was deliberately not used: with ~248 lanes in this repo it would sweep other sessions' lanes, not just mine.

By contrast, the delegate that was created with isolation="worktree" disposed cleanly with no argument (manage_worktree dispose id=dlg_… removed the worktree and deleted the branch), and a lane with no subagent at all removed cleanly too. So the block tracks "a shared-workspace subagent ran here", not "the lane is merged" or "a job is running".

Workaround I used: leave the lane in place and report it. At 248 lanes the cost is small, but both lanes are content-identical to main, so a force remove would have been safe if the gate had permitted it.