Terminal becomes unresponsive after completing work (UI frozen, process alive)

Terminal becomes unresponsive after completing work (UI frozen, process alive)

Description

Claude Code CLI sessions become completely unresponsive after completing work. The terminal freezes (no scrolling, no keyboard input), but the process remains alive and healthy. Resume attempts on affected sessions also hang. This appears to be a regression that started approximately January 12-13, 2026.

This is NOT the large session file bug (#16251) - see investigation details below.

Environment

• Claude Code Version: 2.1.12
• Platform: Linux (Ubuntu)
• OS Version: Linux 6.8.0-90-generic
• Terminal: GNOME Terminal (xterm-256color)
• Installation: Native installer (~/.local/bin/claude -> ~/.local/share/claude/versions/2.1.12)

Symptoms

1. Terminal becomes completely unresponsive:

• Cannot scroll up/down
• Keyboard input is ignored
• No visible cursor or input prompt

1. Process remains running:

• PID shows as sleeping (S state) on epoll_wait
• 0% CPU usage
• Connected to terminal (pts device exists)
• 18 threads running normally

1. Resume attempts hang:

• Running claude --resume or claude -r in a new terminal
• Session picker appears, selecting session causes hang
• Only message shown: "Resuming conversation" then freeze

Reproduction Steps

1. Start Claude Code in any directory: claude
2. Give it a multi-step task (e.g., "Read a plan file and implement it")
3. Let it complete the work (may involve multiple tool calls, file edits, builds)
4. After it reports completion, the terminal freezes:

• No input prompt appears
• Scrolling stops working
• Keyboard input ignored

1. The process remains alive but UI is unresponsive

Frequency: Intermittent but increasingly common. Approximately 3-4 sessions affected in past 3 days across different worktrees.

Why This Is NOT Bug #16251 (Large Session File)

| Aspect | Large File Bug (#16251) | This Bug |
|--------|-------------------------|----------|
| Session file size | >10MB | 925KB (small) |
| "Slow render" events | Yes (300ms+, 700K+ changes) | None |
| Trigger | Resume with large history | After completing normal work |
| CPU during hang | Spikes to 100% | 0% |

Investigation Details

Session Analyzed: ead358d2-1785-4071-ac28-575b05f595e6

Session Characteristics:

• File size: 925KB (not large)
• Total entries: 254 lines
• Assistant messages: 97
• Work completed normally (has stop_hook_summary, turn_duration system entries)

Process State When Hung:

PID     STATE  WCHAN   CMD
200279  S      ep_pol  claude --dangerously-skip-permissions

State: S (sleeping)
Threads: 18
CPU: 0%
Memory: 3.8% (626MB)

Debug Log Timeline

00:04:19 - LSP/clangd errors (non-fatal, connection issues)
00:06:35 - Final API stream started
00:07:08 - "Stop" event processed
00:07:10 - Session state written to disk
00:07:14 - "SubagentStop" event (work completed)
00:08:10 - "idle_prompt" notification triggered
00:08:12 - Notification hook completed successfully
00:29:32 - Version check (only activity 21 minutes later)

No errors at hang point - the session appears to have completed normally but the UI never returned to accepting input.

Session File Analysis

Last 5 entries in session file:

Entry 249: assistant - stop_reason=None, output_tokens=1
Entry 250: assistant - stop_reason=None, output_tokens=1 (contains "Implementation Complete" text)
Entry 251: progress
Entry 252: system - subtype=stop_hook_summary
Entry 253: system - subtype=turn_duration

The presence of stop_hook_summary and turn_duration confirms the turn completed normally on the backend.

Consistent Pattern Across Multiple Hangs

Three separate sessions have hung with the same pattern:

• All have stop_hook_summary and turn_duration system entries (work completed)
• All assistant messages have stop_reason=None
• Work completes successfully, but UI never returns to accepting input

Common timeline:

SubagentStop event -> ~55 seconds -> idle_prompt notification ->
Notification hook completes (status 0) -> UI NEVER returns to input prompt

Hooks/Statusline Ruled Out

Evidence that hooks are NOT the cause:

1. All hooks complete with status 0 in debug logs
2. Statusline script executes correctly when tested directly (<1 second)
3. Process continues background activities after hang (version checks, MCP reconnections)
4. "High write ratio" terminal render events continue 30+ minutes after hang

Contrast: Previously Working Behavior

Before ~January 12:

• Sessions could get full and compact multiple times
• Very long sessions remained responsive
• Resume always worked regardless of session size
• Terminal never froze after completing work

After ~January 12:

• Sessions hang after completing work
• Hangs occur even on small sessions
• Resume attempts on affected sessions also hang
• Terminal becomes completely unresponsive

Potentially Related Issues

• Issue #19195: Background task queue operations after completion signal cause session hang (stop_reason: null)
• Issue #19060: CLI freezes with "No messages returned" error

Impact

• Severity: High - completely blocks continued use of session
• Workaround: Must kill terminal and start fresh session (losing context)
• Data loss: Work is saved but session state is lost
• Productivity: Significant disruption to development workflow

Diagnostic Data Available

I have preserved debug logs, session files (.jsonl), and process state information for affected sessions. Happy to provide any additional diagnostic information.