claude-code - 💡(How to fix) Fix Agents view: live background bash falsely pins agent to "Working" after turn completes

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

The new agents view in the Claude Code TUI infers an agent's status from whether it has live background bash processes, not from whether the agent itself is mid-turn. When an agent finishes its work but leaves a long-lived subprocess running (a dev server, a tail -f log watcher, a polling loop), the view continues to show the agent as Working indefinitely, even though no model turns are in flight and no tool calls are pending.

Root Cause

The signals are orthogonal:

  • Is the agent currently processing? — has a pending model turn or tool call.
  • Are subprocesses the agent started still alive? — independent; useful for the human, but not a measure of agent activity.

Conflating them makes the Working badge untrustworthy. Any agent that leaves a dev server or log tail running looks busy forever, which defeats the purpose of the view (telling at a glance which agents need attention vs. are done).

RAW_BUFFERClick to expand / collapse

Summary

The new agents view in the Claude Code TUI infers an agent's status from whether it has live background bash processes, not from whether the agent itself is mid-turn. When an agent finishes its work but leaves a long-lived subprocess running (a dev server, a tail -f log watcher, a polling loop), the view continues to show the agent as Working indefinitely, even though no model turns are in flight and no tool calls are pending.

Environment

  • Claude Code: 2.1.139
  • OS: Linux (Ubuntu 6.17.0, cloud devcontainer)
  • Surface: TUI agents view

Reproduction

  1. From a session, spawn an Agent (or use a background job) whose task instructs it to start a dev server in the background via Bash(run_in_background: true) — e.g. just agent-dev / next dev / python -m http.server — and then finish reporting.
  2. The agent emits its final result: line and stops processing turns.
  3. The background bash (dev server) remains alive, by design — the human still wants it running.
  4. Open the agents view.

Observed: the agent shows as Working for as long as the subprocess is alive — potentially hours.

Expected: the agent shows as Done / Idle / Waiting once it has stopped processing turns. Live background subprocesses are a separate concern (visible as background bash tasks, not as agent activity).

Why this matters

The signals are orthogonal:

  • Is the agent currently processing? — has a pending model turn or tool call.
  • Are subprocesses the agent started still alive? — independent; useful for the human, but not a measure of agent activity.

Conflating them makes the Working badge untrustworthy. Any agent that leaves a dev server or log tail running looks busy forever, which defeats the purpose of the view (telling at a glance which agents need attention vs. are done).

Related, but not the same

  • #48312 — Tasks sidebar: completed background bash stays "Running" after the process exits. Inverse case: there the process is dead and the UI still says Running. Here the process is alive and the UI infers agent activity from it.
  • #54626 (symptom 2) — same inverse shape as #48312.
  • #21894 — general feature request for visual state indicators (Working/Done/Waiting/Idle). Conceptually relevant; this issue is the concrete bug under that umbrella for the agents view.

Suggested fix

The agents view's status should be driven by agent-turn lifecycle (has a pending model call, has a pending tool call, last turn completed) — not by pgrep of subprocesses spawned by the session. Live background bash entries already have their own surface; let them stay there and stop coloring the agent badge.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING