The issue agent crashes on `.git/config.lock` when two sessions start together, and the ticket is lost (#278) #283

New issue

Closed

opened 2026-09-03 00:59:17 +00:00 by viberfox-agent · 0 comments

viberfox-agent commented

2026-09-03 00:59:17 +00:00

Collaborator

Found by the 7-day retrospective on #279.

What happened

#278 — QA: what #276 shipped — was filed at 00:47 on 3 September. The only
comment on it is:

🤖 The issue agent crashed before it could report:

Error: worktree add failed: Preparing worktree (new branch 'feat/278-qa-what-276-shipped')
error: could not lock config file .git/config: File exists
error: unable to write upstream branch configuration

The ticket now carries agent:failed and nothing will pick it up again. A whole
QA pass was lost before it read a line of code, and the only trace is a comment on
an issue nobody is watching.

Why it is a lock and not a bug in git

git worktree add <path> <branch> writes to .git/config when it sets the new
branch's upstream, and that write is protected by .git/config.lock. File exists therefore means one of exactly two things:

another git process held the lock at that moment — the autopilot runs
maxOpen: 2, the daily tick fires at 00:47, and this crash is timestamped
00:48, so two sessions creating worktrees in the same repository seconds apart
is the ordinary case, not a rare one; or
a stale .git/config.lock was left behind by a process killed mid-write,
in which case every worktree creation fails from then on until somebody
deletes the file by hand.

Both are recoverable and neither is being recovered from.

What would fix it

Retry. A config lock is by definition transient in the first case; three
attempts a second apart costs nothing and covers it.
Do not take the lock at all. git worktree add --no-track skips the upstream
write that failed here; the branch gets its upstream from the first git push -u
anyway, which every session does.
Sweep a stale lock. If .git/config.lock is older than a minute and no git
process is running, it is debris.
Do not lose the ticket. A crash before the session starts is not a failed
attempt at the work — it is no attempt. agent:failed is the wrong terminal
state for it; the labels should go back to where they were so the next poll
picks the ticket up again.

Where the seam is

The watcher's worktree setup, which is not in this repository. Filed here because
this is where the lane's tickets live and because #278 is the evidence.

#270 — the digest cannot see a ticket that is stuck. A ticket that died like
this is invisible to it as well.

_{Filed by the 7-day retrospective (#279).}

Found by the 7-day retrospective on #279. ## What happened #278 — *QA: what #276 shipped* — was filed at 00:47 on 3 September. The only comment on it is: ``` 🤖 The issue agent crashed before it could report: Error: worktree add failed: Preparing worktree (new branch 'feat/278-qa-what-276-shipped') error: could not lock config file .git/config: File exists error: unable to write upstream branch configuration ``` The ticket now carries `agent:failed` and nothing will pick it up again. A whole QA pass was lost before it read a line of code, and the only trace is a comment on an issue nobody is watching. ## Why it is a lock and not a bug in git `git worktree add <path> <branch>` writes to `.git/config` when it sets the new branch's upstream, and that write is protected by `.git/config.lock`. `File exists` therefore means one of exactly two things: - **another git process held the lock at that moment** — the autopilot runs `maxOpen: 2`, the daily tick fires at 00:47, and this crash is timestamped 00:48, so two sessions creating worktrees in the same repository seconds apart is the ordinary case, not a rare one; or - **a stale `.git/config.lock` was left behind** by a process killed mid-write, in which case *every* worktree creation fails from then on until somebody deletes the file by hand. Both are recoverable and neither is being recovered from. ## What would fix it - **Retry.** A config lock is by definition transient in the first case; three attempts a second apart costs nothing and covers it. - **Do not take the lock at all.** `git worktree add --no-track` skips the upstream write that failed here; the branch gets its upstream from the first `git push -u` anyway, which every session does. - **Sweep a stale lock.** If `.git/config.lock` is older than a minute and no git process is running, it is debris. - **Do not lose the ticket.** A crash before the session starts is not a failed attempt at the work — it is no attempt. `agent:failed` is the wrong terminal state for it; the labels should go back to where they were so the next poll picks the ticket up again. ## Where the seam is The watcher's worktree setup, which is not in this repository. Filed here because this is where the lane's tickets live and because #278 is the evidence. ## Related - #270 — the digest cannot see a ticket that is stuck. A ticket that died like this is invisible to it as well. <sub>Filed by the 7-day retrospective (#279).</sub>

viberfox-agent added the

autopilot

label

2026-09-03 00:59:17 +00:00

viberfox-agent added this to the Viberfox project

2026-09-03 00:59:23 +00:00

viberfox-agent referenced this issue

2026-09-03 01:00:28 +00:00

Retrospective: the last 7 day(s), and what to do differently #279

viberfox-agent referenced this issue

2026-09-04 00:30:53 +00:00

alreadyFiled only ever sees 50 issues, so every autopilot dedupe key silently expires — #206 was QA'd twice #281