[Feature]: Delete settled threads from the Sidebar V2 settled shelf

[inayayousfi]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

The Sidebar V2 settled shelf only grows. There is no way to clear it.

Deleting settled threads today is either right-click → Delete, one thread at a time, or ctrl/shift multi-select → right-click → Delete. The second one is worse than it sounds because the settled tail is paged behind "Show more" (SETTLED_TAIL_INITIAL_COUNT), so I have to expand the tail before I can even select the threads I want gone.

Most of my settled threads are one-shot throwaways — a quick question, a small fix, done. I never want to see them again, and there is no low-friction way to say so.

The affordances are already almost there and just do not include delete:

• The slim settled row has a hover action slot, holding exactly one action, Un-settle (apps/web/src/components/SidebarV2.tsx:815-823).
• The shelf header (data-testid="sidebar-v2-settled-shelf-toggle", SidebarV2.tsx:2505-2525) only expands and collapses.

Proposed solution

1. Per row. Add a Delete (trash) hover action on slim settled rows, alongside the existing Un-settle button. Same code path as the context menu's delete case (SidebarV2.tsx:2080-2105): honors the confirmThreadDelete client setting, same failure toast.

2. Per shelf. Add a "Delete all settled" action on the settled shelf header. Scoped to the settled threads in the current partition — i.e. after the active project/scope filter — not every settled thread across every environment. It should include threads still hidden behind "Show more", with the count named in the confirm text so that is unambiguous.

Reuse the batch loop from the multi-select delete handler (SidebarV2.tsx:1915-1953) rather than writing a second one, so orphaned-worktree detection keeps working through the incrementally grown deletedThreadKeys set.

3. Always confirm the bulk action, even when confirmThreadDelete is off. That setting is a per-thread preference; clearing a whole shelf is a different blast radius.

Why this matters

Settle is the "I am done with this" gesture, and right now it is a dead end — the thread stays on disk and on the shelf forever. Making the shelf clearable turns settle into a real completion step instead of a visual mute, and it keeps the sidebar honest for anyone who runs many short threads a day.

Smallest useful scope

Just the header "Delete all settled" action. Per-thread delete already exists in the context menu, so the header is the piece that removes the O(n) interaction. The per-row hover button is a convenience on top and can land separately or never.

Alternatives considered

• Archive instead of delete. Archived threads are already excluded from Sidebar V2 (the thread.archivedAt === null filter at SidebarV2.tsx:1380), so a "Archive all settled" would clear the shelf without destroying history. If maintainers prefer archive as the bulk verb here, that solves my problem equally well — I care about the shelf being clearable in one action, not specifically about destruction. There is no bulk archive today either.
• Multi-select + right-click Delete. Works, but requires expanding the paged tail first, then a multi-select across it. Too much ceremony for routine cleanup.
• Delete on settle. Wrong. Settle is deliberately reversible (Un-settle exists, and [Feature]: Undo Settling a Thread #4706 asks for more of that). Delete is not.

Risks or tradeoffs

• Auto-settle is the big one. Threads settle themselves after sidebarAutoSettleAfterDays of inactivity, default 3. So the shelf is largely age-based, not intent-based — it contains work the user never explicitly finished with. A naive "Delete all settled" would take those too. Two ways out: name the exact count in the confirm and let the user decide, or restrict the bulk action to explicitly settled threads (settledOverride === "settled") and leave auto-settled ones alone. I lean towards the first, but this is the call that needs a maintainer decision before anyone writes code.
• Misclick on the row button. The slim row hover slot currently holds one benign, reversible action. Putting a destructive one next to it means a misfire on a row you meant to un-settle permanently clears its history. Delete thread button on hover #461 was closed with "we have multiple options on hover, that seems right rn" — that was the old sidebar; V2 slim rows have exactly one. If the hover slot should stay single-action, the header action alone still solves the main problem.
• Worktrees. Settled threads can still own a worktree, so a shelf-wide delete runs the same worktree-removal path that fails loudly in [Bug]: Bulk thread delete aborts on "git worktree remove failed" when the worktree is already gone, and the error hides git's stderr #4513. The bulk loop above already aborts on first failure and toasts, which is the right behavior, but it means a partially cleared shelf is a reachable state.

Examples or references

• Delete thread button on hover #461 — "Delete thread button on hover", closed on the old sidebar
• [Bug]: Bulk thread delete aborts on "git worktree remove failed" when the worktree is already gone, and the error hides git's stderr #4513 — bulk thread delete aborts on worktree removal, the same path a shelf-wide delete would use
• [Feature]: Undo Settling a Thread #4706 — Undo settling a thread, adjacent settled-lifecycle work

Contribution

• I would be open to helping implement this.