Hit twice while bumping the console pin (#14027 / PR #14165). Out of scope there under pin-bump discipline.
What happens
scripts/build-console.sh resolution mode 2 (a sibling ../objectui checkout) does not mutate the dev tree — it creates a git worktree at the pinned SHA, under the FRAMEWORK worktree:
/home/user/objectstack-issue-14027/.cache/objectui-d8ec8d6d4f01
That registration lives in the shared objectui/.git, which no framework-side cleanup touches. AGENTS.md's own task-completion sequence is rm -rf node_modules then git worktree remove on the framework worktree — both of which delete the .cache directory without ever telling objectui. The registration survives as prunable.
The next build-console.sh run that resolves to the same pin then dies before doing any work:
Preparing worktree (detached HEAD d8ec8d6d4)
fatal: '/home/user/objectstack-issue-14027/.cache/objectui-d8ec8d6d4f01' is a missing but
already registered worktree; use 'add -f' to override, or 'prune' or 'remove' to clear
VERDICT command-exit 128 - held the lock 0s
Measured twice in one dispatch: the first run created it, the documented cleanup stranded it, and a later run in a freshly recreated worktree at the same path hit the refusal instantly. Remedy is one command, git -C ../objectui worktree prune, but nothing names it — the error names add -f, prune and remove without saying which is right here, and add -f is the one that quietly accumulates registrations.
Why it is worth closing rather than remembering
The failure is exit 128 with an eight-second lock hold, so it looks like a lock or a git problem rather than a leftover of your own previous run. It is also cross-repo: nothing in objectstack's tree shows the cause, and an agent that has cleaned up correctly per AGENTS.md is exactly the one who meets it.
Options
build-console.sh runs git -C SOURCE_ROOT worktree prune before worktree add (cheap; only removes registrations whose directory is already gone).- It removes its own worktree on exit (a trap), rather than leaving it for the next run to trip over.
- The framework-side cleanup step in AGENTS.md gains the prune. Weakest: it relies on every agent doing it.
Option 1 looks right — the prune is safe by construction and repairs the state regardless of which run stranded it.
Generated by Claude Code
Hit twice while bumping the console pin (#14027 / PR #14165). Out of scope there under pin-bump discipline.
What happens
scripts/build-console.shresolution mode 2 (a sibling../objectuicheckout) does not mutate the dev tree — it creates a git worktree at the pinned SHA, under the FRAMEWORK worktree:That registration lives in the shared
objectui/.git, which no framework-side cleanup touches. AGENTS.md's own task-completion sequence isrm -rf node_modulesthengit worktree removeon the framework worktree — both of which delete the.cachedirectory without ever telling objectui. The registration survives asprunable.The next
build-console.shrun that resolves to the same pin then dies before doing any work:Measured twice in one dispatch: the first run created it, the documented cleanup stranded it, and a later run in a freshly recreated worktree at the same path hit the refusal instantly. Remedy is one command,
git -C ../objectui worktree prune, but nothing names it — the error namesadd -f,pruneandremovewithout saying which is right here, andadd -fis the one that quietly accumulates registrations.Why it is worth closing rather than remembering
The failure is exit 128 with an eight-second lock hold, so it looks like a lock or a git problem rather than a leftover of your own previous run. It is also cross-repo: nothing in objectstack's tree shows the cause, and an agent that has cleaned up correctly per AGENTS.md is exactly the one who meets it.
Options
build-console.shrunsgit -C SOURCE_ROOT worktree prunebeforeworktree add(cheap; only removes registrations whose directory is already gone).Option 1 looks right — the prune is safe by construction and repairs the state regardless of which run stranded it.
Generated by Claude Code