Cursor Keybindings Not Working? Chords and Broken Imports

Because ⌘/Ctrl+K belongs to inline edit in Cursor (and to the prompt bar in the terminal), every two-step VS Code chord you have in muscle memory moved. A Cursor staff answer on the forum states it directly: "⌘/Ctrl+K is used for the inline edits. We therefore changed the keychord leader key to be ⌘+R on Mac and Ctrl+M on Windows and Linux."

Check this before you open any settings file. It costs nothing, and the failure does not present as broken: the key does something, just not your thing, so people go looking for a corrupted config instead of a moved leader.

Cursor's own help page has absorbed the change: its instructions for reaching the shortcuts screen now start with ⌘+R.

The Windows story is muddier than that table makes it look. The same help page gives the Windows and Linux route as Ctrl+R then Ctrl+S, which is not the Ctrl+M in the staff answer. Press Ctrl+R first if you are on Windows and keep Ctrl+M as the fallback, rather than deciding which page is stale from your desk. Test both once and keep whichever your build answers to.

Whether to put the leader back on ⌘+K comes down to how many chords you use, and for most people the honest number is two or three. Moving it back means sharing the key with inline edit, which then wants a when clause to keep the two apart, and that is more configuration than remapping three chords by hand. The keybindings.json guide has the setting if you want it anyway.

What you do about it depends on the size of the move. Two people, you say the leader changed and it is over. Migrate fifty engineers in a week and the same sentence arrives as fifty tickets, so put it in the migration note beside the import steps.

Users importing VS Code settings have found entries in Cursor whose when fields read (arbitrary function), a placeholder left when a condition could not be carried across the import. A binding with that clause never fires, silently. The fix is deletion and rebinding, not repair:

1. 1Open Preferences: Open Keyboard Shortcuts (JSON) from the command palette and delete every entry whose when is (arbitrary function).
2. 2Rebind the survivors you actually use through the Keyboard Shortcuts UI (right-click a command → change keybinding) so Cursor writes valid conditions itself.
3. 3For anything needing a precise scope, write the when clause by hand. The keybindings.json reference covers the syntax and context keys.

The step says delete rather than fix because the condition did not survive the import, and the placeholder is all that is left of it. What makes it expensive is the silence, since Cursor raises no error when a binding carrying that clause fails to fire.

The scope of that claim is worth stating. It comes from a forum thread with a staff reply behind it rather than from documentation, so look for it in a migrated setup instead of expecting it everywhere.

Rule out its neighbour in the same pass. The one-click import carries your extensions across with your keybindings, and Cursor installs them from Open VSX, a different registry, where plenty of Marketplace extensions have no listing. A binding whose command belonged to an extension that did not make the trip has nothing left to call. Confirm the extension is installed before you rewrite the key.

When a key does something unexpected (or nothing), stop guessing and ask the editor. Two built-in tools answer it definitively:

1. 1Run Developer: Toggle Keyboard Shortcuts Troubleshooting from the command palette, press the key, and read the log. It shows every rule the keystroke matched and which binding won.
2. 2In the Keyboard Shortcuts UI, search by the key itself (type the combo into the search box) to see all commands competing for it and each one's when clause.
3. 3Fix by narrowing scope: give your binding a focus guard (e.g. editorTextFocus) or disable the competing default by re-adding it with a minus-prefixed command in keybindings.json.

Between the two fixes in that last step, I used to reach straight for the minus-prefixed line. Narrow the scope first instead. Disabling a default is one line and takes the command away everywhere in your editor, including the context where you were glad to have it, and in six months you will not remember doing it. A when clause keeps both bindings alive and costs you one expression. Save the removal for a default you genuinely never want.

One last shape, and it is not a keybinding problem at all. A shortcut can fire perfectly into a feature that has nothing to act on. Design ModeA way to point at an element in Cursor's built-in browser and change it directly, instead of describing it in words. Press Enter for the full definition. has nothing to select until your app is rendering in the browser panel, so ⌘+⇧+D pressed at an empty one can read as an inert key. Confirm the thing your shortcut opens has something to open before you edit keybindings.json over it.

It can, and Cursor's troubleshooting page names the pattern: extensions that provide their own AI completions or intercept keyboard shortcuts are frequent sources of conflict, with other AI coding assistants the primary culprits. Which is worth a thought straight after a migration, since whatever was grabbing your keys in VS Code arrived in the same import.

1. 1Run Disable All Installed Extensions from the command palette, then press the shortcut again.
2. 2If it works now, re-enable extensions one at a time until it breaks. That one is your conflict.
3. 3Disable the culprit for good from the Extensions panel (⌘+⇧+X, or Ctrl+⇧+X on Windows and Linux): find it in the list, click Disable.

This check comes last on purpose. Bisecting an extension list is the most expensive thing on this page, and the troubleshooting log above usually names a competing binding long before you need it. Reach for the bisect when the log shows nothing matching your keystroke at all.