OAuth refresh lock can be taken over when the process holding it is gone

What

When Claude Code renews your login token (an OAuth refresh), it first takes a lock file. The lock stops two Claude Code windows from refreshing at the same moment. Before this release, a process that crashed while holding the lock could leave other sessions stuck: after 5 failed retries they simply gave up, or waited for the lock to time out after 60 seconds.

• Taking the lock now also writes an owner record to .oauth_refresh.lock.owner. It holds the process ID (pid), the process start time, the pid domain or space, and the time the lock file was created. The record is deleted when the lock is released.
• If the lock is still held after the retries, Claude Code reads the owner record and checks whether that process is provably gone.
• If it is, Claude Code deletes the stale lock (and the older legacy lock file, if present) and tries the refresh again.
• If it cannot prove that, it leaves the lock alone. Reasons include foreign_pid_space (the owner ran somewhere whose process list it cannot see), an untrusted process list, holder_not_proven_gone and legacy_lock_held.

The takeover is tied to the gate tengu_quiet_marten, a remotely controlled switch. Nothing has been read about this gate, so which way it is set is unknown.

Why

If you run several Claude Code sessions that share one configuration folder, one crashed session could leave the others unable to renew their login, which shows up as authentication failures, hangs or refresh lock timeouts. Where the takeover runs, another session can clean up after the crashed one instead of waiting it out. It only removes a lock when it can prove the owner has gone, so a slow but still running session is not interrupted.