When an extension opens the Settings UI via workbench.action.openSettings with a search query, the Settings tab opens but hangs while applying the filter. It shows the unfiltered settings list with the filter text present in the search box, but never finishes filtering. Waiting it out can eventually render (sometimes after several minutes), but in practice it’s a hang. The identical extension code works instantly in VS Code.
Reproduces with: my extension “Speedy Git” calling workbench.action.openSettings with a query argument. My extension is Speedy Git (onlineeric.speedy-git-ext).
Steps to Reproduce
From an extension, run:
vscode.commands.executeCommand(‘workbench.action.openSettings’, ‘speedyGit’);
// also reproduces with an @id query:
vscode.commands.executeCommand(
‘workbench.action.openSettings’,
‘@id:speedyGit.dateFormat,speedyGit.dateFormatCustom’
);
The Settings tab opens with the query text in the search box.
The page hangs — settings are shown unfiltered and the filter never applies (UI is effectively frozen for minutes).
Expected Behavior
Settings opens filtered to the query immediately, as it does in VS Code.
Hey, thanks for the detailed report. The repro steps and the link to the old thread help a lot. This doesn’t look like a one-off. The same trigger showed up on Cursor 2.5 too, so I’m tracking this as an ongoing bug.
I haven’t been able to reproduce it on my side yet, so a CPU profile would help pinpoint where it’s hanging. Important: start recording before you trigger the freeze.
Since this likely happens during extension activation, please start with an Extension Host profile:
Cmd/Ctrl+Shift+P > Developer: Start Extension Host CPU Profiler
Reproduce the freeze. Open Settings from the extension with a request
Hit stop. You’ll get a save file dialog
A renderer profile is also useful, since the Settings UI freeze happens there, via DevTools:
Developer: Toggle Developer Tools > Performance tab > Record
Reproduce the freeze
Hit Stop > Download to save the file to disk
Attach the files here. They’ll show the hot path. I’ll post an update in the thread once I have one.
This time I tested in another laptop, please check this environment:
Version: 3.7.42 (system setup)
VS Code Extension API: 1.105.1
Commit: 5702c9cfca656d8710fad58402fe37f14345e3a0
Date: 2026-06-15T19:39:42.738Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200
To get this log, I tested first time, Cursor was completely hanged, I waited 30 mins and killed the Cursor app. Then I try again, this time it is a good reproduced case, it just hanged for less then 30 seconds, may be 10 to 20 seconds, attached files are from this second test case.
Hey, thanks. The profiles and console log were exactly what we needed. They helped us pinpoint where the freeze happens.
The hang isn’t in your extension or in the settings search logic. It’s in our IPC serialization layer on the way back. When Settings opens with a prefilled request, while serializing the response the renderer main thread goes into a tight loop over a large object graph (serializeReplyOK). At the same time, the error from your console log shows up: Method not found: toJSON. The large amount of data plus that exception is what causes the UI to freeze for seconds or even minutes. In VS Code, the openSettings response doesn’t go through this serialization path, so it opens instantly. So this is a regression on our side.
You don’t need to do anything else. The info you shared is enough, and I’ve captured the details for the team. I can’t share an ETA yet, but I’ll post an update in the thread when I have one.
If you want a temporary workaround, open Settings without a request (workbench.action.openSettings with no argument) and apply the filter after it opens. As you noticed, that path doesn’t hang.