I’m seeing a focus/keybinding issue with editor-group movement shortcuts on macOS.
Steps to Reproduce
Minimal repro steps
Open Cursor Chat as an editor tab (not just sidebar pane).
Open a normal code file tab (e.g., .ts) and focus it.
Press Ctrl+Cmd+Right.
Focus jumps toward Chat/editor area.
Press Ctrl+Cmd+Right again.
Chat tabs are moved/split instead of the code tab.
Expected Behavior
Expected behavior
When a code file tab is focused, pressing Ctrl+Cmd+Left/Right should move that code editor tab to the previous/next editor group.
Hey, thanks for the report. This looks like a bug with how editor group focus is tracked when Chat is open as an editor tab. The moveEditorToNextGroup and moveEditorToPreviousGroup commands use activeGroup, which may incorrectly point to the Chat group.
I’ll pass this to the team. In the meantime, can you share your exact Cursor version? You can find it in Help > About or Cursor Settings > General. You wrote “[please fill exact version]”, and the exact version will help us reproduce it.
As a temporary workaround, try not keeping Chat as an editor tab, and use it from the sidebar instead. I know it’s not ideal, but it’s the easiest way to avoid the issue for now.
Thanks for the quick response and for confirming this.
My Cursor details are:
Cursor Version: 3.0.13
VSCode Version: 1.105.1
Commit: 48a15759f53cd5fc9b5c20936ad7d79847d914b0
Date: 2026-04-07T03:05:17.114Z
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: Darwin arm64 25.3.0
I can consistently reproduce it with this flow:
Open Chat as an editor tab
Focus a normal code file tab (.ts/.tsx)
Press Ctrl+Cmd+Right (moveEditorToNextGroup)
Focus jumps to Chat/editor group
Press it again
Chat tabs are moved/split instead of the code editor
I also tested custom keybindings with strict when clauses (editorTextFocus && resourceScheme == file) and removed conflicting bindings, but behavior is the same.
workbench.action.moveEditorToNextGroup / workbench.action.moveEditorToPreviousGroup (and/or shortcuts intended for “move editor to next/previous group”) appear to be a no-op when there is only one editor group in Cursor, while upstream VS Code creates/opens an adjacent group in that situation. After the editor is manually split into two or more groups, the same commands work. Same keybindings behave as expected in VS Code on the same machine.
User keybindings.json check
I reviewed ~/Library/Application Support/Cursor/User/keybindings.json:
There are no user rules in that file binding ctrl+cmd+left, ctrl+cmd+right, workbench.action.moveEditorToNextGroup, or workbench.action.moveEditorToPreviousGroup. So this does not look like a duplicate user override on those keys/commands in that file.
Steps to Reproduce
Steps to reproduce
Open a normal file with a single editor group (no split).
Run Move Editor into Next Group from the Command Palette (or the user’s shortcut if configured).
Observe: no new group / no move in Cursor.
Split once so there are two groups; run the same command again → works.
Compare with VS Code (current stable): step 2 creates/opens the adjacent group without a prior manual split.
Expecte
Expected Behavior
Match VS Code: moving to next/previous group should still do something useful with only one group (e.g. create an adjacent group and move the editor), as in recent VS Code workbench behavior.
Actual (Cursor)
No-op until at least two groups already exist.
Hypothesis
Possible regression or VS Code parity gap after Agent / Composer / editor layout changes (e.g. Cursor 3.x), affecting editor-group creation on “move to next/previous group”.