/worktree and /apply-worktree should not require sandbox permission approvals

Ideas Feature Requests
, ,
1

Feature request for product/service

Cursor IDE

Describe the request

The old Editor-based worktree UI (deprecated in Cursor 3.0) handled worktree creation and apply natively with zero permission prompts. The replacement /worktree and /apply-worktree slash commands delegate to the agent’s shell tool, which triggers sandbox approval dialogs because ~/.cursor/worktrees/ is outside the workspace. This means every worktree lifecycle (create, apply, delete) requires 2-3 manual approval clicks for operations that Cursor itself initiated via its own commands.

Either:

  1. Automatically allowlist ~/.cursor/worktrees/ in the sandbox for shell commands triggered by /worktree and /apply-worktree, or
  2. Handle these commands natively (like the old UI did) rather than routing through the sandboxed agent shell

The slash commands replaced a zero-friction UI with a multi-approval workflow. For users with custom worktree skills that extend the built-in commands, this compounds — each step in the lifecycle prompts for approval.

Related: Sandboxing blocks access to the .git file of a git worktree

Operating System (if it applies)

MacOS

Worktree commands cannot be safely whitelisted