[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

  1. Open the desktop app in Code mode with 3+ sessions in the Recents sidebar.
  2. Press Ctrl+Tab → switches to the next session (works).
  3. 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).
  4. Press Ctrl+Shift+Tab → nothing happens.
  5. 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.

View original on GitHub ↗