[BUG] macOS sleep/wake causes 401 authentication errors requiring full reboot

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/37078
2. https://github.com/anthropics/claude-code/issues/48631

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is not a duplicate of #37078 or #48631.

#37078 is about stale connection pools causing ECONNRESET errors.
#48631 is about general 401 errors across all sessions (not sleep-specific).

My issue (#60104) is specifically triggered by macOS sleep/wake cycles and requires a full system reboot to resolve - neither #37078 nor #48631 mention this specific trigger or resolution. This appears to be a distinct macOS securityd synchronization issue that persists even after the v2.1.137 Keychain race condition fix.

Adding my data here. Have been at my wit's end with this for a while.

The sleep/wake pattern in this issue lines up exactly with what I see, and the timing is the giveaway. Here is what my logs show from the most recent occurrence:

• 5 PM previous day: access token refreshed successfully, ~7.4 hours of life remaining. Everything normal.
• Lid closed for the night.
• ~12:25 AM: token expired silently mid-sleep. No process runs to refresh it because launchd StartInterval timers do not fire while the Mac is asleep.
• 5 AM: lid open, scheduled jobs start firing again. Token is already 4.5 hours dead. Every request hits 401. No automatic recovery path.
• Only fix: full claude /login flow.

The pattern is consistent across multiple occurrences over the past few weeks. It is not "token aging" in any normal sense, it is that the macOS sleep cycle straddles the access token's lifetime and there is no wake-trigger to attempt a refresh before scripts start failing.

A second issue that compounds it: when I do run claude /login to recover, macOS Claude Code writes the new token to Keychain and immediately deletes ~/.claude/.credentials.json. Any local script or hook that reads the credentials file (rather than going through the CLI) breaks until something can read Keychain back. SSH sessions cannot read the login Keychain, so remote recovery is also blocked.

Workarounds I have tried:

1. Shortening LaunchAgent intervals — does not help, launchd skips runs during sleep regardless of interval
2. Manually triggering token refresh via a CLI command — no documented refresh command exists
3. Pre-emptive claude /login before bed — works, but only because it gives ~8 hours of access token life and I am usually back at the machine before it expires

What would actually fix this for me:

• A documented access/refresh token lifetime so users can plan around it
• A claude auth refresh command that uses the refresh token to mint a new access token without the full browser OAuth flow
• A wake-from-sleep hook in the CLI (or at least documented sample code) that attempts refresh on lid open
• An option to keep the credentials file in sync with Keychain rather than deleting it on login

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Update: Issue confirmed to persist on v2.1.195 after macOS reboot.

After system reboot, authentication is temporarily restored,
but the issue recurs after sleep/wake cycles.

This requires a full system reboot every time, which is not
practical for daily usage.

Requesting escalation to engineering team for a lighter workaround.

CRITICAL: Issue is cumulative, not immediate.

Finding: Sleep/wake cycles do NOT always fail immediately.

• First sleep/wake: May succeed
• Second sleep/wake: Fails with authentication loop

This suggests Keychain state degrades progressively with each sleep/wake cycle,
or there's a state that only manifests on the second cycle.

This is NOT a simple "token expired" issue but a state management problem
that worsens with repeated sleep cycles.

Confirmed workaround:

Before sleep:

1. Keep VSCode open
2. Close Claude Code tab(s)
3. Sleep MacBook Pro

After sleep:

1. VSCode is still open
2. Create new Claude Code session
3. Use /resume to restore previous session
4. Result: No authentication loop ✅

This prevents Keychain corruption by ensuring Claude Code tabs are closed
before sleep, while maintaining VSCode state.

Trade-off: Requires /resume workflow, but avoids full macOS reboot.

UPDATE: Workaround is NOT reliable.

Testing revealed:

• First sleep/wake with tab closed: Success ✅
• Extended sleep (several hours) followed by wake: Authentication loop ❌

The workaround provides temporary mitigation but does not resolve
the underlying Keychain corruption issue during extended sleep.

Conclusion: This is not a practical long-term solution.
The root cause requires a proper engineering fix from Anthropic.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.