Desktop app freezes during large builds — token stream stalls while timer continues

Description

Claude Code in the desktop app (not terminal CLI) consistently freezes during large builds. The token stream stalls completely — the token counter stops incrementing — but the session timer continues running indefinitely. The UI becomes unresponsive to the build task, with no error message, no timeout, and no recovery.

This is not an intermittent/random issue. It reproduces reliably when large multi-file builds are initiated in the desktop app. The only workaround is to clear the conversation, which destroys all session context.

Steps to Reproduce

1. Open Claude Code in the Claude Desktop app
2. Start a large build task (multi-file generation, significant codebase modifications)
3. Observe the token counter and timer in the bottom status bar
4. After some initial progress, the token count freezes (e.g., at 438 tokens)
5. The timer continues running (observed from 6m05s to 12m49s with zero additional tokens)
6. The build never completes — the session is effectively dead

Expected Behavior

The token stream should continue flowing, or if a timeout/error occurs, the app should surface it and allow the user to retry without losing session context.

Actual Behavior

• Token count freezes mid-stream (screenshots show it stuck at 438 tokens)
• Timer keeps incrementing (6m → 12m+)
• No error message displayed
• No automatic retry or recovery
• Only option is to clear the conversation, losing all context

Screenshots

Screenshot 1 — 6m05s into the build, frozen at 438 tokens:
The orange spark icon indicates the model is supposedly still processing, but no tokens are arriving.

Screenshot 2 — 12m49s, still frozen at 438 tokens:
The indicator has changed to a red/orange dot. Nearly 7 additional minutes elapsed with zero token progress.

(Note: Screenshots are from the desktop app status bar. Happy to provide additional screenshots or screen recordings if needed.)

Environment

| Detail | Value |
|--------|-------|
| Claude Desktop App Version | 1.3109.0 |
| Claude Code CLI Version | 2.1.104 |
| OS | macOS 15.7.3 (Build 24G419) |
| Architecture | arm64 (Apple Silicon) |
| CPU | Apple M4 Pro, 14 cores |
| RAM | 24 GB |
| Disk | 637 GB free of 926 GB |

Relevant Log Findings

From ~/Library/Logs/Claude/:

1. 27 MCP servers connected at session focus time — this is a significant number of concurrent server connections that may contribute to resource pressure:

• Includes: Bigdata.com, Gmail, Chrome, registry, sequential-thinking, unityMCP, browsermcp, scheduled-tasks, plus 14 plugin servers (finance, design)

1. Recurring authentication errors (every 2-5 minutes throughout the session):

``
[REACT_QUERY_CLIENT] QueryClient error: {"type":"authentication_error","statusCode":401,...,"message":"You must authenticate with GitHub."}
``
These 401 errors fire on a polling loop even when GitHub integration isn't actively being used, suggesting unnecessary background request overhead.

1. Model config 404s:

``
[REACT_QUERY_CLIENT] QueryClient error: {"type":"not_found_error","statusCode":404,...,"endpoint":"/api/organizations/.../model_configs/claude-opus-4-7[1m]"}
``

1. System memory pressure (from system-info.txt at time of capture):

• Free Memory: 0.07 GB
• Memory Usage: 99.7%
• Process Memory (Private): 252.56 MB

1. No explicit error, crash, or timeout logged when the freeze occurs — the main.log shows normal session activity then silence. No hang detection, no watchdog timeout, no recovery attempt.

Impact

• Context loss is the critical issue. When the freeze occurs mid-build, the user must clear the conversation to recover. On large projects, the session context (architecture decisions, file state, build plan) cannot be reconstructed.
• This makes the desktop app unreliable for its primary use case — extended coding sessions with large builds.
• The terminal CLI version does not exhibit this behavior on the same machine with the same tasks.

Possible Contributing Factors

• 27 concurrent MCP server connections creating resource/memory pressure
• Recurring 401 GitHub polling errors adding unnecessary network overhead
• High system memory utilization (99.7%) potentially triggering OS-level throttling
• No timeout/retry mechanism for stalled token streams in the desktop app
• Electron renderer may be blocking on the main thread during heavy operations

Suggested Improvements

1. Implement a stall detector — if no tokens arrive for N seconds, surface an error and offer retry
2. Don't require conversation clear to recover — allow resending the last message or reconnecting the stream
3. Reduce background polling overhead — the GitHub 401 errors fire every few minutes even when unused
4. Add memory pressure monitoring — warn when system memory is critically low rather than silently degrading