WSL branch list does not load, cannot use “Link to master”
Steps to Reproduce
Description
In a WSL project, the branch selector in Cursor stays on “Loading branches…” indefinitely.
As a result, the workspace shows “No branch linked”, and “Link to master” cannot be used successfully.
Hey, thanks for the detailed report with screenshots. I can see that in tms-docs on WSL ubuntu-24.04 the branch picker is stuck on “Loading branches…” and because of that “Link to master” is unavailable.
This is a known bug with the Glass branch switcher on remote extension hosts like Remote-SSH and WSL. cursor-retrieval sometimes doesn’t manage to register the git context provider before an internal timeout, and the UI stays on “Loading branches…” with no auto-retry. I’ve reported your case internally as an extra data point for WSL. No ETA for a fix yet.
Workarounds to try:
Reload Window: Ctrl+Shift+P then “Developer: Reload Window”. This sometimes restarts the remote extension host and the branches load.
Check that git branch runs fast on the WSL side. Run time git branch -a in the terminal inside WSL. If the command itself is slow, the timeout will hit that.
If it reproduces consistently after reload, let me know. Also share the approximate number of branches using git branch -a | wc -l, it helps confirm whether repo size affects the timeout.
Same issue. Reload window does not help. And the WSL sessions imported from the editor window are all under “ubuntu”, while the ones opened in agents view are under “Ubuntu” or wsl.localhost which is somewhat confusing. The branches list fine from the editor window just not in the agents window. Same on a new repo with only one branch as it is on repos with lots of branches. Tbh it’s not clear to me what selecting the branch does either, as I may use multiple branches during the chat session. Unless it’s related to worktrees somehow.
Hey, thanks for the extra details, that really helps. Confirming that in the Agents Window this is the same bug with the Glass branch switcher on remote extension hosts (WSL/SSH) as in the OP, and the fact that the Editor window loads the same branches fine matches the root cause. It’s an issue with how the Agents Window works with the remote git context provider, and the classic VS Code git path isn’t being used. I also passed along that reload doesn’t help and it repros even on a repo with a single branch, that’s a useful signal.
The mismatch in how WSL hosts are shown (“ubuntu” in the editor vs “Ubuntu” / wsl.localhost in the agents view) looks like a separate UI inconsistency. I logged that separately too, thanks.
About branch linking: it’s not directly about worktrees. A linked branch sets the base branch for the workspace in the Agents Window. It’s used as the reference in the diff view and when comparing an agent’s changes. In the chat, the agent can still switch branches on its own. The link just pins the UI reference point. Worktrees are a separate mechanism and are picked when starting a specific agent.
No ETA on the branch loading fix yet. Once I have an update, I’ll post it in the thread.
Hey, thanks for the +1. I added your report as another data point to the existing issue. This is a known bug with the Glass branch switcher on remote extension hosts like WSL and SSH, and we don’t have a fix timeline yet. Once there’s an update, I’ll post it in the thread.
If you want to help with diagnostics, please share your Cursor version, your WSL distro, and whether Developer: Reload Window via Ctrl+Shift+P helps. Also, if you can reproduce it in a repo with only one branch, that’s a useful signal too.
+1 exact same issue.
And Reloading Window didn’t help. And the issue is reproducible with repo with single branch too
Cursor Version: 3.3.4
WSL version: 2.6.3.0
Hey, thanks for the +1. This is the same known bug with the Glass branch switcher on remote extension hosts WSL/SSH, which the rest of this thread is tracking. There’s no ETA for a fix yet, we’ll post here as soon as we have news.
If you can help with debugging, a few quick questions:
Does Developer: Reload Window in Ctrl+Shift+P help, even temporarily?
Can you reproduce it in a fresh repo with a single branch?
Inside WSL, what do you get from time git branch -a?
Also noting your version 3.3.16 Early Access, this confirms the issue still reproduces on the latest build.
(in the editor window, agents window still doing the same thing. and this seems to be a recent regression in the nightly when running local commands. Could be my local environment too not sure. but this issue is what is preventing me from using the agents window)
It’s still running after 30 seconds, which is unusual for git branch -a. I’m going to check whether it finishes shortly so I can give you the elapsed time.
It ran successfully.
git branch -a | grep main reported:
main
remotes/glab-base/main
remotes/origin/HEAD -> origin/main
remotes/origin/main
Plus several other branch names containing main.
Measured command time: 0.020 seconds.
The overall terminal job took about 61.49 seconds, with this startup message before the output:
pyenv: cannot rehash: /home/[me]/.pyenv/shims/.pyenv-shim exists
Hey Jason, thanks for grabbing that timing data. It’s actually a useful signal. About 6 ms means git itself isn’t the bottleneck, so the 10 s timeout isn’t happening because git is slow. Instead, it’s because the cursor-retrieval git context provider isn’t registering on the remote extension host at all. Same root cause as the rest of the thread.
Reload Window not helping also matches what other users reported here. No ETA on the fix yet. We’ll post in the thread once there’s an update.
Two quick things that would help:
Cursor version from Help > About, and your WSL distro and version from wsl -l -v in PowerShell
Does this repro on a brand new repo with a single branch too, or only on existing repos?
Thanks for sharing the version and for testing on a fresh repo, that’s exactly what we wanted to confirm. A repro on a single-branch fresh repo fully rules out any dependency on repo data. The issue is that the cursor-retrieval git context provider isn’t registering on the remote extension host in time. It’s the same root cause this thread is tracking.
+1 for this issue, it’s the main reason I cannot use the new Agents Window feature. Would love to give it a shot, but it’s been broken for a few weeks now.
