CLI crashes with SIGABRT on `HTTP Client` thread (4x in 32h, v2.1.232 & v2.1.233)

Summary

The claude CLI binary has crashed with SIGABRT 4 times in ~32 hours on my machine, across two versions (2.1.232 and 2.1.233). All four crashes share an identical stack shape and appear to originate on the same background thread, so this looks like one reproducible bug rather than four unrelated ones.

Environment

• macOS 15.7.9 (24G830)
• MacBookPro16,1, x86-64
• Claude Code versions: 2.1.232, 2.1.233
• Running inside Terminal.app (parent process zsh)

Crash frequency

| Timestamp (local) | Version |
|---|---|
| 2026-08-14 14:31:21 | 2.1.232 |
| 2026-08-14 19:54:12 | 2.1.233 |
| 2026-08-15 16:21:56 | 2.1.233 |
| 2026-08-15 22:28:51 | 2.1.233 |

Signature (identical across all four .ips reports in ~/Library/Logs/DiagnosticReports/)

• exception: EXC_CRASH / SIGABRT ("Abort trap: 6")
• asi: libsystem_c.dylib: ["abort() called"]
• Faulting thread stack (top frames, all 4 reports): libsystem_kernel.dylib → libsystem_pthread.dylib → libsystem_c.dylib (×2) → claude (×N) — i.e. the abort originates inside the claude binary itself, not a system library.
• Two of the four reports explicitly name the crashing thread HTTP Client; the other two have an unnamed thread with the exact same stack shape, so almost certainly the same code path.
• Not memory pressure: MALLOC/heap regions are under 1GB in every report, no OOM/jetsam indicators.
• The __BUN Mach-O segment (~226MB) appears in every report's vmSummary, confirming the CLI is a Bun-compiled binary.
• 2 of the 4 crashes happened while macOS Low Power Mode was active — possibly a coincidence, possibly a trigger (network throttling/suspension mid-request is a plausible way to break an HTTP client's assumptions and cause a hard abort instead of a retry/reconnect).

Impact

Each crash silently kills the whole session — no error surfaced to the terminal, no in-app recovery. The next claude invocation just starts a brand-new session with no link back to the killed one, so context/work in flight is lost.

What I can provide

I have the four full .ips diagnostic reports (2.1.232-2026-08-14-143121.ips, 2.1.233-2026-08-14-195412.ips, 2.1.233-2026-08-15-162156.ips, 2.1.233-2026-08-15-222851.ips) and can paste/attach them on request — didn't inline them here since they're large and mostly boilerplate thread-state dumps.

Happy to provide more detail or test a fix.