Problem

The current data model has a single running status that covers two very different states:

1. Agent is actively executing — writing code, running tests, making commits. Nothing for the user to do.
2. Agent is idle, waiting for the user — the agent has responded and is waiting for the next instruction. The user needs to continue the conversation.

Both show as running in gh agent-task list. Only needs-input (an explicit blocking question from the agent) surfaces as a distinct status.

Why it matters

With the reworked attention model (#117, #118), ATTENTION only shows needs-input and failed. This means sessions in state (2) — agent waiting for the user — show up under RUNNING with a calm 💤 badge rather than ATTENTION. The user might not realize a session is waiting on them.

Current behavior

What we'd want

If the data source could distinguish "awaiting user" from "actively executing," we'd route it to ATTENTION. Possible signals:

• gh agent-task adding a new status like awaiting-user or idle — ideal but depends on upstream
• Inferring from timestamps — if the last message was from the assistant (not user) and it's been idle, it's likely waiting. But we don't have message-level data in the list view.
• Local Copilot sessions — for local-copilot source, we could potentially parse events.jsonl to see if the last event was an assistant response

Decision

For now, this is a known limitation documented here. The ATTENTION tab is accurate for what we can detect — needs-input and failed are reliable signals. Idle running sessions get the informational 💤 badge which is the best we can do without finer-grained status data.

Action items

• Document this limitation in docs/UI_FEATURES.md under the ATTENTION tab section
• Monitor gh agent-task CLI for new status values that could help
• Consider parsing local session event logs to infer "last speaker" for local-copilot sessions