Cursor-managed worktrees are treated as external when `~/.cursor` is symlinked to an external drive

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I’m reporting what looks like a bug or missing trust model around Cursor-managed worktrees when Cursor state is stored on an external drive via a symlink.

Setup

On macOS, I symlink ~/.cursor to an external SSD to save internal disk space:

/Users/nils/.cursor -> /Volumes/Kingston/Home/.cursor

This is a practical and useful setup, especially on laptops with limited internal storage.

Problem

When Cursor creates a worktree for an agent workflow, the worktree ends up under the symlink target, for example:

/Volumes/Kingston/Home/.cursor/worktrees/rocdown-block-b2a7a76e/rocci-48b990a65f45

Then, when the agent tries to edit files inside that worktree, Cursor shows Pending approval and blocks the write as if the file were an external path.

Example git worktree list:

/Users/nils/Projects/rocci                                                         2770f8f [main]
/Volumes/Kingston/Home/.cursor/worktrees/rocdown-block-b2a7a76e/rocci-48b990a65f45 2770f8f (detached HEAD)

Why this seems wrong

This is not an arbitrary external path chosen by the user during the task. It is a Cursor-managed worktree created by Cursor itself as part of the agent workflow.

The current behavior appears to resolve the symlink to /Volumes/... and then classify the worktree as external, even though from the user’s perspective it lives under ~/.cursor/worktrees and was created by Cursor for the current task.

Expected

One of these should happen:

  1. Cursor-managed worktrees under ~/.cursor/worktrees should be treated as trusted/internal even after symlink resolution.
  2. Cursor should provide a setting to trust Cursor-managed worktrees when Cursor data is stored on an external drive.
  3. Cursor should document that symlinking ~/.cursor to external storage is unsupported, if that is the intended behavior.

Actual

Agent edits inside the worktree require manual approval because the path resolves to an external volume.

That makes best-of-n / worktree-based workflows much less usable in a setup that is otherwise quite reasonable.

Related reports

This seems related to existing path-trust / external-path issues:

My case is a bit different from both of those: this is specifically about Cursor-created worktrees becoming untrusted because ~/.cursor itself is symlinked to an external drive.

Suggested fix

Please consider treating Cursor-managed worktrees as trusted based on their logical ownership (~/.cursor/worktrees / Cursor-managed storage), not only on their fully resolved filesystem path.

At minimum, it would help to have either:

  • a trust exception for Cursor-managed worktrees, or
  • a setting to allow external-drive-backed Cursor state/worktrees without per-edit approval prompts.

Why this matters

Storing Cursor state on an external SSD is a useful real-world setup. It saves space and should not make Cursor’s own worktree workflows effectively unusable.

If helpful, I can provide Cursor version, screenshots of the Pending approval prompt, and any other diagnostics.

Steps to Reproduce

Setup symlink to external SSD like described

Operating System

MacOS

Version Information

Version: 3.16.29 (Universal)
VS Code Extension API: 1.128.0
Commit: 6246455961129c32969845e00aa25d87ae926ec0
Date: 2026-08-18T01:26:26.285Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

For AI issues: which model did you use?

grok-4.6

Does this stop you from using Cursor

No - Cursor works, but with this issue

8

Thanks for the detailed writeup!

I reproduced it and confirmed that the worktree trust check compares the resolved path of the file being edited against an unresolved ~/.cursor/worktrees path, so when ~/.cursor is a symlink the two never match and every edit gets classified as out-of-workspace.

Worktrees under ~/.cursor/worktrees are meant to be trusted, so your expectation #1 is the intended behavior. I’ve filed this and shared it with the team.

In the meantime, if the reason you moved ~/.cursor to the external SSD is disk space, more aggressive worktree cleanup may let you keep it on the internal drive!