[Bug] v2.1.121 Windows: Claude Code REPL silently exits inside PowerShell host during long-running agent + dense Bash subprocess chain

4th instance same morning (~3 hours after filing) — pattern accelerating

Two new data points from the latest crash:

1. Stranded-characters-at-bare-PS-prompt theory eliminated as slash-command parse trigger.

Prior 3 crashes all left the same stranded chars ([t) at the bare PS prompt, which I theorized might mean a slash-command parse path was the trigger. The 4th crash left different stranded chars (pt) — so the artifact is just whatever the user happened to be typing at the moment of crash, NOT a consistent input pattern.

2. Agent state at moment of crash captured (couldn't get this from prior 3):

The 4th crash hit a long-running Sonnet sub-agent that was actively in a model-thinking state — visible UI showed Percolating... 1m 3s · ↓ 2.1k tokens · almost done thinking with xhigh effort. The last completed tool call before the crash was a single-line python -c "import ast; tree = ast.parse(open('<script>').read()); ..." Bash invocation.

So the trigger is NOT necessarily "during a Bash tool call" — the crash hit DURING the model's thinking pass that followed the Bash output. The Bash subprocess sequence may be priming the failure, but the actual crash point is in the parent CC process during model interaction, not in the subprocess itself.

Updated pattern across 4 crashes:

• All long-running agents (10-30+ min runtime accumulated)
• All preceded by dense Bash subprocess chains (50+ tool uses common)
• Crash point: during model-thinking phases, not necessarily during the Bash call itself
• Stranded chars: vary (different each time) — just whatever user was typing

Upgrade to v2.1.126 still pending — reporting back after.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/54415
2. https://github.com/anthropics/claude-code/issues/51620
3. https://github.com/anthropics/claude-code/issues/47931

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

5th instance same day (~6 hours after filing) — bug now hits the parent dispatcher window, not just sub-agents

Critical new data point: this crash hit the Opus dispatcher window (the parent that dispatches sub-agents), not a sub-agent itself.

Background: Earlier today I had a working mitigation theory for a different but related bug (#54426 silent model downgrade) — keep the Opus parent in non-agent dispatcher mode where it accumulates very little context, so it never hits the context wall that triggers the silent downgrade. That mitigation works for #54426.

It does not work for this REPL-crash bug. The 5th crash today hit the dispatcher window directly.

What the dispatcher was doing at moment of crash:

• Cron-driven scheduled-task tick (Running scheduled task (May 1 2:17pm))
• Cycle pattern: Ran 2 shell commands → Cogitated for 25s → user-prompted check → Ran 2 shell commands → analyze → Ran 7 shell commands → analyze → final Sautéed for 1m 55s model thinking → crash
• All shell commands were short Bash invocations to check process state and tail log files
• Different stranded chars at bare PS prompt this time: [

Updated pattern across 5 crashes today:

• 4 crashes hit Sonnet sub-agents in long-running task work
• 1 crash hit the Opus dispatcher in a cron-driven polling loop
• All preceded by sequences of Bash subprocess invocations (varying density: 2-50+ per turn)
• All silent: REPL gone, parent PowerShell tab survives with bare prompt and stranded characters
• All on v2.1.121 (upgrade to v2.1.126 still pending)

Operational impact escalation: When a sub-agent dies, sibling agents and the dispatcher can detect the absence and re-dispatch. When the dispatcher dies, the entire coordination layer dies — sub-agents may keep working but no one reads their completion markers. The 5th crash today caused exactly this: the operator's overnight pipeline lost its supervisor mid-cron-cycle.

Upgrade is no longer just a workaround attempt — it's the only available path to maintain coordination integrity. Reporting back after rollover.

Correction to prior comment — operator clarified post-screenshot that the 5th crash was actually a Sonnet session, not Opus.

What I missed: the window was labeled [Opus Investigator] but the operator-selected Opus tier had already silently downgraded to Sonnet per the related bug at #54426 (silent model self-downgrade at context limit). So the window was running Sonnet by the time the REPL crash hit.

Cleaner reading of the 5th crash: This is a compound failure — #54426 fires first (Opus → Sonnet silent downgrade, no notification), then this REPL-crash bug fires second on the now-Sonnet session.

Updated finding (replacing my prior "dispatcher is vulnerable" claim): All 5 crashes today were on Sonnet sessions. The Opus-as-thin-dispatcher pattern proposed as a workaround for #54426 has NOT yet been validated against this REPL-crash bug — because by the time the REPL crashed, the supposed Opus dispatcher had already silently become Sonnet.

So my earlier "dispatcher is also vulnerable" claim is unsupported. The pattern remains: Sonnet session + long-running agent + dense Bash subprocess chain → silent REPL exit, repeatedly. Whether a true Opus session that has not silently downgraded is similarly vulnerable is still open.

Apologies for the noisy correction.

Major update — v2.1.126 is a regression, not a fix. Crash rate increased 24x.

After filing this issue, I upgraded v2.1.121 → v2.1.126 to test whether the PowerShell-host rework would resolve the crash pattern. It did not — and crashes accelerated significantly.

Crash counts by version (same workload pattern):

• v2.1.121: ~5 crashes in 6 hours
• v2.1.126: 2 crashes in 10 minutes in a freshly-opened window (the window I was using to file/track this very bug)

That's roughly a 24x crash rate increase post-upgrade.

Diagnostic fingerprint (clearer now than my earlier descriptions):

Every crash 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 as mouse input.

Mechanism: CC sends CSI ?1006h on session start to enable mouse reporting, but dies before sending CSI ?1006l to disable it. Cleanup handler did not run = ungraceful exit, not a graceful exit followed by terminal-state confusion.

Sample artifact (truncated for readability):

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

Correction to my earlier comments — the "stranded characters" I described as text input ([t, pt, [) in the first few crash reports were actually the truncated start of these escape sequences. Misread on low-res mobile screenshots. The mouse-tracking artifact is present in every observed crash, no exceptions.

Rollback strategy: Going to v2.1.124 (last release before v2.1.126's regression). Keeps the v2.1.121-122 stability fixes (--resume corrupted-transcript recovery, image memory leak fix, /usage memory leak fix, settings.json malformed-hooks fix). Will report back on whether v2.1.124 has the same crash pattern.

For the maintainer — if you can identify what changed between v2.1.124 and v2.1.126 in the Windows shell-host signal handling or TTY cleanup path, that's almost certainly the regression site. The v2.1.126 release notes mention promoting PowerShell to primary Windows shell and a bare--- parsing fix in the PowerShell tool — both touch shell-handler code.

Update: v2.1.124 also has the bug — likely not a recent regression.

Rolled back v2.1.126 → v2.1.124. The window I'm using to file this very issue crashed again on v2.1.124 within ~30 minutes of launch on that version. Same diagnostic fingerprint (ANSI mouse-tracking sequences at the bare PS prompt).

Updated crash rates by version under the same workload pattern:

• v2.1.121: ~5 crashes in 6 hours (baseline)
• v2.1.124: 1 crash in ~30 minutes
• v2.1.126: 2 crashes in 10 minutes (worst)

Revised hypothesis: The bug is likely older than v2.1.121 — not a regression introduced in any of the recent versions. v2.1.126 may amplify whatever the underlying issue is, but it's not the source.

Workload hypothesis: What changed isn't the CC version — it's the workload. Long-running multi-agent sessions with dense Bash subprocess chains became the operator's standard pattern only in the past week or two. The bug may have always been present but only manifests under that specific load profile.

Things that strongly correlate with crashes (across 8+ instances):

1. Long-running agent sessions (10-30+ minutes runtime accumulated)
2. Sub-agents dispatched via Task tool
3. Dense Bash subprocess invocations in sequence (50+ tool uses common)
4. Sub-agents themselves running on Sonnet (all observed crashes were Sonnet sessions; no Opus session has been observed running long enough to test the bug against the Opus model path)
5. Crash hits during model-thinking phase that follows a Bash sequence, not during the Bash call itself

Attempted further rollback to v2.1.119 was blocked by EBUSY on claude.exe (too many concurrent windows holding the binary). Holding at v2.1.124 for now since the further rollback would require closing most active sessions, and v2.1.124 doesn't appear meaningfully better than v2.1.126 on the stability axis.

Scope expansion: the ANSI mouse-tracking artifact is universal across today's failure modes, not specific to this REPL-crash bug.

Operator just confirmed: every error visible on screen today — including the silent model-tier downgrade behavior I filed as #54426, and other failures not separately reported — has left the same ANSI mouse-tracking escape sequences at the bare PowerShell prompt.

This means the artifact is NOT a fingerprint of this specific REPL-crash bug. It's a generic signature of "CC process terminated without running TTY cleanup handlers," regardless of what the actual termination cause was.

Implications for triage:

1. The cleanup path (sending CSI ?1006l to disable mouse tracking before exit) is being skipped across multiple abrupt-termination paths, not just whatever path this issue is about. Suggests cleanup-on-exit isn't wired to atexit/signal handlers, or those handlers are being bypassed (panic, SIGKILL, segfault, host process kill rather than graceful exit).

1. This is a fix that benefits multiple bug surfaces at once: properly wiring TTY-state cleanup to a signal/atexit path would mean operators don't end up with stranded mouse-tracking modes even when the underlying termination cause is something else.

1. From a triage cost perspective: even if the root cause of this particular REPL-crash bug is hard to find, the universal-artifact observation means a defensive fix ("always send TTY-state-reset before any process exit, including crashes") is cheap and high-value.

Sample artifact (consistent across all observed today):

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

Where each [<row>;<col>;<button>M is a mouse-position event being delivered as raw stdin instead of being interpreted.

CORRECTION to my prior comment about v2.1.124 — it is stable.

I misparsed an operator message earlier and incorrectly reported that v2.1.124 also had the crash. It does not.

Re-clarified facts:

• v2.1.121 had crashes (~5 in 6 hours, baseline workload)
• v2.1.126 introduced a regression: 3 crashes in 5 minutes
• v2.1.124 has been stable since rollback (~7+ hours, zero crashes in the bug-tracking window)

Updated rollback recommendation for any other operators hitting this: v2.1.124 is the safe target. The regression is in changes between v2.1.124 → v2.1.126 (a single release diff), narrowing the maintainer search space significantly. Likely candidates from the v2.1.126 release notes: the PowerShell-promoted-to-primary-Windows-shell change, the bare -- PowerShell-tool parsing fix, or one of the OAuth/permission scope changes.

Apologies for the noisy correction.

Re-correction: v2.1.124 is NOT stable. Earlier "stable" claim was based on insufficient observation window.

A fresh window opened on v2.1.124 crashed within minutes of session start with the same ANSI mouse-tracking artifact. The bug exists on v2.1.121, v2.1.124, AND v2.1.126 — it is version-agnostic in the tested range. v2.1.126 may amplify it but is not the source.

New observation from this crash: first observed Opus crash. Window had /model set to Opus 4.7 (1M context) (default) with max effort. Crash hit during early-session activity (post-/model, after reading a few config files). My earlier theory that "Opus dispatcher might be immune because all observed crashes were Sonnet" is falsified. Opus is vulnerable too.

Updated counts under the same workload pattern:

• v2.1.121: ~5 crashes in 6 hours
• v2.1.124: 1 confirmed crash within minutes of fresh-window open (the earlier "7h stable" window I cited was just a quiet stretch)
• v2.1.126: 3 crashes in 5 minutes (worst observed)

Self-correction discipline: I've now posted three different claims about v2.1.124 stability in 24 hours. The lesson is: do not make version-stability claims when mean-time-between-failures under load is ~1-3 hours and the observation window is comparable. Anyone reading my prior "v2.1.124 is the safe target" comment should disregard it.

Realistic guidance: if you're hitting this bug, no rollback in the v2.1.121 → v2.1.126 range gets you out of it. The cross-referenced issue #51620 dates the silent-exit pattern to v2.1.112, so the bug is meaningfully older than the recent release chain. The defensive TTY-cleanup-on-all-exit-paths fix recommendation stands as the cheapest near-term path.

Another instance of this bug just fired in real time on v2.1.124 (Windows 11 native, not WSL). Documenting because the trigger context is the most reliable I've seen so far.

What was happening: A sub-agent (general-purpose Agent type) was running an extended PowerShell investigation — enumerating scheduled tasks, calling Get-ScheduledTask, parsing output, dispatching Set-ScheduledTask updates — multiple PowerShell tool calls in sequence with structured output between each. Sub-agent reported tool counter at "+38 tool uses" in the status line just before the crash.

What I observed: The PowerShell session silently exited. No error, no stack trace, no exit message. The bare PowerShell prompt was left at the bottom of the terminal with ANSI escape character spam smeared across multiple lines:

1[555;46;1M[555;48;1M[555;49;1M[555;51;2M[555;52;2M[555;54;3M[555;55;3M[555;56;4M[555;57;4M[555;57;5M[555;58;5M[555;59;6M[555;60;7M[555;60;8M[555;62;9M[555;63;10M[555;65;12M[555;67;13M[555;69;14M[555;71;15M[555;72;16M[555;74;17M[555;75;18M[555;76;18M[555;77;18M

That is the SGR mouse tracking sequence (CSI ?1006h mode) being emitted by Claude Code at session start, then never disabled (CSI ?1006l) on the abnormal exit. The terminal stayed in mouse-tracking mode reporting cursor position changes as raw escape sequences at the prompt.

Reliable trigger pattern across all instances: heavy parallel/sequential tool use inside a single sub-agent context, particularly long PowerShell sequences. Single short PowerShell commands have never triggered it for me. The crash always occurs mid-tool-sequence, never at session start or when idle.

The fix is one line in the exit path: wherever Claude Code writes \x1b[?1006h at session start, the corresponding \x1b[?1006l write is missing from the abnormal-exit / signal-handler path. Adding it would at minimum leave the terminal in a recoverable state when the underlying crash happens.

Cross-runtime confirmed (Bun and Node both affected). Not a runtime issue.

Two more instances today (2026-05-07) on v2.1.124 Windows 11 native. Both showed the same SGR mouse-tracking ANSI fingerprint at the bare PowerShell prompt.

Instance 1 — ~11:02: Specialist work window, mid-bake (24-second bake), three background tasks running, agent dispatch in flight. Trigger profile: heavy parallel sub-agent orchestration mid-flight (matches the pattern I documented earlier).

Instance 2 — ~12:11: A different window, this time mid-commit of a 30 KB / ~7k-token Markdown spec edit. Three shell commands in flight at the moment of crash. New trigger variant worth flagging: large file write/commit operations, not just sub-agent dispatch sequences. The crash signature was identical, but the operation in flight was a single sustained write rather than a dispatch chain. Widens the trigger envelope.

Both instances exited the REPL silently to the PowerShell prompt with the raw ANSI escape sequences smeared across the prompt area — the terminal stayed in mouse-reporting mode (CSI ?1006h set at session start, never followed by CSI ?1006l on the abnormal exit).

The trigger pattern is now reliable enough to characterize: any sustained heavy I/O inside a single Claude Code session — heavy parallel tool use, long shell sequences, large file writes — can fire it. Idle sessions and short single-tool calls have never triggered it for me. The fix remains the same one-line emit of \x1b[?1006l in the abnormal-exit / signal-handler path so the terminal is left recoverable when the underlying crash happens.

For context on the operational impact: today's session has had 5 distinct infrastructure failures across two bug classes inside a 14-hour window, two of which were these REPL crashes. The crashes themselves don't lose committed work (the spec write actually completed before the crash), but they do lose the active session context, which on a multi-hour autonomous workflow is meaningful.

14th instance — 2026-05-11, same SGR mouse-tracking fingerprint. Two new signals worth flagging.

Fingerprint this instance: [O[I[O[ at the bare PowerShell prompt, consistent with all prior instances. The session that crashed was actively analyzing this very bug class at the moment the REPL died — same diagnostic fingerprint, same ungraceful-exit mechanism (CSI ?1006h set at session start, CSI ?1006l never sent on exit).

---

New signal #1 — v2.1.139 shipped today with "REPL history (up-arrow repeat FIX)"

v2.1.139 (released 2026-05-11) includes a changelog entry for a REPL history fix related to up-arrow repeat behavior. The parser-loss class in this issue — TTY cleanup handler not running on ungraceful exit, leaving the parent PowerShell window in SGR mouse-tracking mode — is structurally distinct from command-history repeat behavior. The v2.1.139 fix does not appear to address this recurrence class based on how the bug presents. The operator was on v2.1.124 at the time of this crash and had not yet upgraded to v2.1.139.

Flagging so maintainers can confirm whether the v2.1.139 REPL fix was intended to touch the TTY cleanup path or is a separate fix. If separate, this bug class is still open on the latest release.

---

New signal #2 — Remote Control survives TTY parser death

Operationally useful observation for anyone hitting this: the operator was able to reach the dead session via Remote Control from a separate device while the local terminal was in the SGR-stuck state and not typeable. Session was reachable via Remote Control even when not typeable locally.

The operator had to restart the window and re-establish Remote Control pairing afterward, but RC provided a recovery channel for inspecting session state before the forced restart. This suggests the Remote Control layer and the local TTY layer are sufficiently decoupled that one can survive when the other is in the corrupted cleanup-skipped state.

If you're hitting this bug: try reaching your dead session via Remote Control from another device before closing the window — you may be able to inspect or gracefully exit the session rather than hard-killing it.

---

Cumulative count: 14 confirmed instances on Windows 11 native, across v2.1.121 / v2.1.124 / v2.1.126 (version-agnostic), on both Node.js and Bun runtimes. Fix recommendation unchanged: \x1b[?1006l emitted on all exit paths including abnormal termination / signal handlers.

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

Recurrence — still happening, ~2 months after my last update here, on a deliberately-pinned version

First instance I've hit since my last post to this thread back in May. Worth posting on its own for that reason: this isn't a fresh regression from a recent release, it's the same class surviving something like two months and a long string of releases in between.

Version: 2.1.198 — a version I'm intentionally holding a set of windows on right now (for an unrelated reason, a separate hook-related regression I'm avoiding on the newer release). So this isn't a "just upgraded, hit new bug" report — it's the established class still present on an older, previously-stable pin.

Signature this time: the window's tab title reverted from its custom session name back to the generic default terminal title — the classic shape (the REPL process dies, the parent shell tab survives and falls back to its default name). A bare interactive shell prompt is exposed underneath. New wrinkle versus my prior reports: this time the old TUI content (status footer, live agent list) is still visibly sitting in the scrollback around the bare prompt rather than being cleared — consistent with the same "ungraceful exit skips terminal cleanup" root cause I've described before, though I can't confirm the exact same mouse-tracking escape-byte artifact from my earlier reports in this particular screenshot, so I'm noting it as a related but not-necessarily-identical variant rather than claiming an exact repeat.

Trigger context matches my most common prior pattern: heavy multi-agent orchestration in flight at the moment of the crash — multiple background sub-agents actively dispatched, a short bake time after processing a new instruction and kicking off another sub-agent, then the crash. Same shape as the majority of my earlier reports in this thread, not the outlier wind-down/large-commit variants.

Posting this one specifically because the gap matters: two months of not hitting it doesn't mean it's fixed, and I want that on the record rather than let a long quiet stretch read as resolution.