[feature]: Navigation history, back/forward buttons and keybindings

[pantharshit007]

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

When moving between multiple threads, or opening settings and returning to a thread, there is no quick way to retrace steps. Numbered thread shortcuts (Cmd+1, Cmd+2, …) help for fixed slots, but they do not help when you have been bouncing across several threads or left a thread for settings and want to land back where you were.

This is a common navigation problem that browsers, VS Code, and Slack already solve with back/forward history.

Proposed solution

Add browser-style back and forward navigation for primary UI locations (threads, settings, and similar views).

UI

• Back and Forward buttons in the app chrome (similar to browser / VS Code / Slack).
• Click to move one step back or forward.
• Hold (long-press) on back/forward to show a history list and jump to a specific entry (same idea as Chrome’s “Click to go back, hold to see history”).

Keybindings

Shortcut	Action
Cmd+[ (macOS) / Ctrl+[ (Windows/Linux)	Go back
Cmd+] (macOS) / Ctrl+] (Windows/Linux)	Go forward

These match common conventions in VS Code and many other apps.

Example flows

1. Thread A → Thread B → Thread C, then Cmd+[ twice to return to A.
2. Open Settings from a thread, then back to the previous thread.
3. Hold back to pick an older location from the history stack instead of stepping one-by-one.

Why this matters

Anyone who juggles multiple threads or frequently leaves a thread for settings would navigate faster and with less friction. Back/forward is a small, familiar pattern that reduces sidebar hunting and makes the app feel more like other tools people already use all day.

Smallest useful scope

• Maintain a simple history stack for primary views (at least threads and settings).
• Back/forward buttons + Cmd+[ / Cmd+] (and Ctrl equivalents).
• Disable buttons when there is nothing in that direction.
• Hold-to-see-history can be a follow-up if needed for v1.

Alternatives considered

• Rely only on Cmd+1…Cmd+N thread shortcuts — useful for fixed slots, but not for chronological “where I just was” navigation.
• Always use the sidebar to re-select threads — works, but is slower and breaks flow when switching often.

Risks or tradeoffs

• Need a clear rule for what pushes history (e.g. threads and settings yes; ephemeral panels/search maybe no).
• Keybindings should not conflict with existing shortcuts.
• History should probably not grow unbounded or retain stale/deleted threads awkwardly.

Examples or references

Comparable patterns:

• Browsers (back/forward + hold for history)
• VS Code
• Slack

Chrome-style control:

“Click to go back, hold to see history”

Contribution

• I would be open to helping implement this.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Related proposal issue #7729 adds explicit cross-client behavior to this navigation request.

The same app navigation history must drive both the Back and Forward buttons and the Cmd+[, Cmd+], Ctrl+[, and Ctrl+] keybindings. Each control is disabled when its direction has no history entry. The behavior covers responsive web, desktop, and mobile, with placement adapted to each client's existing navigation. It is for main app locations such as threads and settings, not the browser preview.

Moving backward or forward must not add a duplicate history entry or create a loop. For example, after Thread A then Thread B, Back returns to A and Forward returns to B through the same shared history. Opening Settings from a thread and going Back returns to that thread.

I am preserving these requirements here before the source issue closes during the policy pass. The complete proposal remains available in issue #7729. This handoff does not mean the navigation feature is implemented or fixed.