[Bug]: Settle shortcut keeps the settled thread open instead of moving to the next thread #16090

Activity

1. juliusmarminge commented on Oct 5, 2026

   

   juliusmarminge

   on Oct 5, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the clear repro and the pointer into the two code paths, @jpsirois. On main at 1604ccc9d7, settling the open thread from the sidebar already moves you forward. The settle shortcut and the chat title menu do not.

   What I found

   • planForwardNavigation in apps/web/src/components/Sidebar.tsx picks the next card before the settle runs, then navigates only if the settle succeeds and you are still on that thread (shouldNavigateAfterThreadPark). The next card is the next active thread that is not settled, snoozed, or leaving in the same batch. If none remains, it opens a new draft in the same project. The sidebar Settle button, a drop on the Settled header, and Settle thread in the sidebar context menu all use this path.
   • Two other actions call settleThread and stay put:
     • thread.settle (mod+shift+s) in apps/web/src/components/ChatView.tsx settles the open thread and leaves it open. If that thread is already settled, the same shortcut un-settles it.
     • Settle thread in the chat title menu (apps/web/src/hooks/useThreadActionMenu.ts, opened from ChatHeader) does the same. That menu is always the open thread, which is the case the sidebar treats as parking the thread you are looking at.
   • The sidebar context menu is not part of this gap. It already calls attemptSettle.
   • The shortcut was added in feat(web): settle and restore threads with a keyboard shortcut #8089 as a settle/restore toggle that stays on the current thread. Moving forward would change the next press: it would settle the next thread instead of restoring the one you just settled. Restore would still work after you go back to that settled thread. The title-menu action is not a toggle, so it is a clearer candidate to follow the sidebar rule. Snooze from that same title menu also skips the forward navigation the sidebar snooze button uses.
   • No duplicate issue. Mobile has no thread.settle shortcut. Related open feat(web): settle the thread with mod+w on desktop #15688 maps mod+w to settle but also does not navigate.

   Likely fix area

   • Have the chat title Settle thread action share the sidebar attemptSettle / planForwardNavigation path.
   • Decide whether thread.settle should keep its stay-put toggle behavior, or also move forward after settling an active thread (with restore still available once you reopen that thread).

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 5, 2026
3. jpsirois commented on Oct 5, 2026

   

   jpsirois

   on Oct 5, 2026

   Author

   More actions

   I have a small fix on a local branch and tested it locally: thread.settle now uses the same settle-and-advance step as the sidebar Settle button. The sidebar registers its handler, and the shortcut calls it. Without a mounted sidebar, the shortcut settles in place as before. The chat title menu stays as it is, because its comment says it stays on the thread by design.

   Trade-off: a second press now settles the next thread instead of restoring the one you just settled. Restore still works when you go back to the settled thread.

   Is this the direction you want? If yes, I will open the PR.
4. HerbCaudill commented on Oct 12, 2026

   

   HerbCaudill

   on Oct 12, 2026

   More actions

   +1 to this. From the user's perspective, it doesn't make sense that I would see one behavior when using a keybind to settle and another when using a mouse click to settle. Settling is how I triage tasks, and once something is settled I don't want it in front of me any more.
5. t3dotgg

   closed this as completedin #19328on Oct 14, 2026