Proposal

Make Cmd/Ctrl+Shift+] / Cmd/Ctrl+Shift+[ cycle within the current tab's type instead of across all tab types.

• Focus on a terminal → chord cycles terminals only.
• Focus on an editor → chord cycles editor tabs only.
• Focus on a browser tab → chord cycles browser tabs only.
• Focus not on a tab → fall back to activeTabType from the store.

The newly-added Ctrl+PageDown / Ctrl+PageUp (#988 / #1094) would remain as the always-terminal-only chord, independent of focus — useful as an explicit "jump to terminals from anywhere" gesture.

Why

Prior art:

• VS Code (src/vs/workbench/contrib/terminal/browser/terminalActions.ts:528-562) binds Ctrl+PageDown/PageUp and the mac Cmd+Shift+]/[ equivalent to "focus next/previous terminal group" — gated on TerminalContextKeys.focus. So VS Code's Cmd+Shift+] on mac is the terminal-only cycle.

In practice, when a user hits "next tab" from a terminal, they almost always mean "next terminal," not "jump to whatever happens to be two slots over in the unified strip." The current cross-type cycle forces people to mash the chord repeatedly and visually filter on the tab icon — which is the exact complaint that motivated #988.

Alternatives considered

1. Setting toggle (tabCycleScope: "all" | "currentType"). Rejected: this is a design decision, not a user preference. Settings are permanent complexity — docs, support questions, test matrix. Pick the right default instead.
2. Leave Cmd+Shift+]/[ alone, only add terminal-only chord. That's feat(shortcuts): add Ctrl+PageDown/Up to cycle terminal tabs only #1094. Solves the immediate pain point but leaves the broader "next tab" chord still doing the wrong thing by default.
3. Flip default, add opt-out setting for old behavior. Reasonable but I'd bet nobody asks for the escape hatch. Ship without the setting; add it only if users complain.

Migration risk

Low. Anyone using Cmd+Shift+] to cross tab types was probably doing it by accident — aiming for the next tab of the kind they were looking at, tolerating the cross-type jumps as noise. For those users this lands as a bug fix, not a breaking change.

Implementation sketch

• handleSwitchTab in src/renderer/src/hooks/ipc-tab-switch.ts already has getActiveTabNavOrder(store, worktreeId). Add a filter by store.activeTabType before picking the next entry.
• If the user is cycling from an editor/browser but the current id isn't found in the filtered list (e.g. stale state), fall back to the first entry of that type.
• Update ipc-tab-switch.test.ts — current tests assert cross-type cycling; those become the "cycle within type" tests.
• No preload / main-process changes needed; the IPC channel stays ui:switchTab.

Escape hatch (optional)

If anyone does want the old cross-type cycle back, Cmd/Ctrl+Alt+] / Cmd/Ctrl+Alt+[ is available (sits under the existing Cmd/Ctrl+Alt+... carve-out in window-shortcut-policy.ts). Not proposing to add it preemptively — wait for someone to actually ask.

Context

Discussed on #1094 (the #988 implementation PR). That PR keeps the current "cycle all tab types" behavior untouched and adds Ctrl+PageDown/Up as an additive terminal-only binding. This issue tracks the follow-up: changing what the existing chord does by default.

Made with Orca 🐋