Feature request for product/service
Cursor IDE
Describe the request
Summary
On macOS, Cursor binds Cmd+R to “Reload Window” (workbench.action.reloadWindow), which is the same chord most developers use as Run in Xcode. People who switch between Xcode and Cursor repeatedly hit Cmd+R out of habit and accidentally reload the entire Cursor window. That interrupts work and can discard or derail long chat/agent sessions—with no confirmation.
Why this matters
Cmd+R as Run is an established convention in Xcode. Reloading the whole IDE from the same chord is easy to trigger accidentally and feels like destructive behavior (lost context, restarting panels, disrupted flow).
Desired outcome (any one or combination)
Change the default macOS keybinding so Cmd+R does not reload the Cursor window out of the box—for example bind Reload Window to another chord or require a chord.
Show a confirmation dialog before reloading when Chat/Agent sessions are active, or offer “Don’t ask again.”
Improve discoverability for/Xcode users during onboarding (“Cmd+R reloads Cursor; change in Keyboard Shortcuts”).
Documentation: call out explicitly in Help/docs that Reload Window clashes with Xcode Run on macOS.
Environment
Platform: macOS
Workaround I use locally
Remove the binding with a user keybinding rule such as removing workbench.action.reloadWindow from Cmd+R and optionally Ctrl+R via keybindings.json.
Thanks for considering this—it will save a lot of accidental disruption for anyone living in Xcode and Cursor on the same machine.
Operating System (if it applies)
MacOS
Problem
On macOS, ⌘R is Run in Xcode and many developers have that wired in deeply. Cursor/VS Code historically binds ⌘R to workbench.action.reloadWindow (“Reload Window”). Accidental ⌘R reloads the whole window, which disrupts workflow and—in Agent/Chat—can clear or lose session context.
Desired behavior
-
Do not ship macOS defaults where ⌘R means “Reload Window.”
-
Prefer a less collision-prone chord for reload (e.g. a chord or palette-only), especially on macOS where ⌘R is strongly associated with Run.
Extra nuance we hit in practice
Removing workbench.action.reloadWindow from ⌘R via user keybindings helps for the workbench shortcut, but Agent/Chat UI can still see ⌘R like a browser refresh in an embedded surface. So:
- Users may still need to explicitly swallow ⌘R (e.g. bind
cmd+r to "" after unbinding) so the key doesn’t fall through and wipe chat.
Ideally Cursor never treats ⌘R inside chat/agent webviews as “refresh page,” regardless of global keybinding defaults.
Workaround today (users)
In ~/Library/Application Support/Cursor/User/keybindings.json:
-
Unbind reload from ⌘R / ⌃R:
"command": "-workbench.action.reloadWindow" with "key": "cmd+r" / "ctrl+r".
-
Optionally consume the chord so webviews don’t get it:
"key": "cmd+r", "command": "" (and same for ctrl+r if desired).
Reload when truly needed: Command Palette → “Developer: Reload Window”.
Ask for the product
-
Change macOS default keybindings so ⌘R is not Reload Window by default (or gate behind a macOS-specific default profile).
-
Ensure chat/agent surfaces don’t interpret ⌘R as reload even if users customize keybindings.
-
Document Xcode vs Cursor ⌘R conflict and the safe workaround.