Random crash: 'No matching component was found' in Ink component tree

Bug Description

Random crashes occur during long-running sessions with the error "No matching component was found for:" followed by a minified stack trace from the Ink (React terminal UI) rendering layer. The crash terminates the session entirely.

Error Output

`+(g.join(" > ")+`

No matching component was found for:

 - n9 (/$bunfs/root/claude:685:20565)
 - ZP (/$bunfs/root/claude:685:29777)
 - <anonymous> (/$bunfs/root/claude:191:8939)
 - wE$ (/$bunfs/root/claude:7325:8047)
 - R9H (/$bunfs/root/claude:7338:10320)
 - L9 (/$bunfs/root/claude:685:20775)
 - z4 (/$bunfs/root/claude:685:39175)
 - yy (/$bunfs/root/claude:685:49797)
 - cy (/$bunfs/root/claude:685:86054)
 - Re (/$bunfs/root/claude:685:85028)

Steps to Reproduce

1. Start a Claude Code session with cloud-based coding (e.g., using iTrend2 cloud coder)
2. Perform encoding/processing work that generates heavy concurrent output
3. The crash occurs randomly — no specific reproducible trigger identified yet

Expected Behavior

The session should remain stable during heavy output and concurrent tool execution.

Actual Behavior

The session crashes with "No matching component was found" error. The /$bunfs/root/claude paths indicate this is in the bundled Bun binary, and the minified function names (n9, ZP, wE$, R9H, L9, z4, yy, cy, Re) point to the Ink component rendering layer.

Analysis

This appears to be a race condition in the Ink component tree where a component is expected during a render cycle but cannot be resolved. Possible triggers:

• Heavy concurrent output overlapping with tool responses
• Rapid state transitions in the UI during tool call completion
• Terminal signal handling during a render cycle
• Memory pressure during long-running sessions with large context

Environment

• Platform: macOS (Darwin 22.6.0)
• Runtime: Bun (bundled /$bunfs/root/claude)
• Occurrence: Random/intermittent during extended sessions