Option: after settling, open the next thread that needs me

[ToukoUrsin]

I run many threads in parallel and use Settle as "done with this one". Settling the open thread from the sidebar already moves me to the next sidebar row, but that row is often a thread that is still working, so I click around to find the one that finished or is waiting for an answer or approval. The settle shortcut (mod+shift+s) and the thread header menu don't move at all, so I settle and then hunt for the next thread.

Proposal: a client setting, off by default, "Open next waiting thread after settling". When on, settling the open thread from any entry point (sidebar, header menu, shortcut) opens the next thread in sidebar order that needs me (finished, asking, awaiting approval, or failed). If none does, it keeps today's behavior: the next sidebar row, then a new thread.

It reuses the existing forward navigation after settle and the sidebar order used by thread.next. Default behavior stays the same. I have a small implementation ready (tests, lint and typecheck pass) if the direction makes sense.

---

AI-written: drafted and implemented with Claude Code (Claude Opus 5.5) on my behalf; I reviewed and asked for it.

[AdEx-Partners-DE]

I measured my own usage before building this, and the number surprised me: finished threads waited a median of 9.1 minutes for my next message, and one in ten waited more than 102 minutes. The agents were never the bottleneck. I was.

So my fork has a small "work through what waits on you" loop:

• mod+shift+u opens the thread that needs you most: waiting on an approval or an answer first (longest wait first), then failed, then stopped on a usage limit, then finished and unread. Press again for the next one. Also in the command palette.
• A count above the list by reason: need an answer, failed, at a limit, unread. Click a count to open the first of that kind. Nothing waits: no line.
• Open the next thread that needs you after sending (Settings → General, off by default): send, and you are already in the next one. Nothing waits: you stay.

It feels like an inbox you can clear. One key, answer, next.

Tried in a dev build: the shortcut jump, the "nothing waits" case, the setting on and off. Not yet reproduced: the jump after sending with a second waiting thread. I will repeat the measurement after a week and post the new median here.

Does "longest wait first" match how you would rank them? #8576 asks for the latest unread instead.

Code: 876fe856f, acf5497a9, ad782f170, de090dcca. on stark/main.

---

Posted by Claude (Opus 5.5, Claude Code via T3 Code) on behalf of @AdEx-Partners-DE.