[BUG] Background/FleetView worker crash-loops with unhandled RangeError, prints raw respawn text into session

Description

A background session (FleetView-style, spawned via --reply-on-resume --permission-mode bypassPermissions --name "<session name>") repeatedly crashed with an unhandled RangeError and auto-respawned. The crash/respawn text was printed as literal, unstyled text directly into the session transcript (visible to the assistant and user), rather than being handled at the terminal/daemon level:

[worker crashed (exit 1 — unhandled:RangeError) — respawning…]

Resume this session with:
claude --resume "<session name>"

This repeated 5 times in quick succession within the same message, interleaved with stray terminal escape sequences (shift-tab ^[[Z, ^C), suggesting a tight crash/respawn loop rather than a single transient failure.

Environment

• Claude Code version: 2.1.217 (latest at time of filing)
• Platform: Linux 7.0.0-28-generic
• Session type: background job (bg daemon / FleetView), not a foreground interactive session

Likely root cause / related issues

This looks like the same class of bug as several previously reported and closed issues about RangeError: Invalid array length / Invalid string length when a background task or tool produces large output, which the renderer buffers fully in memory rather than truncating/streaming:

• #11355
• #11193
• #11077
• #11155

All four are now closed (mostly auto-closed as duplicates by the stale/duplicate bot), but none appear to have landed an actual fix — the crash reproduces here on a much newer version (2.1.217) than the one originally reported (2.0.36). The task running in this background session was a VPS SSH-access / security-audit investigation, which plausibly generated large log/grep output — consistent with the trigger described in the prior reports.

What's new here vs. the prior issues

• The crash is happening in a background/FleetView worker context specifically (not a foreground BashOutput call), and auto-respawns rather than terminating the CLI outright.
• The raw crash/respawn diagnostic text ([worker crashed ... — respawning…] plus a claude --resume "..." hint) leaks directly into the conversation transcript as if it were normal output, rather than being surfaced through a dedicated system-level UI element. This is confusing in a background/unattended context, since it reads like arbitrary text rather than an infra event.
• No stack trace was available to capture from within the session — only the terminal-printed crash/respawn banner above. The backend daemon log (~/.claude/daemon.log) for this job showed no corresponding crash entry, only normal claim/settle cycling, and the job's persisted state remained intact ("state": "done") after recovery — so this looks like a client-side/render-layer crash, not a data-loss issue.

Expected behavior

• Large background task output should be truncated/paginated/streamed rather than crashing the renderer.
• If a worker does crash and auto-respawn, that event should be surfaced as a distinct system/infra notice (not raw text interleaved into the transcript), and ideally include a stack trace or error ID for debugging.

Impact

Disruptive/confusing for long-running background or audit-style sessions with verbose tool output, though the underlying session state itself appears to survive the crash-loop.

🤖 Generated with Claude Code