Cursor IDE Fails to Detect Git Worktrees

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor IDE Fails to Detect Git Worktrees

Summary

Cursor IDE does not detect Git repositories when opened in a Git worktree directory, even though:

  • Git command line works perfectly
  • VS Code detects and works with the same worktree correctly
  • The worktree is properly configured

Environment

  • OS: macOS 25.2.0 (darwin)
  • Cursor Version: 2.2.44
  • Git Version: 2.51.0
  • Git Path: /opt/homebrew/bin/git

Steps to Reproduce

  1. Create a Git worktree: git worktree add <path> <branch>
  2. Open the worktree directory in Cursor IDE
  3. Observe that Source Control panel shows “The folder currently open doesn’t have a Git repository”
  4. Try to initialize repository (which would break the worktree)

Expected Behavior

Cursor should detect the Git worktree repository and enable Source Control features, just like VS Code does.

Actual Behavior

  • Source Control panel shows “no Git repository” message
  • Git extension initial scan finds 0 repositories
  • Git commands work fine from command line in the same directory
  • VS Code works correctly with the same worktree

Git Extension Log Evidence

From vscode.git.Git output panel:

[Model][doInitialScan] Initial repository scan completed - repositories (0), closed repositories (0), parent repositories (0), unsafe repositories (0)

Despite many git rev-parse --show-toplevel commands being executed successfully.

Worktree Configuration

  • Worktree Path: /path/to/worktree-directory
  • Main Repository: /path/to/main-repository
  • .git file contents: gitdir: /path/to/main-repository/.git/worktrees/worktree-name
  • Git top-level: /path/to/worktree-directory (verified via git rev-parse --show-toplevel)

Attempted Solutions

Tried the following settings in .vscode/settings.json (none resolved the issue):

  • git.enabled: true
  • git.autoRepositoryDetection: true
  • git.detectWorktrees: true
  • git.openRepositoryInParentFolders: "always"
  • git.path: "/opt/homebrew/bin/git"
  • git.scanRepositories: ["/path/to/worktree-directory"]

Comparison with VS Code

VS Code (version 1.106.3) correctly detects and works with the same Git worktree without any special configuration.

Impact

This is a significant issue for developers using Git worktrees, as:

  • Source Control features are unavailable
  • Cannot use Cursor’s Git integration
  • Must use command line or switch to VS Code for Git operations
  • Workaround of initializing repository would break the worktree setup

Additional Context

This appears to be a known issue based on forum discussions, but no official fix has been provided. The Git extension’s initial repository scan is not properly detecting worktrees that use a .git file (instead of .git directory) pointing to the main repository’s worktree directory.

Steps to Reproduce

  1. Create a Git worktree: git worktree add <path> <branch>
  2. Open the worktree directory in Cursor IDE
  3. Observe that Source Control panel shows “The folder currently open doesn’t have a Git repository”
  4. Try to initialize repository (which would break the worktree)

Expected Behavior

Cursor should detect the Git worktree repository and enable Source Control features, just like VS Code does.

Screenshots / Screen Recordings

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.2.44
VSCode Version: 1.105.1
Commit: 20adc1003928b0f1b99305dbaf845656ff81f5d0
Date: 2025-12-24T21:41:47.598Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.2.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

2 Likes

this affects me as well

1 Like

Having same issue here

Hey, thanks for the report.

This is a known issue. Cursor doesn’t correctly detect Git repositories in worktree directories when .git is a pointer file (not a folder). The Git extension scans repos, but it can’t properly handle the worktree setup.

The team is aware of the issue. I’ll add your report to help raise the fix priority.

A similar issue was discussed here: Agent Review fails in Git worktree with multi-root workspace

1 Like