Claude Code Process Deadlock/Infinite Loop - Requires SIGKILL
Claude Code Process Deadlock/Infinite Loop - Requires SIGKILL
Environment
- OS: macOS 26.2 (25C56)
- Claude Code Version: 2.1.41
- Architecture: ARM64 (Apple Silicon)
Description
Claude Code process becomes completely unresponsive and stuck in an infinite loop, with frozen UI (timers stop updating). The process ignores SIGTERM and requires SIGKILL to terminate.
Context When Issue Occurred
- Working directory:
/Users/dan/src/roomie - Using parallel agents for a planning task with the VBW framework
- Process had been running for ~43 minutes when it froze
- Note: This issue has occurred multiple times across different sessions, both with VBW framework, other prompting frameworks, and without any framework
Observed Behavior
- UI completely freezes - timers on screen stop ticking
- Process shows 0% CPU usage
- No network connections - despite being mid-session, process had zero active connections to Anthropic API (compared to healthy sessions which show multiple ESTABLISHED HTTPS connections to 160.79.104.10)
- Process enters state 'S+' (sleeping in foreground)
- Process ignores SIGTERM (graceful shutdown signal)
- Only responds to SIGKILL (force kill)
Stack Trace Analysis
Stack trace captured via sample tool shows:
- 870 consecutive samples in the exact same code path - classic infinite loop pattern
- Main thread stuck in
_os_unfair_lock_lock_slowwaiting on__ulock_wait2 - Repeated calls to the same memory address (0x104fd5aec) indicating a loop
Key Stack Trace Snippet
870 ??? (in 2.1.41) load address 0x1020a0000 + 0x2f35aec [0x104fd5aec]
870 ??? (in 2.1.41) load address 0x1020a0000 + 0x2f35aec [0x104fd5aec]
870 ??? (in 2.1.41) load address 0x1020a0000 + 0x2f35aec [0x104fd5aec]
870 ??? (in 2.1.41) load address 0x1020a0000 + 0x2f35aec [0x104fd5aec]
...
870 _os_unfair_lock_lock_slow (in libsystem_platform.dylib) + 176
870 __ulock_wait2 (in libsystem_kernel.dylib) + 8
Process Details
PID: 33406
TTY: ttys032
Elapsed Time: 43:39
CPU Time: 3:57.24
Status: S+ (sleeping, foreground)
Physical Footprint: 417.9M
Physical Footprint (peak): 474.1M
Diagnostic Commands Used
# Process status
ps -p 33406 -o pid,stat,%cpu,%mem,tty,etime,time,command
# Network connections (returned empty - smoking gun)
lsof -p 33406 -a -i
# Stack trace
sample 33406 1 -f /tmp/claude_sample.txt
# Termination attempts
kill -TERM 33406 # Failed - process ignored signal
kill -9 33406 # Succeeded
Suspected Root Cause
Based on the evidence:
- Lost network connection without proper timeout/error handling
- Deadlock in async code - process waiting on a lock that never releases
- Event loop blockage - Node.js event loop completely frozen, unable to process signals
The lack of network connections despite being mid-session suggests the process lost its API connection and got stuck waiting for a response that never came, without proper timeout recovery.
Expected Behavior
- Process should handle network timeouts gracefully
- Process should respond to SIGTERM for graceful shutdown
- UI should show error state or timeout message rather than freezing
- Process should not enter infinite loops or deadlocks
Reproducibility
- Frequency: Has occurred multiple times across different sessions
- Pattern: Not consistently reproducible, but happens regularly enough to be problematic
- Contexts: Occurs with VBW framework, other prompting frameworks, and without frameworks
- Common factors: Often happens during longer operations or when using parallel agents
Additional Context
This appears to be a recurring bug affecting multiple users. The process enters a state where:
- The event loop is completely blocked
- It cannot respond to any signals except SIGKILL
- No error is shown to the user
- All network connections are dropped
Attachments
Full stack trace sample available upon request (526 lines, redacted for privacy).
Workaround
Monitor for stuck processes and manually kill:
# Identify stuck sessions (0% CPU, no network connections)
ps aux | grep claude
lsof -p <PID> -a -i # Should show HTTPS connections; if empty, likely stuck
# Kill stuck process
kill -9 <PID>
---
Impact: High - Requires manual process monitoring and force killing, results in lost work context when session terminates unexpectedly.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