Cursor IDE Keyboard Not Working

[paolocarroll]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Update: the actual issue is less the performance but actually a keyboard issue that’s caused by the newly released browser stuff. Please see post’s comments.

–

The most recent upgrade of the IDE feels like it is less performant and is tanking my laptop (services running locally now failing due to memory).

I’ve force-quit everything else running locally & not much has changed with our app in the last week.

My laptop: Apple M3 Pro, 36GB Memory, plenty of storage available

Steps to Reproduce

Run the IDE with other services

Expected Behavior

Run well without memory issues

Operating System

MacOS

Version Information

Version: 2.4.21
VSCode Version: 1.105.1
Commit: dc8361355d709f306d5159635a677a571b277bc0
Date: 2026-01-22T16:57:59.675Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Darwin arm64 25.2.0

Does this stop you from using Cursor

Yes - Cursor is unusable

[paolocarroll]

I also have some weird behavior happening where, in the IDE, certain keyboard commands don’t work. Like arrow keys. (If I reload my IDE window, it goes back to working).

[paolocarroll]

this is actually an extremely annoying bug that I believe is caused by cursor

Summary: This is a Cursor bug where the AI chat/composer webview retains focus invisibly. When it happens, press Escape or Cmd+1 to recover. You may want to report this to Cursor’s team (forum.cursor.com or their Discord) since it’s a recurring issue.

–

2026-01-26 18:19:51.359 [info] [Window] [KeybindingService]: | Resolving [ArrowDown]

2026-01-26 18:19:51.359 [info] [Window] [KeybindingService]: \ From 25 keybinding entries, matched cursorDown, when: textInputFocus, source: built-in.

2026-01-26 18:19:51.360 [info] [Window] [KeybindingService]: + Skipping keybinding dispatch because browserViewFocused is true

2026-01-26 18:19:51.492 [info] [Window] [KeybindingService]: / Soft dispatching keyboard event

2026-01-26 18:19:51.493 [info] [Window] [KeybindingService]: | Resolving [ArrowDown]

2026-01-26 18:19:51.493 [info] [Window] [KeybindingService]: \ From 25 keybinding entries, matched cursorDown, when: textInputFocus, source: built-in.

2026-01-26 18:19:51.493 [info] [Window] [KeybindingService]: / Received keydown event - modifiers: [], code: ArrowDown, keyCode: 40, key: ArrowDown

2026-01-26 18:19:51.493 [info] [Window] [KeybindingService]: | Converted keydown event - modifiers: [], code: ArrowDown, keyCode: 18 (‘DownArrow’)

2026-01-26 18:19:51.493 [info] [Window] [KeybindingService]: | Resolving [ArrowDown]

2026-01-26 18:19:51.493 [info] [Window] [KeybindingService]: \ From 25 keybinding entries, matched cursorDown, when: textInputFocus, source: built-in.

2026-01-26 18:19:51.493 [info] [Window] [KeybindingService]: + Skipping keybinding dispatch because browserViewFocused is true

[paolocarroll]

yep - seems like it’s some issue cased by the cursor browser?

[deanrie]

Hey, I can see you’ve already dug deep into the issue. Yep, this is a confirmed bug in state management: the browserViewFocused flag gets stuck on true even after focus returns to the editor.

Root cause:
The internal flag isn’t reset after interacting with the AI webview (composer/chat panel). document.activeElement shows the correct element (the editor textarea), but keybinding dispatch still gets blocked.

Trigger: It usually happens when opening or closing the AI composer (Cmd+I) or the chat panel.

The team is aware, but it needs a fix in the core focus management, so it’s not a quick one. Your detailed report with logs will definitely help with prioritization.

[Nathan_Hettige]

Happening to me too, this is super annoying, along with the prettier issues earlier this month. Reconsidering my choice of editor right now.