Triage the project rail: priority ranking, waiting-on-you colors, and notifications that repeat until you answer

[samithaj]

Problem

With many coding agents running at once, the rail treats every task identically: an agent blocked on a permission prompt in a critical project looks exactly like a scratch project idling for a week. Two things are missing — a way to say which projects matter, and a way to be told, insistently, when an agent is waiting on you.

Two concrete bugs make this worse today:

1. The project header cannot show Blocked for a plain CLI-agent pane. tab_conversation_status (app/src/workspace/view.rs) checks is_long_running() before consulting the agent's own status — but a claude sitting on a permission prompt is a long-running command, so Blocked is shadowed by InProgress and never reaches the header. Only orchestrated child conversations get through. The header's own doc comment says "a task that needs the user … wins over merely working", which the ordering silently defeats.
2. CLIAgentSessionStatus::Blocked carries no timestamp, so nothing can distinguish "just asked" from "waiting 20 minutes".

Also: sessions detected by command-line matching (no plugin listener) render no status badge at all (agent_icon.rs), so a plugin-less agent is visually identical to a plain shell.

Proposal

• Priority ranking. An ordered list of projects, managed from the project row's context menu, persisted keyed on a canonical ProjectKey string so all worktrees of a repo share one rank. Exposed as rank_of() — deliberately a readable attribute, not just a sort key, so per-project agent token budgets can consume it later.
• Colour, not reordering. Rows tint yellow while an agent waits on you, deepening to red past 5 minutes, and green for a finished run whose result hasn't been looked at ("seen" = the pane was focused while Success). Projects never move in response to agent events — spatial memory is what makes a sidebar fast. Header inherits its most urgent child. Precedence is a derived Ord over an urgency enum, so adding a state is placing it in a list rather than editing a comparison chain.
• Nag until unblocked. Ranked projects announce immediately and repeat every 3 minutes; unranked ones debounce 60s (most prompts are answered in seconds and should never make a sound) then repeat every 15. Looking at the pane silences the cycle; looking away while still blocked re-arms after a grace period. Only the agent leaving Blocked stops it for good. Announcements coalesce into one banner. When Warp is frontmost the banner is suppressed but the bell still rings for waiters in other tabs.

Cleanup is structural rather than a call site: poll() receives the complete set of currently-blocked tasks, and anything absent is dropped — so unblocked, killed, pane-closed and window-gone all collapse to "not observed", and a dead session can never nag forever.

Implementation (fork, flag-gated behind the existing FeatureFlag::Projects / ResumeProjectTasks): https://github.com/samithaj/warp/tree/samithaj/rail-triage — built on #14720.

Note on the sound API

Warp exposes only a play_sound: bool riding on a notification, plus AudibleBell::ring(). There is no way to distinguish an urgent "needs approval" sound from a soft "done" chime, which is the convention the Claude Code hook ecosystem has converged on. Worth considering separately.

[oz-for-oss]

@samithaj

Here's what I found while triaging this issue:

• The report maps to real current status-model gaps: blocked CLI-agent state does not retain a timestamp, and blocked state can be masked as in-progress in tab chrome.
• The priority ranking, urgency colors, and repeating reminders are broader product enhancements that likely need product/design review before implementation.

Maintainer details

I concluded that project rail request to prioritize agent work, surface waiting-on-you urgency, and repeat attention notifications, with current client code supporting some of the reported status-model gaps..

Triage summary

This is best treated as a product enhancement for the project/agent rail, with a few supporting client-side defects that make the current experience harder to scan. The requested work spans project priority persistence, rail row/header urgency presentation, and a recurring notification/reminder loop for blocked agents.

Evidence from code inspection

• app/src/terminal/cli_agent_sessions/mod.rs defines CLIAgentSessionStatus::Blocked with only an optional message, so the current CLI-agent status model cannot distinguish newly blocked sessions from sessions blocked for several minutes.
• app/src/terminal/view/pane_impl.rs derives selected conversation status by returning InProgress while the terminal is long-running before falling through to conversation/orchestration status, which can mask a blocked status in tab chrome.
• app/src/ai/agent_management/agent_management_model.rs creates request notifications on blocked status changes, while app/src/ai/agent_management/notifications/item.rs de-duplicates one notification per origin and stores only notification creation time; there is no currently blocked task set or repeating reminder scheduler in this path.
• app/src/projects.rs persists projects by path and timestamp only; it does not currently store a canonical project key or priority/rank metadata.
• app/src/workspace/view/vertical_tabs.rs already supports row background tinting through pane/tab color state, but not derived waiting-on-you urgency colors.
• app/src/ui_components/agent_icon.rs currently returns a CLI-agent icon for command-detected sessions with no rich status, so the current code supports the weaker finding that command-detected sessions lack a status overlay rather than no agent icon at all.

Duplicate check

I scanned all open issues and recent closed issues. The closest adjacent issues are #13895 (scriptable tab title/status/color API), #12329 (SSH/tmux CLI-agent notification reliability), #9868 (missing vertical-tabs summary status icons), and #9888 (long-running shell startup leaking In progress into vertical tabs). Those overlap individual slices but do not duplicate this combined project-rail priority, urgency, and recurring waiting-on-you notification request, so I am not marking this as a duplicate.

Recommended next step

This likely needs product/design review or a spec before implementation because the desired ranking model, urgency colors, repeated notification cadence, and frontmost-window behavior are cross-surface UX decisions rather than a narrow defect fix.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz