Repository navigation
Workspace shows Idle while screen detection reports a working agent #235
Description
What happens
The workspace sidebar can show Idle while the agent roster banner reports working agents and terminal tabs show activity indicators.
Observed on Windows with Claude Code running on a Linux host through SSH and tmux. In the affected workspace, wmux detect explain --surface <id> returned agent: "claude", state: "working", and ruleId: "claude.working.spinner", but the workspace label remained Idle. Two other tabs returned unknown / no-rule-matched. wmux agent-state returned empty states, blocked, and identified arrays, so there were no explicit agent-state reports.
The banner's working count is window-wide; the concrete contradiction is that a surface in this workspace was detected as working while its workspace said Idle.
Expected: workspace status should include screen-detected agent state, consistent with the roster. Missing or unmatched remote telemetry should not by itself imply that an identified agent is idle.
Steps to reproduce
- Open a terminal workspace in wmux 2.11.1 on Windows.
- Connect through SSH to a Linux tmux session and run Claude Code without agent-state hooks reporting back to the local wmux instance.
- Start a turn that displays a working spinner recognized by screen detection.
- Confirm
wmux detect explain --surface <id>reportsworking. - Compare the workspace's Idle label with the working indication in the roster/tab.
This was observed in an existing three-tab workspace; it has not been independently reproduced in a fresh profile.
wmux version
2.11.1. The same implementation is present at master commit ace738b92dd5db2a24971f781ba11f436075d3a6.
Windows version
Windows desktop; exact OS build not recorded.
Anything else
Source inspection identifies inconsistent status inputs:
- AgentRosterBanner.tsx lines 27–32 passes
agentDetectionsintorollupAgents. - WorkspaceRow.tsx lines 189–201 derives sessions from Claude activity, hooks, and declared states, without screen detections.
- workspace-status.ts lines 119–137 falls back to Idle when those inputs do not provide another status.
Suggested fix: use a shared agent-state rollup for the workspace label/dot and roster, retaining declared-state precedence and unknown-state semantics. A regression case should cover a workspace with no hook reports and one screen-detected working surface.
Related but distinct from #81: this concerns a workspace showing Idle despite an existing positive screen-detection result, rather than a running process being mistaken for active work.
Activity
fix(sidebar): include detected agents in workspace status (#235)
fix(sidebar): a silent agent must fall through, not override the row (#…
amirlehmam commentedon Sep 15, 2026
Fixed in 2.11.2, via your own PR #236 plus a follow-up on the precedence — details of that follow-up are in the PR thread, so I will keep this to the outcome.
Your diagnosis was right, and citing the three source ranges is what made it a one-session fix rather than a three-session one:
AgentRosterBanner.tsxreadrollupAgents— declared state and screen detection.WorkspaceRow.tsxread only the hook/observer-derived sessions.workspace-status.tstherefore fell through toIdle.Two components answering one question from two different sets of facts. Over ssh + tmux nothing reports hooks back to the local wmux, so the row had literally no input except the shell — which is idle, because the Claude Code TUI is not a "running command" — while the banner beside it could see the spinner. Exactly as you described it.
What shipped: the workspace row now reads the same rollup the roster does, so a screen-detected working agent puts the row on "Running…" with a green dot. Where I diverged from your patch is that the rollup's state joins the existing signals rather than outranking them — specifically so that
unknownkeeps falling through to the heuristics, per the declared-state protocol in #128:unknownmeans "an agent is here and has not said what it is doing", which is not a claim and must not displace one. Your framing of this in the issue —— is exactly right, and the corrected version holds it in both directions: unmatched telemetry implies neither idle nor anything else. It contributes nothing, and the row keeps whatever finer answer it already had.
You also asked for the regression case, and it is there: a workspace with no hook reports and one screen-detected working surface (
tests/unit/workspace-agent-status.test.ts), plus the inverse pinned as a parity — a silent agent must render byte-identically to no agent at all.You were right that this is distinct from #81. #81 is a running process mistaken for active work; this was a positive detection result that never reached the consumer. Thanks for saying so up front — it stopped me from going down the wrong path.
2.11.2 is building and will be on the releases page shortly. If the Idle label survives the update in that ssh+tmux workspace, please reopen with
wmux detect explain --surface <id>andwmux agent-stateoutput as before — that pairing is what pinned this down.