[Feature]: Allow Ctrl+Tab keybindings for next and previous thread

[makeavish]

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

T3 Code exposes thread.next and thread.previous commands, but I cannot assign Ctrl+Tab and Ctrl+Shift+Tab to them in the keybinding settings.

This means #1014 does not fully solve the original workflow. That issue was closed because thread traversal became keybindable, but the specific tab-cycling shortcuts it requested are not usable in practice.

When working across several active threads, I want to switch between them without reaching for the sidebar or memorizing numbered positions. Ctrl+Tab is especially useful for quickly cycling through recent threads, similar to the thread-switching interaction in the ChatGPT desktop app.

Proposed solution

Allow the desktop app's keybinding system to capture, persist, and execute:

• Ctrl+Tab for thread.next; and
• Ctrl+Shift+Tab for thread.previous.

If these chords are currently filtered because Tab is treated as focus navigation, the keybinding recorder and dispatcher should recognize them before normal focus traversal when a modifier is held.

Ideally, repeated presses while holding Ctrl would cycle through threads and could show a lightweight recent-thread switcher/preview. However, the essential request is that these chords can be assigned and reliably invoke the existing thread traversal commands.

The behavior only needs to be guaranteed in the desktop app, where browser-reserved shortcut handling is under T3 Code's control. The web app can remain unsupported or require a different binding if browsers intercept these chords.

Why this matters

Thread switching is a frequent action when several agents or tasks are active. A conventional next/previous shortcut makes navigation faster and avoids depending on sidebar order, pointer interaction, or numbered thread shortcuts.

It also closes the gap between having keybindable traversal commands in theory and being able to assign the requested shortcut in practice.

Smallest useful scope

• Accept Ctrl+Tab and Ctrl+Shift+Tab in the desktop keybinding editor.
• Persist them like other custom bindings.
• Dispatch them to thread.next and thread.previous without triggering focus traversal.
• Document or surface any conflict when the same chord is assigned elsewhere.

A preview/MRU switcher can be a follow-up; direct cycling is sufficient for the first version.

Alternatives considered

• Use another custom shortcut for thread.next / thread.previous. This works around the limitation but loses the familiar tab-switching convention.
• Use numbered thread shortcuts. These require knowing a thread's position and do not provide simple next/previous cycling.
• Click threads in the sidebar. This interrupts keyboard-driven navigation.

Risks or tradeoffs

• Tab normally controls focus traversal, so modified Tab chords need to be intercepted without breaking accessibility behavior for unmodified Tab / Shift+Tab.
• [Feature]: Keyboard shortcuts to navigate between terminals and splits #2630 proposes the same default chords for cycling terminals. T3 Code should either resolve the conflict by context, warn about it in the keybinding editor, or leave both unassigned by default while still allowing users to choose.
• Browser environments may reserve or intercept these shortcuts, so desktop-only support is a reasonable initial boundary.
• Thread order should be explicit: the existing thread.next / thread.previous ordering is sufficient initially; MRU ordering could be considered separately.

Examples or references

• Keyboard shortcuts for navigating between projects and chats #1014 requested Ctrl+Tab thread cycling but was closed after thread.next / thread.previous became keybindable. The requested chords still cannot be assigned.
• Add Cmd+Shift+[ / ] hotkeys for switching between threads #1459 also requested previous/next thread shortcuts and was closed as completed.
• [Feature]: Keyboard shortcuts to navigate between terminals and splits #2630 proposes Ctrl+Tab / Ctrl+Shift+Tab for terminal cycling, so shortcut conflicts need a defined behavior.
• Comparable UX: Ctrl+Tab thread navigation in the ChatGPT desktop app.

Contribution

• I would be open to helping implement this.

[fsargent]

I opened PR #7548 for the smallest scope proposed here. It allows Ctrl+Tab and Ctrl+Shift+Tab to be assigned to the existing thread navigation commands without changing any defaults. Plain Tab and Shift+Tab continue to handle focus navigation. Focused tests are included.