Optional most-recently-used order for thread.next / thread.previous (or an Alt+Tab-style recent-thread switcher)

[andybergon]

Area
apps/web

Problem or use case
thread.next and thread.previous step through threads in the sidebar's positional order (pinned, then active, then snoozed, then settled), not the order threads were last visited. When I bounce between two threads that sit far apart in that list, "previous" does not take me back to the one I was just on. It walks the list instead, so returning to my last thread can take several presses.

This is the ordering the request in #6966 explicitly left for later ("MRU ordering could be considered separately", "a lightweight recent-thread switcher/preview" as a follow-up). Filing it separately so that follow-up has a home.

Proposed behavior
Offer a most-recently-used traversal option alongside the existing positional prev/next, so both orderings are available. Either shape works:

• a separate pair of bindable commands for MRU previous/next, or
• an Alt+Tab-style overlay that cycles recently visited threads while a modifier is held, similar to editor and browser tab switching.

The positional prev/next should stay as-is; this is an addition, not a replacement.

Why this matters
Switching between the two or three threads you are actively working is the common case, and MRU order matches how tab switching works in editors and browsers. Positional order is better for scanning the whole list; MRU is better for "flip back to what I was just doing."

Related

• [Feature]: Allow Ctrl+Tab keybindings for next and previous thread #6966 requests Ctrl+Tab for the existing positional prev/next and defers MRU as separate.
• Add browser-style tab bar for working across multiple T3 Code sessions #7341 proposes a browser-style tab bar for working across sessions (a visible-UI take on the same multi-thread workflow).

[Williawar]

Opened #11072 with the smallest version of this: a thread.cycleRecent command, ctrl+tab by default. One press goes to the last viewed thread; holding the modifier and pressing again steps further back, release commits (Arc/Dia/Chrome tab cycling). Session-only list, no overlay, no persistence. thread.previous and thread.next are unchanged.

[maxwellyoung]

I tried the overlay version of this in #12065 before getting sign-off, and it got closed under the prior-approval rule. Asking here properly this time.

What it did: hold mod+shift and tap ] or [ (the existing thread.next / thread.previous bindings) to open a switcher over your most recent threads. Taps move the highlight and releasing the modifier opens it. A single tap and release takes you back to the thread you just left, so bouncing between two threads is one keystroke. Escape or switching windows cancels. The overlay shows up to ten threads, history is per session, and the highlighted thread is announced to screen readers. It appears instantly with no animation, since it's a keyboard action you'd hit constantly.

The close note pointed out that it changes what the existing traversal shortcuts do, and the original ask here was for positional prev/next to stay as they are. So I'd rather reshape it than argue for that:

• Option A: a new thread.switchRecent command (plus a reverse) with the overlay, leaving thread.next / thread.previous exactly as they are. Unbound by default, or ctrl+tab if you want a default.
• Option B: the smaller no-overlay version from feat(web): thread.cycleRecent switches to the last viewed thread on Ctrl+Tab #11072, which only needs a recording.

I'd lean towards A, since the overlay is what makes it clear where release will land once you go past the last thread. Happy to do either, or to stay out of the way if #11072 is the version you want. Which shape works for you?

[Brechard]

I've prototyped the overlay version for switching between working conversations and would like approval of the direction and scope before opening an upstream PR.

The proposed behavior is:

• Add separate forward/backward conversation-cycle commands, bound to Ctrl+Tab and Ctrl+Shift+Tab by default. Existing thread.next / thread.previous keep their positional behavior.
• Arc-style (proposed default): hold Ctrl to select from recent conversations, release to open, and tap again to return to the last conversation. Shift reverses; Escape or losing window focus cancels without navigating.
• Chrome-style, selectable in Settings → General → Conversation switching: each press immediately opens the next/previous conversation in sidebar order, without an overlay.
• The overlay shows the conversation title, project, branch/worktree, and existing attention state (approval, input, working, unread, etc.). The selected row's footer identifies its directory and machine. It reads the existing shell metadata without fetching conversation transcripts.

The new sidebar includes pinned, active, and working conversations, including a collapsed Working shelf. The legacy sidebar uses its visible conversations. History is per window and resets on reload; previewing alone does not mark a conversation read. This is web/desktop keyboard navigation, with remappable bindings for browsers that reserve Ctrl+Tab.

Prepared branch, based directly on upstream 9a3070bcf0, with one feature commit (b208522614).

Before: upstream default	After: Ctrl held

Arc-style recording — 15.18 seconds: hold, advance, reverse, release, tap to return.

Chrome-style recording — 11.67 seconds: immediate forward and reverse navigation.

Verification on the clean upstream branch: 604 focused tests passed across switcher behavior, keybindings, settings, and sidebar status logic; web/contracts/shared typechecks passed; targeted lint introduced no warnings compared with the base. I also exercised both modes, modifier release, reverse, quick return, and cancellation in T3 Code's embedded Chromium Browser panel on macOS against isolated state.

Screenshots are from the stated upstream revisions at the same 1280×800 viewport. The sanitized clips were recorded before the transplant; the switcher component, hook, and ordering logic are identical to the public commit. Attention states are visual fixtures, and held sequences use DOM keyboard events, so these captures do not establish OS-level accelerator handling.

Would you approve this scope, including the overlay, the two-mode setting, and the default Ctrl+Tab bindings, for an upstream PR?

Prepared with GPT-6-astra through the Codex harness in T3 Code.

[maxwellyoung]

far too busy imo, recent conversations is implied for example