Archiving an agent deletes its worktree immediately

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Archiving an agent that is bound to a git worktree triggers WorktreeArchiveCleanup, which removes the on-disk worktree shortly after archive — often within ~30 seconds, even when the worktree is currently open as a workspace folder (after “jump to worktree” / move agent into the checkout).
This contradicts the Worktrees docs, which describe cleanup only via cursor.worktreeCleanupIntervalHours and cursor.worktreeMaxCount, and prior staff guidance that archive does not directly delete worktrees.

Steps to Reproduce

  1. Create a git worktree under Cursor’s managed root, e.g. ~/.cursor/worktrees/<repo>/<id>/ (via Agents Window /worktree, or git worktree add to that path).
  2. Run an agent against that worktree (or use jump to worktree / move agent into the checkout so the workspace folder is the worktree path).
  3. Make uncommitted changes in the worktree (optional but makes impact obvious).
  4. Archive the agent (Cmd+Shift+E in Agents Window, or archive from the agent list).
  5. Observe the worktree directory is removed within ~30 seconds.

Expected Behavior

  • Archiving should hide the chat only and leave the worktree on disk until:
    • the user explicitly runs /delete-worktree or git worktree remove, or
    • scheduled cleanup (interval / max-count) runs per docs.
  • If archive-triggered cleanup is intentional, it should never delete a worktree that is open as the active workspace folder, and should require confirmation when there are uncommitted changes.

Operating System

MacOS

Version Information

Version: 3.14.7
VS Code Extension API: 1.128.0
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Date: 2026-07-30T06:41:34.009Z
Layout: Agent Window
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

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey there! Thanks for the detailed report. You’re right this shouldn’t happen, and it’s an issue we’re tracking.

The reliable way to stay safe until it’s fixed: commit or git stash push -u in the worktree before archiving (the -u grabs untracked files too). Once your work is on a branch or stash, archive can’t take it. Also note Cmd+Shift+E in the Agents Window is Archive, not Explorer, so it’s easy to hit by habit, use Cmd+G for the file tree. Unarchiving restores the chat but not a removed worktree, so committing first is the key.

There’s an existing thread following this same behavior, so I’ll merge yours into it and post updates there: Archiving an agent deletes its dirty worktree without confirmation.