I’ve been troubleshooting a frustrating conflict between OpenClaw and my preferred AI coding assistant (Cursor’s built-in agent). Both plugins appear to be competing for the same keybinding to trigger an “explain this code” function, but OpenClaw is consistently winning, regardless of my keymap.json order.
**My environment:**
- Editor: Cursor (v0.40)
- OS: macOS Sonoma 14.5
- Relevant Plugins: OpenClaw (v2.1.0), Cursor native AI (no separate plugin)
**The conflict:**
I have `cmd+i` mapped to Cursor’s “Explain” action, which works perfectly when OpenClaw is disabled. With OpenClaw enabled, the same shortcut triggers OpenClaw’s explanation overlay instead, which lacks the context I need for my workflow. I’ve confirmed this is not a Cursor-specific remap issue.
**Attempted resolutions (all failed):**
- Explicitly rebinding `cmd+i` in Cursor’s keymap settings (User).
- Adding a `when` clause to the keybinding (`editorTextFocus && !openClawVisible`).
- Disabling OpenClaw’s keybindings via its own settings file.
The plugin’s keybinding appears to be registered at a lower level, overriding user-level definitions. Has anyone successfully decoupled OpenClaw’s hotkeys without disabling its core functionality? I’m looking for a surgical fix, not just a plugin toggle, as I rely on its other features for repository navigation.
– Hudson
Measure twice, spend once
That lower-level registration you mentioned is really interesting. Have you checked if OpenClaw's keybindings are being set through the VS Code API in its activation script, instead of the standard keybindings.json method? I ran into something similar with another extension that used `context.globalState` for persistent shortcuts, and I had to manually clear that state before my user keymap would take priority.
Does Cursor have a developer console or a way to list all registered commands and their sources? Sometimes seeing the exact command ID OpenClaw is using can help you target it more directly in your keymap file with a `when` clause, even if it's a context you wouldn't expect.
Interesting. I've never used Cursor, but I see this in VS Code extensions all the time. Have you tried disabling the keybinding by setting it to an empty array in your keymap file? Something like `{ "key": "cmd+i", "command": "openclaw.explain", "when": "false" }`. It forces a no-op that can sometimes override the extension's default.
That's a clever trick I hadn't thought of. I'm a bit nervous about putting `"when": "false"` in my keymap, though. Does that permanently reserve that keybinding for a non-functional command? I'd worry about it blocking other extensions or future updates from using that shortcut in a useful way.
Is there a way to make it more temporary, like only disabling OpenClaw's binding while leaving the possibility open for something else to pick it up? Or does that `"when": "false"` just sit there inert?
The lower-level registration is probably coming from OpenClaw's activation function, like user574 said. Have you checked the extension's installed folder? Sometimes they hardcode bindings in the `package.json` `contributes` section that just ignore user overrides.
If you find the command ID there, you can try binding it to a nonsense key, like `cmd+alt+shift+i`, in your user keymap file. That often works better than trying to disable it, because it reassigns the command instead of fighting the activation precedence.