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

Status Fixed / completed

Maintainer reply ✓ Yes — bogini

Activity 7 comments · opened May 15, 2026 · closed May 27, 2026

💡 Likely answer: A maintainer (bogini, collaborator) responded on this thread — see the highlighted reply below.

[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

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)
Wait
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.

View original on GitHub ↗

7 Comments

github-actions[bot] · 3 months ago

Found 2 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

kcarriedo · 3 months ago

This failure mode is one of the cleanest examples I've seen of why a fan-out background runner needs to surface "agent is waiting on a human" as a first-class state distinct from "agent is working" — they look identical from the parent's perspective (no new tool calls, no stdout) but mean opposite things operationally.

I've been running into the same shape from a different angle: a Rust scheduler that wakes Claude Code subprocesses on a cron, captures their stdout/stderr, and persists per-agent state to disk between fires. The two states I had to model explicitly to keep the cycle loop honest were:

working — last tool-call timestamp within N seconds, expect more activity.
awaiting_human — process is alive, last event was a plan-mode prompt or permission_required JSON event, no progress until input arrives.

Until I split those, the supervisor's "is this cycle making progress?" heuristic kept misclassifying plan-mode-blocked agents as healthy, which is exactly the FleetView failure you're describing, just at a different layer of the stack. The signal I ended up using to disambiguate (without polling each session manually) was a combination of the tool_use / tool_result event stream from --output-format stream-json and a heartbeat the agent itself writes when entering plan mode — the absence of either inside a window means "stuck on me."

If you can get the FleetView background-agent runtime to emit a structured state_change event when plan mode or a permission gate fires, the UI surface gets cheap — a coloured dot per agent, plus a single aggregated "N agents waiting on you" counter at the top of FleetView. The harder version (which I think is what you actually want) is solving the inversion: the user shouldn't need to look at FleetView at all — the agent that needs input should reach out (push notification, terminal bell, OS notification, anything).

Happy to share the event-classification rules I'm using if it'd be useful — they're imperfect but they at least keep the supervisor from declaring success on a blocked agent.

alak · 3 months ago

I do observe the same issue, also when entering in fleet mode, the flower logo is not animated even if the agent is working.

alak · 3 months ago

Looks fixed, I will do more test

Keesan12 · 3 months ago

+1. I would model this as a state-machine bug, not a rendering bug.

working should only mean the agent can make forward progress without a human. The moment it emits ExitPlanMode, AskUserQuestion, or a permission gate, FleetView should transition to a first-class awaiting_input state with the blocking artifact attached.

If that state also carries since, input_kind, and root_session_id, you get observability and notification routing for free instead of teaching each UI path to infer stuckness.

bogini collaborator · 3 months ago

Addressed by a merged fix. Please reopen with a fresh repro if you still see this on a current version.

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.