A status read that takes a write lock

git status is not read-only. It refreshes the index and writes it back, so it acquires .git/index.lock exactly like a commit does. Six hook call sites read status on a timer or a lifecycle event, so they raced whatever the session was actually doing.

The collision

Drag the slider to move the hook's sampling moment, and toggle the flag to see the difference. The hook is the amber lane; your command is the blue one.

pass --no-optional-locks hook fires at:

your command

hook status

Why the error message makes it worse

The message names a stale lock and tells you to delete the file by hand. That is the correct remedy for a crashed process and the wrong one here, where the lock belongs to a live operation and clears by itself. On a repository shared by several worktrees and sessions, following the advice can strand somebody else's partial state. Measured 2026-08-25: four consecutive commands failed this way while the lock was already gone by the time it could be inspected.

What changed

file	calls

worktree list is deliberately untouched: it does not take the index lock. A ratchet test scans hook source and fails, naming file and line, if a plain status call reappears.