[BUG] Regression after v2.1.112: silent CLI exits on Windows, not fully fixed by NODE_OPTIONS

Update: recommended workaround stack does NOT resolve the bug on latest versions.

Second affected teammate on v2.1.114+ already had all three mitigations applied in ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_NO_FLICKER": "1",
    "NODE_OPTIONS": "--max-old-space-size=8192"
  },
  "tui": "fullscreen"
}

Still hit the regression mid-session. Failure mode this time was TUI renderer corruption — raw ANSI escape sequences dumped as literal text, forcing Ctrl+C to recover back to PowerShell (screenshot attached).

This confirms the hypothesis from the original report: at least two separate regressions after v2.1.112:

1. Memory/OOM pressure — masked by NODE_OPTIONS=--max-old-space-size=8192 for borderline cases only
2. TUI/process-layer regression — unaffected by any user-side config (tui: fullscreen, NO_FLICKER, or raised Node heap)

Only mitigation that works across all affected teammates: pin to v2.1.112 and disable the auto-updater:

npm install -g @anthropic-ai/claude-code@2.1.112
setx DISABLE_AUTOUPDATER 1

Environment for this occurrence:

• OS: Windows 11
• Terminal: Windows Terminal (PowerShell)
• Same plugin loadout as original report (skill-creator, claude-code-setup, figma, playwright, atlassian, superpowers)

Happy to provide additional diagnostic output if you can suggest what would help — Node still exits without writing any crash log.

<img width="1904" height="561" alt="Image" src="https://github.com/user-attachments/assets/6ad62f29-88c2-497c-b030-5337ba7b57c6" />

@bcherny @ThariqS @chrislloyd

Same bug, fresh receipts from the v2.1.121 → v2.1.126 era. v2.1.124 is currently the most stable target.

Filed #55424 yesterday for what is almost certainly the same bug — github-actions duplicate detector linked the two. Posting my findings here too because this issue has the regression label and dates back further (since v2.1.112), so it's the better surface for triage.

Versions tested under sustained load

Workload pattern: long-running Sonnet sub-agents (10-30+ minute runtime) dispatched via Task tool, doing dense Bash subprocess chains (50+ tool uses common). Crash counts under that workload:

• v2.1.121: ~5 silent exits in 6 hours
• v2.1.124: zero crashes in ~7+ hours since rollback (most stable)
• v2.1.126: 3 silent exits in 5 minutes — major regression on top of the pre-existing one

If you're hitting this bug today, stay on v2.1.124. v2.1.126 is significantly worse.

Diagnostic fingerprint — universal "cleanup-skipped" signature

