Possibly these are three unrelated issues, but I discovered all of them while trying to use the [Inspect Context Keys Utility Command][1] (See link 1 in reply post below… Discourse is preventing me from adding more than 2 links)
Issue 1: Inspect Context Keys - No Console Output
No expected context is output to the Developer Console when using Inspect Context Keys tool. Steps to reproduce:
Open the Developer Console (This is the Electron/Chromium Console accessed via Help → Toggle Developer Tools)
Press Ctrl+Shift+p to open the command palette.
Select or type the Developer: Inspect Context Keys command
The mouse cursor turns into a selection plus sign ＋, and UI elements are hilighted in red when hovered over.
Click on the text editor window (or any other) UI element to select the element to inspect context keys on.
Results:
Expected: The context keys for the selected UI element should be output to the Developer Console
Actual: No context output is printed in the Developer Console window.
Console logs for this issue: None (… because that’s the issue )
Issue 2: CORS Errors in Cursor’s Console Log
After opening Cursor, a CORS error can be seen in the Developer Console logs when it tries to access the API at https://api*.cursor.sh. Steps to reproduce:
Start Cursor app
Open the Developer Console (This is the Electron/Chromium Console accessed via Help → Toggle Developer Tools)
See the CORS error (visible when Cursor tries to make API requests):
workbench.html:1 Access to fetch at ‘https://api2.cursor.sh/auth/full_stripe_profile’ from origin ‘vscode-file://vscode-app’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.
workbench.desktop.main.js:21456
GET https://api2.cursor.sh/auth/full_stripe_profile net::ERR_FAILED 502 (Bad Gateway)
After opening Cursor, and working a while, the message is output to the logs:
workbench.desktop.main.js:450 [bc9] potential listener LEAK detected, having 202 listeners already. MOST frequent listener (8):
Steps to Reproduce: Unknown
It happened the first time I opened the Developer Console to try and use the Inspect Context Keys tool
I’ve yet been unable to find what actions cause this to happen again after restarting Cursor
Seems like it could be similar to the following issue on official VSCode: [microsoft/vscode#129527: Potential listener leak detected][2] See link [2] in reply post below (Discourse only allowed me 2 links) (… but that one was supposed to be fixed in 2021?)
I have to say though: Despite the above innocuous bugs… Overall, the experience when using Cursor is an improvement over the “official” alternative, GitHub Copilot! This is mostly thanks to their “Responsible AI Service” filtering requests in a seemingly random manner, actually degrading the AI pair programmer “Service”. Also, there are many issues in general with using GitHub Copilot on Linux distros that only ship VSCodium without much support for Microsoft’s Extension Marketplace, among other API proposals in product.json which keep breaking every time they update Copilot and/or VSCodium.
The AppImage distribution of Cursor seems to be a big improvement in the latter, simply because it ships everything in one package and supports https://marketplace.cursorapi.com/_apis/public/gallery out of the box, plus porting over all previously installed extensions & settings from VSCode / VSCodium.
I’m also experiencing issues 1 and 3 when I try to Inspect Context Keys. This is frustrating when trying to write new keyboard shortcuts. In particular, I’m having trouble with the AI side pane, which I now can’t get rid of since moving my cursor AI chat view container into the main side panel.
While I can’t comment on the first issue as I’ve never used inspect context keys before, the second issue regarding cause as well as the leak alert are both fine!
What is the use case for the Inspect Context Keys command?
It’s very useful for writing keyboard shortcuts. For example, specific keybindings only to be used when writing a prompt for composer/chat. Inspect Context Keys will inform how to isolate those keybindings.
While that should hypothetically be working, there may be some changes we have done building Cursor that have stopped this from working.
Unfortunately, this is probably not a high-priority issue so, while I will log it as an issue on our internal tracker, you may not see this fixed in any near-future updates.
Unlike VSCode, Cursor is a closed-source app, and we do not support the same level of debugging and development tools to look deeper into what Cursor is doing behind the scenes. While we don’t specifically disable or break any of these features, it’s unlikely that we would dedicate any resource to fixing or supporting some a feature without a highly requested use case!
That’s too bad! VS Code (and, you’d hope, its derivatives) being so customizable and accessible is a huge productivity boost. One of the strengths of a tool like Cursor could be fostering a vibrant support community where developers collaborate and enhance each other’s experiences. Access to debugging and development tools is a foundational part of that.
Also, some parts of the Cursor DX are currently very painful. Attempting to use readline keybindings in chat/composer blows away the in-progress prompt, wasting tons of time. I’d really love to be able to fine-tune that experience.
Effectively yes, this is the use-case for needing Inspect Context Keys feature. It helps to see what “context keys” are available when writing when clauses for Keyboard shortcuts. Without this feature, configuring keyboard shortcut bindings is much more difficult, because we’re essentially “flying blind” so to speak. While some of those “context keys” are documented, not all of them are and it becomes complicated to introspect when creating keyboard shortcuts that overload the same key bindings when in different “contexts”.
Some more info about this can be found at the following links:
Just want to add here that the context keys are very important when building extensions for VSCode / Cursor. They do not just expose editor internals but also state that extension authors set themselves to control visibility of commands etc.
It would let us do a much better job of supporting Cursor from the extension side. Something more to consider in terms of prioritization.
Why wouldn’t you just disable/remove the Inspect Context Keys command if it’s not planned to be exposed? Currently it’s completely unusable, and might waste users’ time trying to figure out where the problem is.
)