Move Editor to Next/Previous Group: no-op with a single editor group (works in VS Code; regression suspected after Agent UI)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

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

  1. Open a normal file with a single editor group (no split).
  2. Run Move Editor into Next Group from the Command Palette (or the user’s shortcut if configured).
  3. Observe: no new group / no move in Cursor.
  4. Split once so there are two groups; run the same command again → works.
  5. 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”.

Operating System

MacOS

Version Information

Cursor / About

Version: 3.0.16
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: Darwin arm64 24.5.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. This is a known bug. activeGroup can incorrectly point to the Chat editor group instead of the code editor in Cursor 3.x. There’s already a similar report here: Ctrl+Cmd+Left/Right moves focus to Chat tab and splits Chat editors instead of moving code editor

The team is aware of the issue. There’s no fix yet, but the workaround is to not use Chat as an editor tab and keep it in the sidebar instead. Not ideal, but it avoids the problem.

Let me know if there’s anything else.

1 Like
6

A post was merged into an existing topic: Ctrl+Cmd+Left/Right moves focus to Chat tab and splits Chat editors instead of moving code editor