0.2.5 and 0.2.6 on macOS 26.6.2, two Macs with 15 and 19 Claude accounts.
What happened. I quit the app on one Mac to install 0.2.6 and relaunched it. Its first refresh flagged 8 of 15 Claude accounts as needing re-authentication: every account whose login was 37 to 39 days old (connected 2026-08-07 to 08-09, on 0.2.2 through 0.2.4). The 7 accounts logged in within the previous 22 days kept refreshing. At the cycle before the quit, all 15 had refreshed.
Why, from the cookie jars (names and dates only). sessionKey in each account's WKWebsiteDataStore carries an expiry 28 days after its creation. On the Mac that lost accounts, the 7 surviving jars hold a sessionKey created 08-24 to 08-31 and expiring 09-21 to 09-28; the 8 failed jars hold 4 or 5 cookies and no sessionKey at all. On the other Mac, where I re-logged every account on 2026-09-06, all jars show sessionKey created 09-06 expiring 10-04, and none carries a newer one after nine days of ten-minute refreshes. The client copies cookies into its own Cookie header, so if claude.ai rotates the session in a Set-Cookie reply, the jar never sees it.
While the process runs, the in-memory cookie keeps working past its expiry: the 8 accounts refreshed for 9 to 11 days after their cookies had expired. A relaunch reloads the jar, WebKit drops the expired cookie, and apiCookies throws reauthenticationRequired. So nothing shows until the next relaunch, and then every account past 28 days goes dark at once. A reboot does the same.
Two things would help, either alone:
- Show the session expiry per account, from the cookie's own expiry date, and flag it in the menu ahead of time, so a re-login can happen before the accounts go dark.
- If claude.ai rotates
sessionKey on API calls, write the Set-Cookie back into the account's data store so an actively refreshed account never expires. I have not checked whether the server sends one.
Happy to test either on the Mac with the 8 dead accounts before I re-login them.
0.2.5 and 0.2.6 on macOS 26.6.2, two Macs with 15 and 19 Claude accounts.
What happened. I quit the app on one Mac to install 0.2.6 and relaunched it. Its first refresh flagged 8 of 15 Claude accounts as needing re-authentication: every account whose login was 37 to 39 days old (connected 2026-08-07 to 08-09, on 0.2.2 through 0.2.4). The 7 accounts logged in within the previous 22 days kept refreshing. At the cycle before the quit, all 15 had refreshed.
Why, from the cookie jars (names and dates only).
sessionKeyin each account'sWKWebsiteDataStorecarries an expiry 28 days after its creation. On the Mac that lost accounts, the 7 surviving jars hold asessionKeycreated 08-24 to 08-31 and expiring 09-21 to 09-28; the 8 failed jars hold 4 or 5 cookies and nosessionKeyat all. On the other Mac, where I re-logged every account on 2026-09-06, all jars showsessionKeycreated 09-06 expiring 10-04, and none carries a newer one after nine days of ten-minute refreshes. The client copies cookies into its ownCookieheader, so if claude.ai rotates the session in aSet-Cookiereply, the jar never sees it.While the process runs, the in-memory cookie keeps working past its expiry: the 8 accounts refreshed for 9 to 11 days after their cookies had expired. A relaunch reloads the jar, WebKit drops the expired cookie, and
apiCookiesthrowsreauthenticationRequired. So nothing shows until the next relaunch, and then every account past 28 days goes dark at once. A reboot does the same.Two things would help, either alone:
sessionKeyon API calls, write theSet-Cookieback into the account's data store so an actively refreshed account never expires. I have not checked whether the server sends one.Happy to test either on the Mac with the 8 dead accounts before I re-login them.