In a WSL remote workspace, all extension-provided icons (activity/view icons + icons inside extension UIs, plus extension icons) become squares or invisible after restarting Cursor. Built-in Cursor/VS Code icons remain fine. Disabling/re-enabling an extension (e.g. GitLens) temporarily fixes all extension icons until the next restart.
Steps to Reproduce
Open a WSL workspace (Remote WSL).
Install extensions with icon assets (e.g. GitLens, Todo Tree, etc.).
Icons are correct initially.
Close Cursor completely.
Reopen the same WSL workspace.
Observe: extension icons are broken (squares/invisible).
Disable + re-enable GitLens (or reinstall an extension) → icons become correct again until next restart.
With Cursor Agent help:
Hypothesis
Regression in Windows renderer scheme/protocol handling for vscode-remote-resource:// on startup (CORS + sometimes treated as unknown scheme), so extension SVG/WOFF2 assets from WSL don’t load after restart. Disable/reenable triggers a refresh that temporarily fixes it.
Workaround
Launching with --disable-features=OutOfBlinkCors makes it work, but that’s not an ideal long-term solution.
Ask
Can Cursor fix/allowlist/register vscode-remote-resource:// properly on startup for WSL so extension assets load without CORS / unknown-scheme failures?
Hey, thanks for the detailed report. The repro steps and your hypothesis really help.
This is a known class of issue. There’s a related thread where Windows users (not WSL) hit the same thing: extension icons (Claude, Codex, GitLens, etc.) disappear after a restart and come back after Developer: Reload Window: Some sidebar tab icons disappeared
In your case, the WSL layer adds the CORS / vscode-remote-resource:// angle, but the root cause is the same. extension icon resources don’t load correctly on startup.
For now, there are two workarounds:
Run Ctrl+Shift+P then Developer: Reload Window after each restart (fastest)
Keep using your --disable-features=OutOfBlinkCors flag (more permanent, but not ideal)
I’ve passed this to the team. No ETA yet, but your CORS and protocol details help us prioritize it. I’ll post an update here if there’s news.
If you’re still hitting it, please share your Cursor version and your WSL distro. I’ll move it to the right team as a separate issue about a startup race in protocol registration (the old ticket linked to this thread was closed without a fix). If you can’t reproduce it on the current version, let me know too and I’ll close the thread.
It’s still happening in Cursor 3.2.11. I removed the GitLens extension (as wasn’t really using it in the end) but it still happens (normal since it’s a Cursor issue not a GitLens one). My WSL instance is Ubuntu too, running in Windows 11.
Version: 3.2.11 (user setup)
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
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
OS: Windows_NT x64 10.0.26200
Thanks for confirming and for the info about your version and distro. I can reproduce this on 3.2.11 on Ubuntu WSL.
The old related issue was closed without a fix, so I’ll open a new, narrower ticket specifically for this startup race around registering vscode-remote-resource:// in WSL, and I’ll attach your report plus a similar one from Extentions icons don't load under the extention tab on the sidebar. I’ll post an update here once I have one.
For now, as a workaround, either run Ctrl+Shift+P then Developer: Reload Window after restart, or use your --disable-features=OutOfBlinkCors flag.