Ctrl+r in chat/composer ignores user keybindings and still creates a new chat

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When the chat/composer input has focus, ctrl+r ignores my user keybinding for workbench.action.openRecent and instead creates a new chat. The same keybinding works correctly in other Cursor contexts like the editor and explorer.

Steps to Reproduce

  1. Open Cursor on macOS.
  2. Add this to your user keybindings.json:
{
  "key": "ctrl+r",
  "command": "workbench.action.openRecent"
}
  1. Focus the editor or explorer and press ctrl+r.
  2. Confirm that workbench.action.openRecent runs as expected.
  3. Move focus into the chat/composer input.
  4. Press ctrl+r again.
  5. Observe that Cursor creates a new chat instead of running workbench.action.openRecent.

Optional Verification

  1. Run Developer: Toggle Keyboard Shortcuts Troubleshooting.
  2. Focus the chat/composer input.
  3. Press ctrl+r.
  4. Observe that the troubleshooting log says the matched command is workbench.action.openRecent, even though the UI still creates a new chat.

Expected Behavior

User keybindings should be respected consistently, including when the chat/composer input is focused.

Operating System

MacOS

Version Information

Version: 2.6.22 (Universal)
VSCode Version: 1.105.1
Commit: c6285feaba0ad62603f7c22e72f0a170dc8415a0
Date: 2026-03-27T15:59:31.561Z (5 days ago)
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0

Additional Information

Developer: Toggle Keyboard Shortcuts Troubleshooting

2026-04-01 12:35:16.724 [info] [Window] [KeybindingService]: / Soft dispatching keyboard event
2026-04-01 12:35:16.724 [info] [Window] [KeybindingService]: \ Keyboard event cannot be dispatched
2026-04-01 12:35:16.724 [info] [Window] [KeybindingService]: / Soft dispatching keyboard event
2026-04-01 12:35:16.724 [info] [Window] [KeybindingService]: \ Keyboard event cannot be dispatched
2026-04-01 12:35:16.724 [info] [Window] [KeybindingService]: / Soft dispatching keyboard event
2026-04-01 12:35:16.724 [info] [Window] [KeybindingService]: \ Keyboard event cannot be dispatched
2026-04-01 12:35:16.725 [info] [Window] [KeybindingService]: / Received  keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 17, key: Control
2026-04-01 12:35:16.725 [info] [Window] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 5 ('Ctrl')
2026-04-01 12:35:16.725 [info] [Window] [KeybindingService]: \ Keyboard event cannot be dispatched in keydown phase.
2026-04-01 12:35:18.021 [info] [Window] [KeybindingService]: / Soft dispatching keyboard event
2026-04-01 12:35:18.021 [info] [Window] [KeybindingService]: | Resolving ctrl+[KeyR]
2026-04-01 12:35:18.021 [info] [Window] [KeybindingService]: \ From 3 keybinding entries, matched workbench.action.openRecent, when: no when condition, source: user.
2026-04-01 12:35:18.021 [info] [Window] [KeybindingService]: / Soft dispatching keyboard event
2026-04-01 12:35:18.022 [info] [Window] [KeybindingService]: | Resolving ctrl+[KeyR]
2026-04-01 12:35:18.022 [info] [Window] [KeybindingService]: \ From 3 keybinding entries, matched workbench.action.openRecent, when: no when condition, source: user.
2026-04-01 12:35:18.022 [info] [Window] [KeybindingService]: / Soft dispatching keyboard event
2026-04-01 12:35:18.459 [info] [Window] [KeybindingService]: + Ignoring single modifier ctrl due to it being pressed together with other keys.

### Does this stop you from using Cursor
No - Cursor works, but with this issue
6

Hi @tesseract36,

Seems like a bug. The composer input handles keyboard events in a way that can swallow certain keybindings before VS Code’s keybinding service actually dispatches them. Your troubleshooting log shows exactly this: the correct command is resolved during soft dispatch, but it never reaches hard dispatch (execution). This can affect any user keybinding when the composer input has focus.

No workaround at the moment beyond pressing the shortcut when the editor or another panel is focused. Will report to the team.