Claude Code Process Deadlock/Infinite Loop - Requires SIGKILL

Resolved 💬 3 comments Opened Feb 13, 2026 by dbachelder Closed Feb 16, 2026

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

  1. UI completely freezes - timers on screen stop ticking
  2. Process shows 0% CPU usage
  3. 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)
  4. Process enters state 'S+' (sleeping in foreground)
  5. Process ignores SIGTERM (graceful shutdown signal)
  6. 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_slow waiting 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:

  1. Lost network connection without proper timeout/error handling
  2. Deadlock in async code - process waiting on a lock that never releases
  3. 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.

View original on GitHub ↗

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