In my case, the “pruebaworktrees” folder has its perfectly valid .git folder and I’m able to use the /worktree command from the Edit window to create new working worktrees
Do you also have a remote configured? Please make sure you do.
Another troubleshooting step is to disconnect and reconnect Github via cursor.com/dashboard → Integrations → GitHub → connect/configure.
Normally you shouldn’t have to do this but it might help Cursor to resolve/populate the repo metadata that the Agents Window uses to decide whether to display Worktree info.
The remotes were actually the problem. Having a remote makes the new worktree option appear… but I wonder why does this feature require remotes at all? git worktree doesn’t seem to require does it?
Awesome! Glad it worked. We are planning to resolve this so that the remote is no longer required to bring it in line with the expected git worktree behavior. But it’s a good workaround for now
Hey Alex! A “remote” is the link between your local git repo and a hosted version (on GitHub, GitLab, etc.). You can have a local repo without one — it just means nothing’s been pushed up yet.
Here’s the full flow:
Create a new empty repo on GitHub (don’t initialize it with a README) and copy the URL. You can set it to Private during creation if you don’t want it publicly visible.
In your project, check if a remote is already configured: git remote -v
If nothing comes back, add it: git remote add origin <your-repo-url>
(Optional, good practice but not required for the workaround to work) Push your code up: git push -u origin main
Once that’s done, the GitHub reconnection in Cursor should work as expected. Let me know how it goes