[BUG] Desktop app (macOS): 'Previous session' shortcuts (Ctrl+Shift+Tab / Cmd+Shift+[) do nothing, while 'Next session' (Ctrl+Tab) works
Open 💬 0 comments Opened Jun 13, 2026 by realpha-hokuto
Environment
- Claude desktop app 1.12603.1 (macOS, Code mode)
- macOS 26.5 (25F71), MacBook Pro + 2 external displays
- Input source: Japanese IME on ABC (US) keyboard layout
Description
The documented session-switching shortcuts (https://code.claude.com/docs/en/desktop) work in one direction only:
| Shortcut | Documented action | Result |
|---|---|---|
| Ctrl+Tab | Next session | ✅ works |
| Ctrl+Shift+Tab | Previous session | ❌ nothing happens |
| Cmd+Shift+[ | Previous session | ❌ nothing happens |
Steps to reproduce
- Open the desktop app in Code mode with 3+ sessions in the Recents sidebar.
- Press Ctrl+Tab → switches to the next session (works).
- Press Ctrl+Tab again → advances to the 3rd session (so the cycle is position-based and we are now mid-cycle, with a valid 'previous' target).
- Press Ctrl+Shift+Tab → nothing happens.
- Cmd+Shift+[ also does nothing (tested from the top of the list).
Expected
Ctrl+Shift+Tab / Cmd+Shift+[ should move to the previous session, mirroring Ctrl+Tab.
Ruled out locally
- Not a 'no previous session' edge case — step 4 fails even mid-cycle where a previous target exists.
- Karabiner-Elements is running, but its active rules only touch right_option / caps_lock / command keys — no Tab, bracket, or Ctrl+Shift rules (karabiner.json inspected).
- No macOS symbolic hotkey is bound to the Tab key (com.apple.symbolichotkeys checked).
- Both 'previous' bindings fail while Ctrl+Tab works, which points at the previous-session handler/binding itself rather than key delivery.
🤖 Filed with Claude Code on behalf of the user after local diagnosis.