Repository navigation
[Feature]: Prioritize Sidebar V2 threads that need review #4695
Description
Activity
I closed draft PR #4702 because opening an implementation before maintainer response got the issue-first sequence wrong. Its branch and media remain available as prototype evidence only.
After comparing the idea with current
main, the implementation can be narrowed substantially:- reorder only the active-card block; leave Snoozed and Settled classification, shelves, and ordering unchanged;
- put the cross-client classifier/comparator in
packages/client-runtime, with thin web/mobile adapters; - retain the existing separate persistence owners (web ClientSettings and mobile device-local preferences), rather than implying settings sync that does not exist;
- exclude filters ([Feature]: Add global thread filters to the Projects sidebar #1043), pins (Pin / unpin threads to keep important conversations at the top #698), backend/protocol changes, and remediation of the unread-completion bug Sidebar can miss unread Completed status for newly finished threads #3131.
One product choice still needs maintainer direction:
- Preset scope: Static creation order / Needs review first / Working first. This is the smallest cross-client settings surface.
- Full scope: Static mode plus a user-reorderable priority for Needs review / Working / Other active, as originally requested.
There is also an acknowledgement choice. “Needs review until opened” requires new mobile visit-state persistence and overlaps #3131. The smaller, lifecycle-aligned option is “Needs review until explicitly Settled,” using the existing cross-client Settle action as acknowledgement.
Would you prefer the preset or full priority scope, and should review priority clear on open or on Settle? I will wait for direction before preparing another implementation PR.
- locked and limited conversation to collaborators
on Aug 15, 2026
Before submitting
Area
apps/web
Problem or use case
Sidebar V2 currently keeps active threads in creation order even when their status changes. A thread that has just finished can remain below several agents that are still working, so the next item that needs a person's attention is easy to miss.
This affects both the desktop/web sidebar and the native mobile thread list.
Proposed solution
Add an opt-in automatic ordering mode to the existing Sidebar/Thread List V2 settings:
Keep current creation-order behavior as the default, and leave Snoozed and Settled behavior unchanged.
Why this matters
The sidebar becomes an attention queue: finished, blocked, failed, or input-waiting work appears before work that is still progressing. Users can review completed work promptly without losing the ability to choose a different group priority.
Smallest useful scope
One device-local preference for automatic ordering and one preference for the three-group priority, shared by the web/desktop Sidebar V2 and native mobile Thread List V2 implementations. No server protocol or database migration.
Alternatives considered
Risks or tradeoffs
The implementation touches both web and mobile because both clients expose Sidebar V2 independently, so the contribution is larger than a single-surface UI tweak. The behavior is nevertheless one setting contract and one ordering model. I would appreciate maintainer guidance on whether that cohesive cross-platform scope is acceptable in one PR or should be split by client.
Contribution