[BUG] Aborted in-flight request leaves foreground CLI session stuck in false "Not logged in" state

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

If an in-flight request gets aborted mid-stream, the CLI session gets stuck reporting "Not logged in · Please run /login" on every subsequent prompt, even totally unrelated ones. Auth is not actually broken: claude auth status shows a valid, active auth method the whole time, and a brand new claude session in the same shell with the same env vars works immediately. This looks like the same underlying pattern as #74222 (aborted/interrupted request leaving stale in-memory auth state), but triggered without any daemon or agent-view fleet involved — a single foreground CLI process, no memory pressure, no background workers.

In our case the abort was triggered by pressing left-arrow to background the session while a request was completing right after an Agent tool call finished.

What Should Happen?

An aborted in-flight request (from a client-side interrupt, not a real auth failure) should not corrupt the session's auth state. Either the abort should be handled without touching auth state, or a retry should succeed. At minimum, the error should not claim "Not logged in" when the real condition is "an in-flight request was aborted and the client is in a bad state" — this sends users down an unrelated auth-debugging path (it did for us, for several turns).

Error Messages/Logs

❯ just a simple test task
I'll spin up a simple test agent for you.
⏺ Agent(Simple test task)
  Done (1 tool use · 21.1k tokens · 10s)
Not logged in · Please run /login
✻ Churned for 0s
❯ test again
Not logged in · Please run /login


[INFO] [Stall] tool_dispatch_start tool=Agent toolUseId=toolu_xxxxxxxx permissionDecisionMs=1
...
[INFO] [Stall] agent_completion agentId=xxxxxxxx agentType=general-purpose exitPath=completed durationMs=10744 turns=2 finalStopReason=end_turn
[INFO] [Stall] tool_dispatch_end tool=Agent toolUseId=toolu_xxxxxxxx outcome=ok durationMs=10751
...
[DEBUG] [API:timing] dispatching to firstParty model=claude-opus-4-8[1m]
[DEBUG] [API REQUEST] source=repl_main_thread
[DEBUG] [PERF:bg-leftarrow-start]
[DEBUG] [REPL:unmount] REPL unmounting
[ERROR] Error in API request: Request was aborted.

Steps to Reproduce

1. Start claude authenticated via a custom bearer-token gateway (ANTHROPIC_AUTH_TOKEN + ANTHROPIC_BASE_URL pointing at an internal LLM proxy)
2. Give it a prompt that spins up a subagent, e.g. "spin up a simple test agent"
3. While the agent tool call is completing / the next turn is dispatching, press left-arrow to background the session, aborting the in-flight request
4. Observe [ERROR] Error in API request: Request was aborted. in the debug log
5. Send any new prompt in the same session, including one completely unrelated to agents
6. Observe "Not logged in · Please run /login" on every subsequent prompt, despite claude auth status reporting valid auth throughout

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.202

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Using ZSH

The subagent itself completed successfully (exitPath=completed, finalStopReason=end_turn) before the abort occurred — the Agent tool and its auth path are not implicated.
Root cause is isolated to a client-side interrupt colliding with an in-flight request, not to subagents, gateway auth, or the auth token configuration itself.
Workaround: avoid backgrounding while a request is actively streaming. If the false "Not logged in" state occurs, restart the CLI session rather than attempting /login — the token was never actually invalid.
Related: #74222 describes the same symptom (valid auth, false "Not logged in") but via daemon/agent-view worker respawn under memory pressure. This report reproduces the same class of bug through a different trigger (foreground request abort, no daemon involved), which may help narrow down the shared root cause.