On every startup when opening a project in WSL2 (Ubuntu) from cursor ., the workbench console shows:
Unable to create workbench contribution 'remoteTerminalBackend'. Error: A terminal backend with remote authority 'wsl+ubuntu' was already registered.
[LocalProcess1][resolveAuthority(wsl,1)][~2660ms] returned an error
This happens even with cursor --disable-extensions . (user extensions ruled out). Only Anysphere remote extensions are installed (anysphere.remote-wsl, anysphere.remote-ssh); Microsoft ms-vscode-remote.remote-wsl is NOT installed.
After clearing workspace storage (Windows %APPDATA%\Cursor\User\workspaceStorage\* and WSL ~/.cursor-server/data/User/workspaceStorage/*), repeated [UriError]: path must begin with a slash errors stopped, but the two errors above still appear every launch.
Steps to Reproduce
Confirm only Anysphere WSL extensions are installed: cursor --list-extensions → anysphere.remote-wsl, anysphere.remote-ssh only (no ms-vscode-remote.remote-wsl).
Do NOT import VS Code extensions into Cursor.
Quit all Cursor windows (Task Manager: no Cursor.exe left).
In PowerShell: wsl --shutdown
In WSL: cd ~/dev/HOSPO && cursor .
Open DevTools (Help → Toggle Developer Tools) → Console.
Observe errors (1) and (2) in “Describe the Bug” on every startup.
Optional stricter repro:
8. Quit Cursor again, then: cursor --disable-extensions .
9. Same errors still appear in DevTools.
Expected Behavior
WSL remote should initialize once: resolveAuthority(wsl) succeeds without error, and remoteTerminalBackend for wsl+ubuntu should be registered only once. The workbench console should not show “already registered” or resolveAuthority errors on a normal cold start.
Hey, thanks for the detailed report. The troubleshooting was really thorough, and extra thanks for ruling out MS remote-wsl, running --disable-extensions, and clearing workspaceStorage.
This is a known kind of remote terminal startup noise. We see the same remoteTerminalBackend already registered error on Remote-SSH too, and we’re tracking it. It’s basically a race during remote backend init at startup. The first resolveAuthority(wsl) attempt fails, then the connection comes back on retry, which is why editing and the terminal still work. Those two console lines are annoying, but in practice they aren’t fatal. I’ve filed an internal report specifically for the WSL case. I can’t share a fix timeline yet.
One quick question: do you see any real functional impact on the Agent or indexing, like tools hanging, indexing never finishing, or the agent terminal not returning output, or is it only console errors with no visible issues? If something is actually broken, tell me exactly what fails, it’ll help us understand how deep the race goes.
Thanks for the follow-up and for filing the internal WSL report.
To answer your question: for me it’s mostly console noise with no consistent functional impact.
Editing and the integrated terminal work normally after startup.
Agent / Composer generally work for me; I haven’t seen tools hanging or the agent terminal failing to return output on a regular basis.
Indexing appears to complete (I haven’t noticed it stuck forever).
After clearing workspaceStorage, the repeated UriError spam stopped; what remains on every launch is mainly the two lines you mentioned (already registered + resolveAuthority(wsl)).
Occasionally I see [composer] No first token received within 2s in the console, but it usually recovers on retry. Not blocking, but worth noting.
So day-to-day usage is fine, but the console errors on every cold start are confusing when debugging other issues. Happy to provide more logs if you need them for the WSL race case.
Thanks, this is exactly the confirmation we needed. Since editing, terminal, Agent, and indexing are working normally, and on each cold start you only see those two console lines already registered + resolveAuthority(wsl), that matches our assessment. It’s just noise during remote backend init, not fatal. The WSL case is logged, but I can’t share a fix timeline yet. If there’s an update, I’ll reply here.
About [composer] No first token received within 2s, that’s a separate issue and not related to the WSL race. It’s about the first token in the streaming response, and since it recovers on retry, it’s most likely a network or latency factor. If it starts happening more often or becomes blocking, please start a separate thread with the Request ID from that session. You can get it via Chat menu in the top right > Copy Request ID. That’ll make it easier to investigate this symptom separately from the terminal noise.
Thanks for offering logs. If we need anything specific for the WSL case, I’ll ask here.