Problem
While working lifting-logbook issue #693 (add a scheduled docker build --no-cache CI check), a session was interrupted mid-task (process restart) while npm install and two local Docker builds were running in the background inside a fresh worktree (.claude/worktrees/issue-693-docker-nocache, branch chore/issue-693-nightly-docker-nocache-build). The worktree had the target file written but not yet committed at the moment of interruption.
On resuming, PR #719 was already open — the exact file (verified byte-identical via git diff), already committed (5c39715c, authored as the locally-configured git identity brownm09) and pushed, with a commit message reading:
"Rescued from an uncommitted local worktree during a worktree audit; the branch was fast-forwarded onto current main before committing."
This was not an action taken by the interrupted session itself (it had not reached the commit/push/PR-open steps yet). Something else — some automated "worktree audit" process — found the in-progress worktree (which looked orphaned during the interruption), fast-forwarded it onto current main, committed, pushed, and opened the PR, entirely outside the session's visibility.
What's unclear
- What mechanism/hook/routine actually did this? Nothing in the commit or PR body names it, and it doesn't match any documented dev-env routine I'm aware of (it's a materially different action than the non-destructive squatting-correction in ADR-058, which parks idle squatters rather than committing/pushing/opening PRs on their behalf).
- Is this a known, intentional dev-env mechanism (e.g. some worktree-cleanup routine that recovers "orphaned" work rather than discarding it), or something else?
- If intentional: should it notify the interrupted session (or the user) more visibly when it takes over mid-session work, rather than silently completing the git/PR mechanics? A session resuming after an interruption currently has no way to know this happened except by noticing the branch is unexpectedly already pushed.
- If unintentional/unknown: where is this coming from, and does it pose any risk (e.g. could it "rescue" a worktree that's mid-edit but not actually ready to ship)?
Suggested next step
Grep dev-env's claude/scripts/, claude/routines/, and hook configs for anything matching "worktree audit" or "rescue" terminology, and check for any cron/routine that scans .claude/worktrees/** across projects. Document the finding (or the absence of one) in the relevant ADR or REFERENCE.md runbook once identified.
No functional harm resulted this time — the rescued content was verified correct — but the lack of attribution/visibility is worth closing.
Problem
While working lifting-logbook issue #693 (add a scheduled
docker build --no-cacheCI check), a session was interrupted mid-task (process restart) whilenpm installand two local Docker builds were running in the background inside a fresh worktree (.claude/worktrees/issue-693-docker-nocache, branchchore/issue-693-nightly-docker-nocache-build). The worktree had the target file written but not yet committed at the moment of interruption.On resuming, PR #719 was already open — the exact file (verified byte-identical via
git diff), already committed (5c39715c, authored as the locally-configured git identitybrownm09) and pushed, with a commit message reading:This was not an action taken by the interrupted session itself (it had not reached the commit/push/PR-open steps yet). Something else — some automated "worktree audit" process — found the in-progress worktree (which looked orphaned during the interruption), fast-forwarded it onto current
main, committed, pushed, and opened the PR, entirely outside the session's visibility.What's unclear
Suggested next step
Grep dev-env's
claude/scripts/,claude/routines/, and hook configs for anything matching "worktree audit" or "rescue" terminology, and check for any cron/routine that scans.claude/worktrees/**across projects. Document the finding (or the absence of one) in the relevant ADR or REFERENCE.md runbook once identified.No functional harm resulted this time — the rescued content was verified correct — but the lack of attribution/visibility is worth closing.