Claude Code freezes/hangs with no input accepted — 100% write ratio in terminal renderer

Open 💬 12 comments Opened Feb 12, 2026 by davidpmclaughlin

Description

Claude Code CLI sessions become completely unresponsive — no keyboard input is accepted (Ctrl+C, Ctrl+D, typing all ignored). The process stays alive but the UI is frozen. The only recovery is to kill the process from another terminal.

This has happened at least 5 times in the past few days. Two frozen sessions were caught running simultaneously today.

Version & Environment

  • Claude Code: 2.1.39
  • OS: macOS 26.2 (Build 25C56), Apple Silicon (arm64, T6041)
  • RAM: 24 GB
  • Terminal: Apple Terminal 466
  • Shell: /bin/bash

Reproduction

Occurs during long conversations with many tool calls (Slack API, file reads, MCP server interactions). No SSH commands, no large file reads, no massive output — normal usage with moderate-sized API responses.

Frozen Session Details

Session 1 (PID 37894) — frozen ~15h 43m

  • Debug log: f206e0fe-fcf9-4e49-8767-897226513853.txt (3.5MB)
  • Message count at freeze: 747 deferred messages
  • Token count at freeze: 121,004 / 167,000 threshold
  • Last log entries: High write ratio: blit=0, write=86776 (100.0% writes), screen=1299x143
  • Freeze time: 2026-02-12T05:52:02Z
  • Pattern: API request made → stream started → high write ratio loop → silence

Session 2 (PID 58385) — frozen ~9h 14m

  • Debug log: 1474e176-7d40-404d-bc27-2fd1459e3619.txt (2.1MB)
  • Message count at freeze: 1,170 deferred messages
  • Token count at freeze: 156,796 / 167,000 threshold (very close to threshold!)
  • Last log entries: High write ratio: blit=0, write=80922 (100.0% writes), screen=1850x95
  • Freeze time: 2026-02-12T14:07:48Z
  • Pattern: identical — API request → stream chunk received → high write ratio → silence

Common Pattern Across All Freezes

  1. Debug logs show High write ratio: blit=0, write=80000-87000 (100.0% writes) — the terminal renderer is doing zero blits and 100% full-screen writes every frame
  2. The [useDeferredValue] Messages deferred by 1 count climbs into the hundreds/thousands
  3. An API request is made, a stream starts, and then the process goes silent
  4. No error, crash, OOM, or signal logged — it just stops writing to the debug log
  5. The process remains alive (S+ state in ps) but accepts no input

Historical Occurrences

Scanning all debug logs, at least 4 sessions ended with this exact 100.0% writes pattern:

  • 2026-01-28 (d1a5eb06) — write=1333
  • 2026-02-04 (ca45a690) — write=1163
  • 2026-02-11 (b26b881d) — write=56639
  • 2026-02-12 (f206e0fe) — write=86776

The write counts have been growing over time, suggesting the issue gets worse with longer/more complex conversations.

Hypothesis

The terminal renderer appears to enter a state where it can only do full-screen rewrites (0 blits) with very large write buffers (80-87KB per frame). Combined with high message counts (700-1170 deferred messages) and token counts near the autocompact threshold, this seems to cause the event loop to block, preventing input handling.

Session 2 was at 156,796/167,000 tokens (94% of threshold) — the proximity to the autocompact threshold may be a contributing factor.

Environment Notes

  • Multiple MCP servers active (gdrive, slack, gmail) per session
  • Using Apple Terminal (not iTerm2 or other alternatives)
  • Conversations involve frequent Slack API calls with JSON responses

🤖 _This bug report was written with AI assistance (by Claude Code itself, analyzing its own debug logs)_

View original on GitHub ↗

This issue has 12 comments on GitHub. Read the full discussion on GitHub ↗