Cursor misconfiguration blocks VS Code native Ctrl+1 shortcut keys used to focus first editor panel

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am unable to press Ctrl+1 to focus first editor panel (in split view mode) because of a Cursor misconfiguration.

Steps to Reproduce

  1. Update to latest Cursor version (3.0.16 at the moment)
  2. Close all Cursor Chat and Agent windows/panels
  3. Open a file
  4. Press Ctrl+\ once or twice to split the current editor into 2 or 3 editors
  5. Press Ctrl+2 or Ctrl+3 to focus the second or third editor panel => Success
  6. Press Ctrl+1 to focus the first editor panel => Failed => Bug

Expected Behavior

Pressing Ctrl+1 must focus the first editor panel, regardless the Cursor Chat panel is open or not.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.0.16 (system setup)
VSCode Version: 1.105.1
Commit: 475871d112608994deb2e3065dfb7c6b0baa0c50
Date: 2026-04-09T05:33:51.767Z
Layout: editor
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: Windows_NT x64 10.0.26200

Additional Information

My workaround:

  1. Open “Keyboard Shortcuts” settings
  2. Search for “View: Focus First Editor Group”
  3. Observe the “When” expression is !cursor.chatEditorGroup.enabled => This is the culprit
  4. Right click > Change When Expression > Delete all the faulty expression
  5. Now Ctrl+1 is back to work. I tested and this workaround works with Cursor Chat panel opened and closed.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the report. It’s super solid, with both a root cause and a workaround.

Confirmed, this is a bug on our side. When cursor.chatEditorGroup.enabled is on, the Ctrl+1 binding for focusFirstEditorGroup gets disabled and nothing replaces it, so the shortcut just stops working. Most likely Ctrl+2 through Ctrl+3 for focusing editor groups are affected by the same condition too.

Your workaround removing the When Expression is the right move for now. I’ve passed this on to the team. No specific ETA yet, but your report helps us prioritize it.