Claude Code CLI randomly aborts with SIGABRT on "HTTP Client" thread — reproduced across v2.1.199–2.1.205 (macOS)

Summary

Claude Code CLI process crashes sporadically during interactive sessions with SIGABRT (Abort trap: 6). The crash has an identical signature across 4 separate incidents spanning 4 versions over 4 days, including the latest version at time of reporting — updating does not resolve it.

Environment

• macOS 26.5.1 (25F80), Apple Silicon (Mac16,7)
• Terminal: Ghostty (xterm-ghostty), zsh + Oh My Zsh
• Claude Code versions affected: 2.1.199, 2.1.201, 2.1.202, 2.1.205

Crash signature (identical in all 4 macOS crash reports)

• Exception: EXC_CRASH / SIGABRT ("Abort trap: 6")
• Faulting/triggering thread name: "HTTP Client" (same name every time)
• Stack: pthread_kill ← raise ← [unsymbolized frames] — consistent with an unhandled panic (e.g. a Rust panic) inside the HTTP client component calling abort()

Occurrence log:
| Version | Timestamp (KST) |
|---|---|
| 2.1.199 | 2026-07-06 10:21:08 |
| 2.1.201 | 2026-07-06 14:00:56 |
| 2.1.202 | 2026-07-08 18:16:16 |
| 2.1.205 | 2026-07-09 15:11:02 |

Secondary symptom

After the abort, the terminal is left in xterm mouse-tracking mode (never disabled, since the process didn't get to run its cleanup path). Any subsequent mouse movement injects raw escape-sequence bytes into the shell prompt, which appear as garbage "typed" input (highlighted red by zsh-syntax-highlighting). Workaround: run reset.

Repro steps

Not deterministic — occurs sporadically during normal long-running interactive sessions. No isolated minimal repro yet. Happy to share full anonymized .ips crash reports if useful (paths are already redacted by macOS to /Users/USER/*).

Request

Given the consistent thread name across versions, could this be a known unhandled-panic path in the HTTP client (possibly around reconnects/response slicing)? Any guidance on what diagnostic info would help pin this down further.