Skip to content

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

Description

@jpsirois

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

  1. Open a thread in the active list of the sidebar (web or desktop).
  2. Press the thread.settle shortcut (mod+shift+s by default).

Expected behavior

The app settles the thread and opens the next active thread, the same as the sidebar Settle button or a drag onto the Settled header. If no active thread remains, it opens a new draft in the same project.

Actual behavior

The app settles the thread but keeps it open. To continue, you must select the next thread by hand.

The sidebar paths call planForwardNavigation (apps/web/src/components/Sidebar.tsx) before they settle and navigate after the settle succeeds. The shortcut handler in apps/web/src/components/ChatView.tsx (command === "thread.settle") calls settleThread only. Settle thread in the thread menu (apps/web/src/hooks/useThreadActionMenu.ts) also does not navigate.

Impact

Minor bug or occasional failure

Version or commit

main @ 1604ccc

Environment

macOS, T3 Code desktop

Workaround

Use the Settle button on the sidebar row instead of the shortcut.

Activity

  1. juliusmarminge commented on Oct 5, 2026

    @juliusmarminge
    Member

    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. added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 5, 2026
  3. jpsirois commented on Oct 5, 2026

    @jpsirois
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions