Auth session drops during long conversation with Opus 4.6 (1M context) — unrecoverable without CLI restart

Environment

• Claude Code version: 2.1.81
• Model: claude-opus-4-6 (1M context)
• OS: macOS Darwin 25.2.0 (Apple Silicon)
• Shell: zsh

Description

During a long conversation (~1700+ JSONL lines, heavy tool use including cargo builds, QEMU runs, file edits), the auth session dropped mid-command and became unrecoverable without fully restarting the CLI process.

Reproduction Steps

1. Start a long session with Opus 4.6 (1M context) — heavy tool use (dozens of Bash, Edit, Read calls)
2. At ~1700+ conversation lines, the agent runs a git clone command via Bash tool
3. The Bash command fails with getcwd: No such file or directory (the working directory became invalid)
4. After this failure, the session enters a broken state:

• The CLI reports "Not logged in · Please run /login" for all subsequent interactions
• Running /login reports "Login successful" but the next prompt still says "Not logged in"
• Running /model shows the model had silently switched from Opus 4.6 to Sonnet 4.6 (user did not request this)
• The session is unrecoverable — only a full Ctrl+C + restart of the CLI process fixes it

JSONL Evidence

From the session transcript (~/.claude/projects/.../4f5f87a2-....jsonl):

L1704 [claude-opus-4-6] TOOL: Bash: rm -rf .../limine && git clone https://github.com/...
L1709 [<synthetic>] TEXT: Not logged in · Please run /login    ← auth drops here
L1718 USER: ok idk what happened, but you switched to sonnet 4.6 model and errored out
L1719 [<synthetic>] TEXT: Not logged in · Please run /login    ← still broken
L1727 USER: /login → "Login successful"
L1729 USER: ok idk what happened, weird bug but you should be good now?
L1730 [<synthetic>] TEXT: Not logged in · Please run /login    ← STILL broken after login

Key observations:

• The [<synthetic>] model tag shows the CLI generated the "Not logged in" message locally, not from the API
• The model switch from Opus to Sonnet was never recorded in the JSONL — happened at CLI layer
• The getcwd: No such file or directory error from the failed git clone may have corrupted the shell process state, cascading into the auth failure
• The token was NOT actually expired — a parallel Claude Code session on the same machine continued working fine throughout

Expected Behavior

• Auth should survive shell command failures (even getcwd errors)
• /login should actually recover the session when it reports "Login successful"
• Model should not silently switch without user action

Actual Behavior

• Auth drops after a shell command fails with a working directory error
• /login reports success but doesn't actually recover the session
• Model silently switches from Opus 4.6 to Sonnet 4.6
• Only a full CLI restart recovers

Workaround

Kill the CLI process (Ctrl+C) and start a fresh claude session. The auth token is still valid — the issue is purely in the CLI's session state management.