SIGWINCH (terminal resize) causes runaway memory allocation → OOM kill

Environment

• Claude Code 2.1.83
• Linux 6.17.0 aarch64 (OCI ARM A1.Flex, 24GB RAM, 0 swap)
• Running inside tmux, accessed via terminal pane in a web-based dashboard

Reproduction

1. Start a Claude Code session inside a tmux pane with a non-trivial conversation (~3000 messages, ~7MB on disk)
2. Resize the tmux pane by dragging a column divider (produces rapid burst of SIGWINCH signals)
3. Claude Code process memory spikes from <1GB to 21GB in ~6 seconds → Linux OOM killer fires

What happened

Dragging a tmux pane border while a Claude Code session was idle triggered a runaway memory allocation. The Ink/React TUI renderer appears to lack SIGWINCH debouncing — each resize event during the drag queues a full re-render before the prior one is freed, causing unbounded heap growth.

Kernel OOM log

Out of memory: Killed process 887731 (claude) total-vm:96256392kB, anon-rss:21348556kB

A second Claude session (PID 888303) in a different tmux pane was unaffected at 728MB RSS — confirming the spike was caused by the resize, not pre-existing bloat.

Scope summary (systemd cgroup)

Consumed 50min 29.757s CPU time, 8.8G memory peak

Expected behaviour

Terminal resize should debounce SIGWINCH and perform a single bounded re-render. Even with a large conversation, a resize should not allocate more than a few MB.

Workaround

On our end we've mitigated this by pausing the terminal's ResizeObserver during column drag and only calling fitAddon.fit() once on mouseup — so only one resize event reaches the pty/tmux chain. But the underlying issue is that Claude Code's renderer shouldn't allocate unboundedly on rapid SIGWINCH.