Setting up the worktrees.json is useless in a WSL environment, I’ve seen a couple of auto closed threads about it already, any ETA about a fix for this?
Steps to Reproduce
In WSL2 in a repo with known setup steps (like installing pnpm deps) use the new chat to create a single one inside a worktree, should not matter if it’s from main or develop.
This is what my current .cursor/worktrees.json looks like:
Hey, thanks for the report. This is a known issue. worktrees.json isn’t detected in remote environments like WSL, SSH, or devcontainers. The root cause is that the agent uses a file:// URI to check if the config exists, and that doesn’t work in a remote context.
You found the right threads, it’s the same issue. A partial fix for path resolution shipped in 2.1.26, but it only solved part of it, like backslashes in paths. The actual config lookup still doesn’t work in WSL or SSH.
The team is aware of the bug. Unfortunately there’s no workaround yet, so setup scripts in worktrees won’t work in WSL until this is fixed. We’ll update the thread when there’s news.
Hey, I see the screenshot. This is related to changes in Cursor 3.0. Worktrees now work via slash commands: /worktree and /best-of-n, not via the dropdown like before. Details here: Cursor 3: Worktrees & Best-of-N
About the original worktrees.json bug on WSL: the team is aware, but there’s no ETA yet. The file:// URI issue in remote environments still applies, so setup scripts in worktrees on WSL won’t work for now.
I’ll keep the thread open. Let me know if the /worktree command at least starts on WSL, even without setup scripts.
The issue I find with the /worktree command is that it scopes down the current message to that worktree but after that I’m not sure it does for the whole session, it might end up doing the changes on my current default base worktree (the original one where I cloned the repo) if I’m not careful with how I phrase follow up changes.
Just as I suspected, sometimes when I ask the agent to do more work in the same agent, it goes and does it in the base worktree, not in the one created at the start, I have to constantly remind it to use the worktree.
Thanks for the extra info. The agent switches back to the base worktree instead of staying in the one created via /worktree. This is a known bug, so it’s not just you. The team is aware of the worktree isolation issue.
For now, the workaround is to explicitly remind the agent of the worktree path in follow-up messages, which you’re already doing. It’s not ideal, but there isn’t another option yet.
If you can, please send the Request ID from a session where the agent switched back to the base worktree. You can find it in the chat menu in the top right > Copy Request ID. This will help the team debug.
For the original worktrees.json bug on WSL, there’s no change. The file:// URI issue is still relevant. No ETA yet.
