Problem
When several sessions belong to the same case or workspace, the dashboard still presents them as individual entries in a flat tab strip / vertical rail. Related sessions can be separated by sessions from other projects, making navigation difficult as the session count grows. Filtering past conversations by case does not organize the live session tabs.
Existing foundation
PR #335 added the owner-scoped tab-layout model, persistence, and GET/PUT /api/tab-layout, but explicitly excluded browser layout rendering. The current source includes named groups; the frontend does not consume this API. On a running installation, GET /api/tab-layout returned HTTP 200 with groups: [] while the rail displayed a flat list and the Session actions menu offered only Session options and Close session.
This request is for the user-facing grouping experience and case/workspace placement, building on that foundation rather than introducing a second layout model.
Suggested behavior
- Offer an opt-in grouping mode: By case, By workspace, or the existing Flat view. Sessions from different CLI backends should still share a group when they belong to the same case/workspace.
- Automatically place newly created or resumed sessions into the matching group. For workspace grouping, use the actual workspace identity (location/host and full path), not only the folder basename; unrelated directories with the same name must remain separate.
- Render named, collapsible groups in the session rail and provide equivalent navigation in the horizontal/mobile layout, with a visible session count.
- Allow manual named groups and moving a session between groups, including grouping related cases/worktrees together. Automatic placement should not silently overwrite an explicit manual choice.
- Persist membership and ordering through reloads and server restarts, retain the existing owner isolation, and avoid changing session execution or closing sessions when a group is removed.
Acceptance examples
- Three sessions in case A and two in case B appear under their respective groups, even if launched in interleaved order.
- A new/resumed session in case A joins A without manual reordering.
- A collapsed group and its session placement remain usable after a page reload; stored membership/order survive a server restart.
- Two workspaces with the same basename on different paths or hosts are not merged accidentally.
- Removing a group leaves its sessions running and accessible in the ungrouped list.
Is a frontend follow-up to #335 already planned? If so, please link it; otherwise, could this track case/workspace-based session grouping?
Problem
When several sessions belong to the same case or workspace, the dashboard still presents them as individual entries in a flat tab strip / vertical rail. Related sessions can be separated by sessions from other projects, making navigation difficult as the session count grows. Filtering past conversations by case does not organize the live session tabs.
Existing foundation
PR #335 added the owner-scoped tab-layout model, persistence, and GET/PUT /api/tab-layout, but explicitly excluded browser layout rendering. The current source includes named groups; the frontend does not consume this API. On a running installation, GET /api/tab-layout returned HTTP 200 with groups: [] while the rail displayed a flat list and the Session actions menu offered only Session options and Close session.
This request is for the user-facing grouping experience and case/workspace placement, building on that foundation rather than introducing a second layout model.
Suggested behavior
Acceptance examples
Is a frontend follow-up to #335 already planned? If so, please link it; otherwise, could this track case/workspace-based session grouping?