[BUG] Response latency of up to 15 minutes, reproducible in both Desktop app and CLI, fixed only by fully quitting/restarting

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?

Bug: Response latency of up to 15 minutes, reproducible in both Desktop app and CLI, fixed only by fully quitting/restarting

Summary

Both the Claude Code Desktop app and the CLI intermittently stall for very long periods (observed up to ~15 minutes) before responding to even trivial messages (e.g. a single "テスト" / "test"). The issue is not tied to a specific model, does not require a long conversation history, and reproduces across two different client implementations (Desktop, CLI). The only reliable fix found so far is to fully quit the app / kill the CLI process and restart it — simply waiting, or starting a brand-new thread, does not help.

Environment

• Client: Claude Code Desktop app (macOS) and Claude Code CLI
• Models tested: Opus 4.8, Sonnet 5 — both affected equally
• OS: macOS (Darwin 24.6.0)

Steps to reproduce

1. Use Claude Code (Desktop or CLI) normally for a while.
2. At some point, send a short message (e.g. "テスト").
3. Observe that no response arrives for several minutes, up to ~15 minutes in the worst observed case.

What does NOT fix it

• Switching model (Opus → Sonnet, or vice versa) — stall still occurs.
• Starting a brand new thread/session with the same client still running — stall still occurs.
• /fast mode — not supported/functional in this environment.
• Pressing ESC / Ctrl+Q to "cancel" — see below, this does not actually cancel the underlying request.

What DOES fix it

• Fully quitting the Desktop app (not just closing the window) and relaunching it.
• Killing and restarting the CLI process.
• After a full restart, the very next message gets an immediate, normal-speed response.

This strongly suggests the root cause is client-side session/connection state that degrades over time (e.g. a stale or zombied network connection, a stuck internal request queue, or a broken token/session refresh), rather than server-side (API) congestion — genuine server-side slowness would not be resolved by restarting a local client.

Secondary/related symptom: ESC does not cancel the in-flight request

When a response is stalled and ESC / Ctrl+Q is pressed to "cancel," followed by sending a new short message:

• The new message gets an immediate, correct response.
• Shortly after, the original (supposedly cancelled) request's answer also comes back on its own, and the client then treats it as if it were a new answer to whatever the most recent input was — producing a confusing "it came back out of nowhere" experience.

This suggests ESC only stops client-side rendering/waiting UI, without actually cancelling the underlying in-flight request to the server, and the client does not track/discard the stale in-flight request once a new one is sent. This looks like the same class of bug as the main stall (broken tracking of request/connection state), rather than an unrelated issue.

Impact

This makes both the Desktop app and CLI effectively unusable for stretches of a session, with no in-app indication of what is wrong or how long the stall will last, and no workaround except guessing to fully restart.

Suggested investigation areas

• Long-lived WebSocket/HTTP connection lifecycle management in the client (both Desktop and CLI share underlying Agent SDK connection logic?)
• Auth/session token refresh handling — does a refresh failure silently hang requests instead of erroring out?
• Whether ESC/interrupt actually sends a cancellation to the server, or only stops local UI updates while the server-side request continues to completion
• Whether there's a way to detect a "stuck" connection client-side and auto-recover without requiring a full app restart

What Should Happen?

Claude Code should respond within a few seconds to tens of seconds, without requiring a full application restart to recover normal response speed.

Error Messages/Logs

Steps to Reproduce

1. Use Claude Code normally (Desktop or CLI) for an extended session.
2. Send a short, simple message/prompt.
3. Observe that the response takes anywhere from several minutes up to 15 minutes to arrive.
4. Note that waiting does not resolve the slowdown — only fully quitting and restarting the app/CLI restores normal (fast) response times.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.177 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_