Session hangs indefinitely in Plan mode (Haiku 4.5), never responds

Bug Report — Session hangs indefinitely in Plan mode (Haiku 4.5), never responds

Summary

A running Claude Code session ("Head-to-head typing game") stopped producing any output — no text, no tool calls — while showing an active/spinning state, and never recovered. The only way to unblock was for the user to manually relaunch the session.

Environment

• Session title: "Head-to-head typing game" (session id local_d3121e16-327c-4e2a-ab02-992df8b6283f)
• Mode at time of hang: Plan
• Model at time of hang: Haiku 4.5
• Observed via the Claude Code UI and via the list_sessions/search_session_transcripts tools from a separate concurrent session ("LLM job validation hook" — this session's own auto-generated title, as seen by the target session in delivered messages)

Timeline

1. Session was last confirmed actively working around 2026-07-05T04:52:54Z (per list_sessions lastActivityAt).
2. A cross-session status-check message was sent to it (via send_message) asking for a summary of a UI/UX review it had been asked to do on /debug/typing-tracker. The message was accepted and queued ("will be processed after the in-flight turn finishes").
3. list_sessions continued to report isRunning: true well past the point where a normal turn would complete; lastActivityAt stopped advancing.
4. search_session_transcripts for terms expected in a reply (e.g. "senior UI/UX review") only ever matched the echoed incoming question, never a reply.
5. User visually confirmed via screenshot: the message appears in the transcript labeled "From 'LLM job validation hook'", followed by an orange spinner icon with no text/tool output beneath it, and an empty, idle input box. Mode indicator showed Plan, model indicator showed Haiku 4.5.
6. No further progress occurred; user chose to relaunch the session rather than continue waiting.

Expected behavior

The session should either:

• Process the queued message and respond (even if slowly under system load), or
• Surface some visible error/timeout/retry state instead of an indefinite silent spinner.

Actual behavior

The session entered an unresponsive state — actively "thinking" (spinner shown) but producing no text or tool-call output — and stayed that way with no recovery, for the remainder of the observation window (several minutes, spanning multiple polling checks).

Suspected contributing factors (unconfirmed)

• The session was in Plan mode when it hung. Plan mode requires an explicit ExitPlanMode approval step before acting; it's possible the session was waiting on an internal state transition related to plan mode that never resolved.
• The model in use was Haiku 4.5, a smaller/faster model — unclear whether model choice is related, or coincidental (e.g. an automatic fallback/downgrade happened before the hang, which would itself be worth investigating).
• The machine was under heavy load from multiple concurrent Claude Code sessions at the time (user had explicitly asked to stop several running sessions earlier in the same window due to overload) — resource contention is a plausible but unconfirmed cause.

What's NOT confirmed

• Whether this is reproducible on demand, or a one-off.
• Whether Plan mode, Haiku 4.5, or system load (or some combination) is the actual trigger.
• Whether any error was logged internally that isn't surfaced in the UI/transcript.

Impact

Silent, indefinite hang with no error surfaced — the only signal available was external (polling isRunning/lastActivityAt from another session, and the user visually checking the UI). No way to tell, from within the session itself, that it was stuck versus genuinely still working.

Suggested next steps

• Reproduce with the same conditions (Plan mode + Haiku 4.5 + concurrent system load) to confirm the trigger.
• Add a visible timeout/stall indicator in the UI when a turn exceeds an expected duration with no incremental output.
• Check whether Plan mode has any known blocking wait-state that isn't resolved automatically when a new message is queued mid-plan.