Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
After using the built-in browser and then switching back to an Agent chat, it seems like some of my keyboard input are still being picked up by the browser instead of the chat.
The weird part is that the chat input looks focused. I can see the text cursor in the message field and type normally, but certain shortcuts still control the browser and move focus over to the browser so I can’t even continue typing and instead have to move my mouse back to the Agent chat.
The easiest example is Alt + Left / Alt + Right. I use those shortcuts to move the text cursor word by word, but instead the browser goes back or forward a page.
I also noticed the same thing with Alt + Up / Alt + Down. Those seem to act on the browser page as well instead of the chat input.
So basically:
- Use the built-in browser.
- Switch to an Agent chat.
- Start typing in the chat input.
- Press an Alt + Arrow shortcut.
The browser reacts to it, even though my cursor was focused on the chat.
I’m not sure if other people are running into this with different key combinations too, but Alt + Arrow is where I notice it consistently.
I asked Opus 5.5 (medium) and the reponse I got seemed logical and moves the initial first thought of it just being my own personal hotkey settings, hence why I am writing this report.
Here’s the Agent response:
I found the cause, and it can’t be fixed with a keybinding when condition. Cursor’s built-in browser catches Alt+Left and Alt+Right in Electron’s main process, before the workbench keybinding system ever sees them.
The code is in /Applications/Cursor.app/Contents/Resources/app/out/main.js. Each browser view registers a before-input-event listener, which runs on every key press while the browser has native keyboard focus. That listener checks the key against a fixed table and calls preventDefault() on a match. The relevant part of the table:
else if (s && !n && !r) // alt only, no cmd, no shift
switch (i) {
case "arrowleft": a = "navigate-back"; break;
case "arrowright": a = "navigate-forward"; break;
}
This has no when clause and doesn’t show up in the Keyboard Shortcuts editor. Your keybindings.json has no browser entries either, and the workbench commands cursor.browserView.goBack/goForward have no key bound to them. Nothing you add to keybindings.json can override it.
The real bug is about focus. The listener only fires when the operating system still gives keyboard focus to the browser’s native view, even though the chat input looks focused. The browser is a separate native view on top of the window. When you click into the chat after using the browser, or after an agent drives it, native focus doesn’t always return to the main window. That’s also why Alt+Up and Alt+Down act on the browser page: they aren’t in that table, but they still reach the browser. Cursor has its own way to hand focus back: pressing Cmd+I while the browser is focused calls parentWindow.webContents.focus().
Steps to Reproduce
1 - Open the built-in browser and load any page. Click inside it (or move focus to the browser)
2 - Click into the Agent chat input and type some text.
3 - Press Alt+Left to move back one word.
Expected Behavior
The text cursor moves back one word in the chat input.
Operating System
MacOS
Version Information
Cursor 3.22.7
macOS 26.5.1
Does this stop you from using Cursor
No - Cursor works, but with this issue