[Bug] FleetView: background agent stuck in 'working' state when it enters plan mode or asks a question

[Bug] FleetView: background agent stuck in "working" state when it enters plan mode or asks a question

Summary

In FleetView (the Claude Code CLI background-agents view), when a running agent calls ExitPlanMode (plan approval) or AskUserQuestion, the job row continues to show the "working" state and never surfaces the prompt that needs my response. The job sits indefinitely without indicating that human input is required.

Expected behavior

When a background agent emits a plan for approval or asks a clarifying question, the FleetView job row should:

• Transition out of the "working" state into a "needs input" / "awaiting response" state
• Surface the plan or the question inline so I can approve / answer without opening the full session
• Ideally trigger a notification (terminal bell, system notification, or status-line indicator) so I know I'm now the bottleneck

Actual behavior

• The job row continues to show the "working" spinner / state
• There is no visible affordance to respond
• The agent is effectively idle (waiting on me) but I have no way to know that without manually opening the session

Reproduction

1. From FleetView, kick off a background task that will plausibly enter plan mode or ask a question (e.g. anything ambiguous, or anything where you've prompted the agent to plan first)
2. Wait
3. Observe that the job stays in "working" forever instead of flipping to a state that prompts me

Impact

This silently blocks long-running background work. The whole point of FleetView is to fan out work and check back later — if the UI doesn't tell me when an agent is waiting on me, I have to open every running session to find the blocked one. In practice this means I miss plan-mode prompts and questions for hours.

Environment

• Surface: FleetView (Claude Code CLI background agents view)
• Platform: macOS (Darwin 25.4.0)
• Terminal: Ghostty

Suggested fix sketch

Treat ExitPlanMode and AskUserQuestion tool calls (and any other tool that explicitly waits on a human) as state transitions in the FleetView job-list, not as continued work. The classifier that drives the job row's status should map these tools to a distinct "needs input" state with a visible CTA.