[Bug] GC death spiral causes process freeze with unresponsive Ctrl+C during long sessions #19344

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   has reproHas detailed reproduction stepsHas detailed reproduction steps

   platform:macosIssue specifically occurs on macOSIssue specifically occurs on macOS

   area:tui

   area:tools

   area:core

   memory

   perf:memory

   on Jan 19, 2026
2. github-actions commented on Jan 19, 2026

   

   github-actionsBot

   on Jan 19, 2026 – with GitHub Actions

   More actions

   Found 3 possible duplicate issues:

   1. [BUG] Claude Code v2.1.9 Complete Freeze - 100% CPU, Main Thread Stuck in Infinite Loop (macOS ARM64) #18532
   2. Memory leak causing V8 OOM crashes (SIGABRT) on extended sessions #18011
   3. [BUG] Memory leak in long-running idle Claude Code sessions #18859

   This issue will be automatically closed as a duplicate in 3 days.

   • If your issue is a duplicate, please close it and 👍 the existing issue instead
   • To prevent auto-closure, add a comment or 👎 this comment

   🤖 Generated with Claude Code
3. ariccio commented on Jan 20, 2026

   

   ariccio

   on Jan 20, 2026

   More actions

   FWIW when you need to increase the heap size, this is the command I use: export NODE_OPTIONS="${NODE_OPTIONS:-} --max-old-space-size=16384

   I'm gonna spam this a few places since it's a useful workaround for some of the bugs in this claude code version where peak memory consumption may be 10x larger than average.
4. raphaelweber commented on Jan 26, 2026

   

   raphaelweber

   on Jan 26, 2026

   Last edited by raphaelweber

   More actions

   I'm experiencing similar freezes, but my analysis suggests a different root cause - not GC thrashing, but a thread deadlock.

   Thread State Analysis

   Analyzed a frozen process via /proc/<pid>/task/*/wchan:

   Thread Type	State	Count
   Main thread	ep_poll (waiting for epoll events)	1
   Worker threads	futex_wait_queue (blocked on mutex)	18
   I/O thread	wait_woken	1

   Diagnosis

   This is not GC thrashing - the threads are blocked on mutexes, not in garbage collection.

   The main thread is stuck in ep_poll, waiting for events. The UI thread (which should process keyboard input) is blocked on futex_wait_queue - waiting for a mutex/lock.

   This indicates a classic deadlock:

   • One thread holds a lock and is waiting for I/O
   • The UI thread is waiting for the same lock
   • Result: Complete freeze, no input processing

   Key Difference from GC Death Spiral

   Metric	GC Death Spiral (#19344)	My Case
   CPU	150-180%	Low (no spinning)
   Thread state	GC functions	futex_wait_queue
   Memory	Growing	Stable

   Additional Observations

   • Process shows State: R (running) because one thread is active, but the event loop never runs
   • Network connections to API server remain ESTABLISHED - TCP is open but no data flowing
   • Issue started a few days ago, occurs irregularly (every few minutes to hours)

   Concrete Reproduction Case

   I found a specific trigger: blocking serial port access.

   stty -F /dev/ttyUSB0 115200 raw -echo && timeout 8 cat /dev/ttyUSB0 2>&1 || true

   When Claude Code executes this via the Bash tool:

   • The process holds /dev/ttyUSB0 open (visible via lsof)
   • One thread is stuck on wait_woken (blocking read on serial port)
   • The entire UI freezes - even though timeout 8 should abort after 8 seconds
   • Esc doesn't work, timer stops, no input possible

   This suggests Bash tool execution blocks the main event loop instead of running asynchronously.

   Update: The freeze also occurs with non-blocking commands and even with background workarounds (command &). The issue is not specific to serial ports - any Bash tool execution can trigger the freeze. This happened multiple times within minutes during normal usage.

   Additional Evidence

   After killing the frozen process:

   • The terminal immediately showed buffered keystrokes that were typed during the freeze
   • These keystrokes were passed to the shell (causing "command not found" errors)
   • This confirms the UI thread was blocked but the process was still alive - keyboard input was buffered by the terminal but never read by Claude Code

   Environment

   • Claude Code 2.1.19
   • Ubuntu 24.04.3 LTS
   • Kernel 6.14.x

   ---

   This may be a separate issue or a different code path leading to similar symptoms. Wanted to document this in case it helps narrow down the problem.
5. github-actions

   added

   staleIssue is inactiveIssue is inactive

   on Feb 13, 2026
6. github-actions commented on Feb 28, 2026

   

   github-actionsBot

   on Feb 28, 2026 – with GitHub Actions

   More actions

   Closing for now — inactive for too long. Please open a new issue if this is still relevant.
7. github-actions

   closed this as not plannedon Feb 28, 2026
8. github-actions commented on Mar 7, 2026

   

   github-actionsBot

   on Mar 7, 2026 – with GitHub Actions

   More actions

   This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.
9. github-actions

   locked as resolved and limited conversation to collaborators on Mar 7, 2026