Background auth daemon fails to recover from a rejected proactive refresh, requires manual re-login every ~8h (Max plan)

Summary

On a Max plan subscription, the background auth daemon's proactive token
refresh fails and cannot self-heal, requiring manual claude auth login every
time the access token expires (~8h). This did not happen previously on a Pro
plan subscription with the same machine/setup.

Environment

• claude --version: 2.1.220 (Claude Code)
• subscriptionType: max, rateLimitTier: default_claude_max_5x
• OS: Linux

Observed behavior (from ~/.claude/daemon.log, unedited)

[2026-07-31T05:58:30.583Z] [supervisor] auth: scheduling proactive refresh in 28555s
[2026-07-31T05:58:30.583Z] [supervisor] auth: token found via keychain re-check
[2026-07-31T13:54:25.829Z] [supervisor] auth: proactive refresh starting
[2026-07-31T13:54:26.260Z] [supervisor] auth: proactive refresh failed, signalling re-auth required
[2026-07-31T13:54:26.265Z] [supervisor] auth: headless daemon cannot complete OAuth — run `claude auth login` to refresh
[2026-07-31T13:54:26.265Z] [supervisor] auth: no token found, will re-check keychain every 30s
[2026-07-31T17:25:26.509Z] [supervisor] auth: scheduling proactive refresh in 28537s
[2026-07-31T17:25:26.509Z] [supervisor] auth: token found via keychain re-check

The pattern repeats roughly every 8 hours: proactive refresh is attempted,
fails, the daemon discards the token entirely rather than retrying, and it
only recovers once the operator runs claude auth login manually (a browser
flow), which the daemon cannot complete headlessly.

Separately, claude daemon --help states:

Service install is disabled in this version — the daemon runs on demand and exits when the last client disconnects.

So there is no persistent background service in this version; the daemon
lifecycle is tied to an active client session. On an idle terminal with no
active client, nothing is refreshing the token at all between commands.

Expected behavior

The refresh token should be usable across many token rotations without
requiring a browser-based re-login every ~8 hours, consistent with prior
behavior on a Pro plan subscription on the same machine/setup.

Question

Is proactive refresh failed on a Max plan expected to require full
re-authentication, or should the refresh token itself be retried/recovered
without discarding it? Is there a way to trigger a headless refresh (e.g. a
claude auth refresh subcommand) that does not require opening a browser?

Additional notes

• claude auth status reports a valid, logged-in state immediately after

manual re-login, so the credentials file itself is not corrupted — only the
daemon's background refresh path fails.

• This has recurred multiple times over 2026-07-30/31, roughly every 8 hours

(the access token TTL), each requiring a fresh interactive login.