[BUG] Frequent SIGABRT (Aborted, core dumped) at approval prompts on WSL2 — VM-wide memory exhaustion, v2.1.220

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Aug 1, 2026

Summary

Claude Code CLI dies several times per evening with Aborted (core dumped) (SIGABRT), most often while sitting at an interactive approval prompt ("This command requires approval / Do you want to proceed?"). The terminal is left in SGR mouse-tracking mode afterwards (escape-code flood as in #49017), recoverable with reset.

The crash signature matches the closed issue #30131 (sudden memory exhaustion → abort on failed allocation, triggered by TUI rendering events), but it is still occurring on the current release, v2.1.220.

Environment

  • Claude Code 2.1.220 native install (bun-compiled ELF under ~/.local/share/claude/versions/) — latest at time of filing
  • Ubuntu on WSL2 (kernel 6.6.87.2-microsoft-standard-WSL2), Windows 11 25H2
  • WSL VM: 32 GB RAM + 16 GB swap; CPU with AVX2 (so oven-sh/bun#24290 does not apply)
  • TERM=xterm-256color, no tmux/screen; ulimit -d / ulimit -v unlimited
  • Node 22.22.0 (via n) used for project tooling only

Evidence it is memory exhaustion, not just a TUI crash

In the most recent crash (2026-08-01 ~23:07 BST), the CLI aborted and a background next dev server running inside the same session crash-looped with SIGABRT ×5 within 4 seconds. WSL's crash capture wrote five node core dumps (signal 6, Out of memory strings present) to %LOCALAPPDATA%\Temp\wsl-crashes\wsl-crash-<epoch>-<pid>-..._bin_node-6.dmp.

Multiple unrelated processes aborting on allocation failure at the same instant points to VM-wide memory exhaustion — consistent with #30131's observation of the CLI ballooning from ~500 MB to many GB almost instantly. No core dump was captured for the CLI binary itself, only its node children; dumps available on request.

Frequency / reproduction

  • Several crashes per evening during normal interactive use (multiple on 2026-08-01 alone)
  • Most reliably observed when the session is waiting at a permission/approval dialog
  • CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 does not prevent the post-crash mouse escape-code flood, so mouse tracking is evidently still enabled with that flag set

Additional note

As of 2.x the npm package (@anthropic-ai/claude-code) ships the same bun-compiled binary (bin/claude.exe), so the previously suggested workaround of switching to the Node/npm build to rule out the bun runtime is no longer possible.

View original on GitHub ↗