{"version":"2.1.288","anchor":"auth-refresh-lock-stale-handling-and-takeover-logic-reworke","canonical_anchor":"auth-refresh-lock-stale-handling-and-takeover-logic-reworke","heading":"Login refresh lock is no longer taken from a process that is still alive","tier":"notice","area":"Auth","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.288\/e\/auth-refresh-lock-stale-handling-and-takeover-logic-reworke","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.288","markdown":"### Login refresh lock is no longer taken from a process that is still alive\n\nWhen processes share login credentials, a refresh lock held by a live process no longer counts as stale after a fixed 60 seconds\n\n**Unclear.** The exact waiting time used when the holder is not proven to be running is not stated.\n\n**What**\n\nWhen several Claude Code processes share the same login credentials, one of them takes a lock while it refreshes the login, so the others wait. Before, any lock older than 60 seconds was treated as abandoned and could be taken over. Now:\n\n- a lock whose holder is shown to still be running is never treated as abandoned\n\n- a lock whose holder cannot be shown to be running becomes abandoned after a set time\n\n- a request to take over the lock is tied to the holder's folder rather than to its process\n\nThe log message written when a process takes over a lock is also shorter.\n\n**Why**\n\nThis may cut down on one Claude Code process wrongly taking the lock from another that is still busy refreshing, which matters when you run several at once.\n\n- Area: Auth\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}