CLI auto-logout after ~8h idle: expired access token not silently refreshed via refresh token

Summary

When a Claude Code CLI session is left idle for ~8 hours, the access token expires and the session requires a manual /login — even though a valid refreshToken is present in ~/.claude/.credentials.json. The CLI does not proactively (or lazily on next use) refresh the token silently.

Steps to Reproduce

1. Log in to Claude Code CLI (/login)
2. Leave the session idle (no API calls) for ~8 hours
3. Return to the session and attempt to use it
4. CLI prompts for re-login despite a valid refresh token being stored

Expected Behavior

When the access token is expired but a valid refreshToken exists in credentials, Claude Code should silently exchange it for a new access token without requiring the user to manually /login.

Actual Behavior

The session appears "logged out". The user must run /login again to continue.

Environment

• Platform: Linux (Ubuntu)
• Shell: bash
• Claude Code CLI

Additional Context

Inspecting ~/.claude/.credentials.json, the credentials object contains:

• accessToken — short-lived (~8 hour TTL based on expiresAt)
• refreshToken — long-lived
• expiresAt — Unix timestamp in milliseconds

The access token TTL of ~8 hours is reasonable for security, but the UX should be transparent: the refresh token should be used automatically so users are not forced to re-authenticate on every session that spans more than 8 hours.

This is especially disruptive when:

• A login session is idle while another tool (e.g. Codex) is actively running in a separate session using the same credentials
• The user returns to the original session after the TTL window and finds it requires re-login

Suggested Fix

Before making any API call (or on CLI startup), check if expiresAt is within a threshold (e.g. < 5 minutes remaining or already expired). If so, use the refreshToken to silently obtain a new accessToken and update ~/.claude/.credentials.json — without interrupting the user.