Every silent exit observed in my testing leaves the parent PowerShell stuck in SGR mouse-tracking mode (mode 1006). Visible artifact at the bare prompt is a stream of [<row>;<col>;<button>M escape sequences — every mouse movement over the now-CC-less terminal dumps raw escape codes to stdin instead of being handled.

(env) PS <path>> [I[555;45;1M[555;51;3M[555;60;7M...

Mechanism: CC sends CSI ?1006h on session start to enable mouse reporting, but dies before sending CSI ?1006l to disable it. Cleanup handler is not running.

This artifact is not specific to any single failure mode. Every error visible on screen across two days of testing — including the silent-model-tier-downgrade bug at #54426 and other failures not separately filed — left the same artifact. That means the cleanup path is being skipped across multiple abrupt-termination causes, not just whichever specific termination this issue is about.

Implication for the maintainer: even before the root cause of the silent exit is found, wiring TTY-state cleanup to a robust atexit/signal handler (so it runs on panics, SIGKILLs, host process kills — not just on graceful exits) would eliminate the user-visible artifact across the entire bug class. Cheap defensive fix, broad benefit.

Workload correlation

Things that strongly correlate with crashes (across 8+ instances I observed in 24 hours):

1. Long-running agent sessions (10-30+ minutes runtime accumulated)
2. Sub-agents dispatched via Task tool (parent + child both vulnerable)
3. Dense Bash subprocess chains (50+ Bash tool uses common, often cd <path> && python <script>.py 2>&1 | grep ... style with bash && chaining)
4. All observed crashes were on Sonnet sessions; Opus may or may not be affected (operator workload uses Opus only as a thin dispatcher with very low tool-use rate, so I have no data either way)
5. Crash hits during the model-thinking phase that follows a Bash sequence, not during the Bash call itself — narrows failure point to the parent CC process during model interaction, not the subprocess

The OP's observation that this happens during idle, tool calls, AND long responses lines up. The common factor isn't the activity type — it's the accumulated session weight.

Re: NODE_OPTIONS workaround

I have not tested the NODE_OPTIONS workaround mentioned in the OP. Operator's Windows system runs at default Node memory limits. The pattern of crash + cleanup-skip suggests something more than memory pressure — process termination without atexit-handler execution is consistent with SIGKILL (e.g., OOM-killer or external) or unhandled native exceptions, not graceful Node-side OOM.

Filing context

This is the Auto Mode product surface — Anthropic's officially-supported autonomous-execution mode. Operator runs multi-agent workflows for autonomous overnight pipeline operation. Bug surfaces under sustained autonomous load, not under interactive use, which may be why it's been hard to reproduce in development environments.

Correction to my prior comment in this thread: v2.1.124 is NOT stable. Disregard the "stay on v2.1.124" guidance.

A fresh window opened on v2.1.124 just crashed within minutes of session start with the same ANSI mouse-tracking artifact I described. My "7+ hours stable" observation window was simply a quiet stretch — when I extended the test, v2.1.124 crashes too.

Updated honest read:

• v2.1.121: crashes (~5 in 6 hours under sustained load)
• v2.1.124: crashes (1 within minutes on a fresh window)
• v2.1.126: crashes worse (3 in 5 minutes)

This issue's framing of "silent CLI exits since v2.1.112" is consistent — the bug is older than the recent release chain and not specific to any one version in the tested range. v2.1.126 may amplify it, but no rollback target in the v2.1.112 → v2.1.126 era gets fully out of the bug under sustained autonomous load.

Also new: this latest crash hit an Opus 4.7 (1M context) max-effort session, which is the first Opus instance I've observed crash. So Opus is also vulnerable, not just Sonnet sub-agents.

The defensive TTY-cleanup-on-all-exit-paths recommendation in my prior comment still stands — it's the broadest-benefit fix even before the silent-exit root cause is found.

One more useful triage data point: bug exists across runtimes (Bun AND Node).

Operator who's been hitting this on Node v2.1.121-126 was previously on Bun and experienced silent CLI exits with the same shape — that's what caused the switch to Node in the first place. Same Windows host, same workload class, different runtime. Bug followed her across the runtime swap.

Implication for triage: the bug is almost certainly NOT in the JS runtime layer. Rules out Node-specific theories (heap GC, V8 internals, NODE_OPTIONS-tunable memory limits) — Bun has different GC, different memory model, different event-loop, and still produced the same silent exit. Failure surface is in shared code: the native binary (claude-code-win32-x64/claude.exe), TTY-state handling, child-process management, Windows console-host interaction, or signal-handler wiring — all of which are runtime-agnostic.

The OP's note that NODE_OPTIONS workaround "didn't fully fix" lines up with this — if the bug isn't in Node's heap path, no Node-side option is going to fully resolve it.

Cross-runtime stability would be a useful regression-test target if it isn't already in the test matrix.

Great analysis @ThatDragonOverThere !

I hope the team looks into this soon. Thanks! @chrislloyd @ThariqS @bcherny

Thanks for reporting. can i ask for a crash dump?

First enable Windows Error Reporting LocalDumps:

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\claude.exe" /v DumpFolder /t REG_EXPAND_SZ /d %LOCALAPPDATA%\CrashDumps /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\claude.exe" /v DumpType /t REG_DWORD /d 2 /f

Then attach the .dmp from %LOCALAPPDATA%\CrashDumps.

Closing for now — we still need a bit more information to move forward. Please open a new issue if this is still relevant.

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.