I’m opening this thread to request an update on an ongoing issue regarding proper Git worktree support in Cursor.
As noted in previous discussions, because Cursor struggles to parse the .git pointer file (as opposed to a standard .git folder), opening a worktree directly breaks several basic IDE capabilities:
Language Server (LSP) Features: Basic features like Find All References, Go to Definition, and formatting either fall back to limited modes or stop working entirely.
AI & Agent Features: File referencing in chat (@file), codebase context indexing, and AI code reviews fail or return incomplete results.
This is a known issue that has been raised a few times over the past year:
Since worktrees are an essential part of Cursor workflows, especially when running parallel AI agent tasks that I want to govern and observe, this continues to be a major blocker to using Cursor efficiently.
According to a comment in the April thread, a fix was currently in development. Could someone from the Cursor team provide an update on its progress or a general timeline for when we might see a fix?
For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)
For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…
Additional Information
Add any other context about the problem here.
Does this stop you from using Cursor?
Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue
The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!
The good news is that worktree support has moved a lot since that April thread, and the blanket “Cursor can’t parse the .git pointer file, so LSP and AI features break” description no longer matches current behavior on the latest versions (3.12.x). Opening a worktree directly now detects the repo, and codebase indexing and @file context work in it. So this is worth a fresh look rather than an “is it fixed yet” status.
A few specifics:
Using worktrees in the IDE (project window). The old Local/Cloud/Worktree dropdown was replaced with slash commands in the editor agent chat:
/worktree [branch=<name>] <task> creates a worktree and starts an agent in it
/apply-worktree merges the changes back into your main branch
/delete-worktree removes the worktree
/best-of-n <model1,model2,...> <task> runs the same prompt across multiple models in parallel
The one real, intentional limitation. For worktree agent workspaces inside the Agents Window, language servers are off by default. That is a deliberate performance choice, since running many parallel worktrees can spin up a lot of LSP processes. It is the most likely reason you would see Find All References / Go to Definition / formatting fall back to limited modes in a worktree today. You can turn it back on: open a file in that workspace and enable the LSP toggle for it (look for Enable LSPs for Worktrees under the workspace’s Code Intelligence / LSP settings).
If you want full language features right now, open the worktree as a regular editor window. For example, create it yourself with git worktree add ~/some/path and open that folder normally. Externally created worktrees are treated as first-class now, so you get the full language-server experience there.
We’re continuing to invest in worktree and LSP support, so I don’t have a specific ETA to share on the remaining Agents-Window pieces. If you retest on the latest build and still hit a specific flow that’s broken, could you reply with:
Your Cursor version (Help > About)
The exact flow (a worktree opened directly as a window vs. an Agents-Window worktree agent) and which feature (@file, Go to Definition, AI review, etc.)
A quick repro
That lets us track and fix the specific case rather than the general “worktrees are broken” bucket. Thanks!
I have been speaking mostly about the editor (IDE) window and it’s support, when opening a worktree directory.
After checking and verifying your solution, I’ve found out the following:
In the IDE the language server really do not start by default and require a restart
When opening files the editor chooses the language as the worktree equivalent (for example for Go, it chooses the language as Worktree Go by default) and that requires changing the language mode manually to allow actions such as see implementations and so on. But it’s per file and quite cumbersome
Inside the agents / chat sidebar, it does not support `@file` still, even after restarting the language server
all 3 of those are relevant to the following version info
I created the worktree initially from the agents window, and then went into it by clicking the “Editor ” to open the editor window, since then I also closed and re-entred to that same editor window directly from the IDE using the “File → Open Recent → XXXX”
I’ll try to see how I can reproduce it in a new project, and will update that thread
All three happen because that worktree lives under ~/.cursor/worktrees (created from the Agents Window), and Cursor treats anything there as a managed worktree workspace - opening it via “Editor ” or Open Recent keeps that mode. In that mode, language servers are off by default and @file is scoped to the owning agent, so a plain editor window won’t get full LSP or list those files (restarting the LSP won’t change the @file part).
Cleanest fix for full IDE features right now - use a standalone worktree outside ~/.cursor/worktrees:
git worktree add ~/dev/myproj-feature <branch>
then File → Open Folder on it. You’ll get normal language servers, language modes, and @file there.
If you want to stay in the Agents-Window worktree: turn on Enable LSPs for Worktrees in the LSP settings, then fully restart the window (that’s why a restart was needed).
On the “Worktree Go” language mode - I haven’t been able to pin that down on my side. If it shows up in your clean repro, a screenshot of the language indicator (bottom-right status bar) plus the version would help me get it tracked.
” to open the editor window, since then I also closed and re-entred to that same editor window directly from the IDE using the “File → Open Recent → XXXX”