Hey, thanks for the detailed report and the upstream links, that really helps with debugging. I can see the screenshot with empty squares instead of icons in the sidebar.
Yep, this is the same bug as in the upstream issue you linked. The scheme used to serve extension resources in Remote-SSH and WSL sessions isn’t marked as CORS-enabled, so Chromium blocks loading SVGs and fonts. I can reproduce it too.
A fix is already prepared and in the pipeline, it’ll ship in one of the next updates. I can’t share an exact ETA yet.
For now, a temporary workaround is running Developer: Reload Window. Ctrl+Shift+P then type Developer: Reload Window. This usually brings the icons back until you reconnect to the session.
I’ll follow up in the thread once the fix is in a release.
Hey, thanks for checking in. This is a known bug, we can reproduce it, and we’re tracking it internally. I can’t share an exact fix timeline yet.
For now, the workaround is the same: Developer: Reload Window via Ctrl+Shift+P then Developer: Reload Window. It usually brings the icons back until the next reconnect to the session.
Once I have something concrete on the fix, I’ll update the thread.
I’ve tried Developer: Reload Window workaround multiple times on different projects, but nothing was fixed for me. I’m on Cursor 3.9.16. So I can not confirm that this workaround works for me, because it doesn’t.
It is really annoying to search tooltips on empty sidebar.
Hey, thanks for getting back to me. I see the screenshot, blank icons in the sidebar with the “RapidAPI Client” tooltip.
Since Developer: Reload Window doesn’t help at all for you and the tooltips still show up, it sounds like a slightly different variant than the one in the thread. A couple quick questions so we don’t have to guess:
Open Settings and check workbench.activityBar.orientation. If it’s set to vertical, try switching it back to the default horizontal and see if the icons come back. This is a separate case, and Reload Window won’t fix it.
What connection type are you using Remote-SSH or WSL, and what’s your client OS?
About the original bug from the thread, it’s known, reproducible, and we’re tracking it, but I can’t share an exact ETA for a fix yet. Your case, based on your description, might have a different cause, so please try step 1 and tell me what you get.
Changing to vertical does not fix this. It looks the same on my side.
I’m also using Remote-WSL on Windows 11 but with Ubuntu 26.04.
There are errors like these in developer tools window.
Icons: workbench.html:1 Access to image at 'vscode-remote-resource://127.0.0.1:41639/stable-042b3c1a4c53f2c3808067f519fbfc67b72cad80/vscode-remote-resource?path=%2Fhome%2Flubo%2F.cursor-server%2Fextensions%2Fdonjayamanne.python-environment-manager-1.2.7-universal%2Fresources%2Flogo.svg&tkn=2e50efa0-833a-43c2-8cac-fa85fe13fdb5' from origin 'vscode-file://vscode-app' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: chrome, chrome-extension, chrome-untrusted, cursor-rpc-devtools, data, http, https, sentry-ipc, vscode-file, vscode-webview GET vscode-remote-resource://127.0.0.1:41639/stable-042b3c1a4c53f2c3808067f519fbfc67b72cad80/vscode-remote-resource?path=%2Fhome%2Flubo%2F.cursor-server%2Fextensions%2Fanthropic.claude-code-2.1.198-linux-x64%2Fresources%2Fclaude-logo.svg&tkn=2e50efa0-833a-43c2-8cac-fa85fe13fdb5 net::ERR_FAILED
Fonts: workbench.html:1 Access to font at 'vscode-remote-resource://127.0.0.1:41639/stable-042b3c1a4c53f2c3808067f519fbfc67b72cad80/vscode-remote-resource?path=%2Fhome%2Flubo%2F.cursor-server%2Fextensions%2Feamodio.gitlens-18.2.0-universal%2Fdist%2Fglicons.woff2&tkn=2e50efa0-833a-43c2-8cac-fa85fe13fdb5' from origin 'vscode-file://vscode-app' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: chrome, chrome-extension, chrome-untrusted, cursor-rpc-devtools, data, http, https, sentry-ipc, vscode-file, vscode-webview. vscode-remote-resource://127.0.0.1:41639/stable-042b3c1a4c53f2c3808067f519fbfc67b72cad80/vscode-remote-resource?path=%2Fhome%2Flubo%2F.cursor-server%2Fextensions%2Feamodio.gitlens-18.2.0-universal%2Fdist%2Fglicons.woff2&tkn=2e50efa0-833a-43c2-8cac-fa85fe13fdb5:1 GET vscode-remote-resource://127.0.0.1:41639/stable-042b3c1a4c53f2c3808067f519fbfc67b72cad80/vscode-remote-resource?path=%2Fhome%2Flubo%2F.cursor-server%2Fextensions%2Feamodio.gitlens-18.2.0-universal%2Fdist%2Fglicons.woff2&tkn=2e50efa0-833a-43c2-8cac-fa85fe13fdb5 net::ERR_FAILED
Thanks, those console errors actually make it clear. The block is coming from the vscode-remote-resource scheme, and that isn’t in the allowlist for cross-origin requests. That’s the same root cause as in the original report, it just shows up deterministically in your WSL case.
So we can rule out the workbench.activityBar.orientation idea. You’re hitting this exact bug, not a separate variant. And it’s expected that Developer: Reload Window doesn’t help here. That workaround only helps in the intermittent case, but in a WSL session the icons don’t come back.
This is a known bug, we can reproduce it, and we’re tracking it. I can’t share an exact fix timeline yet. Once the fix ships in a release, I’ll reply in the thread.
It’s been nearly 3 weeks and we still have no fix. This is getting beyond ridiculous.
The VSCode team fixed this in a single day and shipped in under a week. I have now watched several updates go by and each time hoped this would be the one, but nothing.
Also, censoring the slightest dissatisfaction on the part of your paying customers is definitely not going to make us feel any better about your tardiness in fixing obvious bugs. On the contrary, it makes VSCode with copilot look all the better.
I am using Windows Cursor → Anysphere Remote SSH 1.1.6 → Fedora remote workspace.
Symptom: Blank Activity Bar slot for DBCode (and likely other remote extensions). DBCode commands work via Command Palette.
Console (every session):
Access to image at ‘vscode-remote-resource://127.0.0.1:…/dbcode.dbcode-…/icon.svg’ … blocked by CORS policy.
Allowed schemes do NOT include vscode-remote-resource.
Hey, thanks for the details and the console errors. They make it clear what’s going on. This is the same bug as in that thread: the vscode-remote-resource scheme, which serves extension assets in remote sessions, isn’t marked as CORS-enabled, so Chromium blocks loading SVG icons and fonts. Your case is a deterministic version of the same issue, just like the users on WSL in the thread.
Just to set expectations, Developer: Reload Window doesn’t help in this case, so it’s not worth trying. The icons won’t come back after reconnecting to the session.
We’re aware of the bug, we can reproduce it, and we’re tracking it internally. I can’t share an exact fix timeline yet. Once the fix ships in a release, I’ll follow up in the thread.
