Describe the Bug
Guys, for the sake of all the gods, dogs, cats, and everything you hold dear, please, PLEASE, stop overriding user’s custom hotkeys!
Today, after yet another update, when desperately trying to debug a critical issue, I’ve hit Cmd+E, expecting the editor to behave as usual, but instead it changed my view to some <censored>. When you urgently need a thing A, but instead someone shoves you in the face thing B, you start hating thing B immediately. Especially when you’re frustrated and in a hurry.
Please don’t do that.
Please.
With almost every single update when you release some new fancy feature, I have to interrupt my work and go to hotkey setting to find out which of my hotkeys have you fbrokened-up this time.
This is immensely frustrating.
Please don’t do that.
Steps to Reproduce
- Install old version of Cursor.
- Install “ms-vscode.atom-keybindings” extension (not sure if related. It might, it might not be)
- Define custom hotkeys that you know will be overridden in a later update.
- Update
- Observe your custom keybind no longer does what you expect it to
Expected Behavior
User’s custom keybinds should have the highest priority, no matter what the editor adds. If you want to introduce new hotkeys for a new feature, try showing release notes, like vscode does.
Bonus points if you’ll figure out which new keybinds conflicts with user’s custom keybinds and show a message/page/view, offering the user a possibility to bind new features to other hotkeys.
Operating System
MacOS
Current Cursor Version (Menu → About Cursor → Copy)
Version: 2.0.38 (Universal)
VSCode Version: 1.99.3
Commit: 3fa438a81d579067162dd8767025b788454e6f90
Date: 2025-10-29T20:45:40.883Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 23.6.0
Does this stop you from using Cursor
No - Cursor works, but with this issue