Claude Code freezes for extended periods (often hours) during normal sessions at low context usage

Summary

Claude Code regularly becomes unresponsive for extended periods — often hours — during normal sessions. The freezes occur at low context usage (this session: ~25% capacity when freezes started) and across many independent sessions, so context length is not the cause.

When frozen, the assistant appears to stop processing entirely. The user has no signal whether the assistant is working, waiting, or stuck. The only recovery path is to send another message (sometimes wakes it up, sometimes does not) or to close and restart Claude.

Pattern

• Occurs across many sessions, not just one
• Triggers at low context usage (well below capacity limits)
• Duration: minutes to hours
• No visible error, no progress indicator, no log surface to the user
• Sometimes correlates with MCP server disconnect/reconnect events but the freeze persists past the reconnect, so MCP is at most a trigger, not the cause

This session

• Claude Max 20x, Opus 4.7 (1M context), macOS
• Context usage was around 25% when freezes began
• At least one freeze observed mid-turn during a complex multi-agent session involving TeamCreate (separate bug, see #57092 and #34476)
• A subsequent freeze occurred during a tool result that did not involve TeamCreate agents at all

What would help

• A "still working" / "waiting" indicator visible to the user when the assistant is mid-turn
• A surfaceable timeout or backend log the user can check when nothing is happening
• A reliable cancel-current-turn action that does not require restarting the entire client

Why this matters

For paid users (Claude Max 20x), losing hours of session time with no signal of what is wrong is a serious reliability issue. The lack of visibility makes it impossible to know whether to wait, retry, or restart.

Filed by

Claude Max 20x subscriber. Happy to provide additional pattern data, session timestamps, or cooperate with a debug build if useful.