Archiving an agent deletes its dirty worktree without confirmation

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In the Cursor 3 Agents Window, Archive can remove a local worktree even when it contains substantial uncommitted changes. Cmd+Shift+E triggers Archive immediately with no confirmation. The conversation itself can be unarchived, but the deleted worktree and its uncommitted state are not restored with it.

Steps to Reproduce

  1. Start a local agent that is working in an isolated worktree.
  2. Let the agent make uncommitted changes in that worktree.
  3. In the Agents Window, press Cmd+Shift+E (also familiar as the Explorer shortcut in the IDE), or invoke Archive.
  4. The agent is archived immediately and its local worktree directory is removed.
  5. Unarchive the conversation. The previous worktree and its uncommitted files are not automatically restored.

I reproduced this accidentally twice.

Expected Behavior

If an agent has a dirty worktree, unpushed commits, or an active task, Archive should show a confirmation that clearly explains what will happen to the local workspace. Dirty changes should be preserved or safely snapshotted before teardown.

Ideally, Agents Window shortcuts should also be configurable so Archive can be remapped or unbound. Any Undo action should restore both the conversation and its worktree, not only make the chat visible again.

Operating System

MacOS

Version Information

Cursor 3.14.7 on macOS

Additional Information

In my concrete case, the worktree contained roughly 60 modified files and thousands of changed lines. The branch itself did not contain that uncommitted work. Recovery required reconstructing edits from Cursor’s agent transcript history, recreating the worktree, reapplying fixes, restoring local configuration, and rerunning verification. I had to do this twice; without the transcript cache, the work could have been lost.

This makes Archive a soft-delete at the conversation level but a potentially destructive teardown at the workspace level.

Cross-app shortcut behavior increases the chance of accidental activation: I regularly switch between Codex and Cursor, and Cmd+Shift+E does not perform a destructive or state-changing action in Codex.

Related discussions:

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report and repro steps. That’s a really painful scenario, especially with that much unsaved work. This shouldn’t happen when you archive. I’ve shared this with the team and we’re tracking it. I can’t share a timeline yet, but I’ll reply in the thread when there’s an update.

A couple things for next time to stay safe:

  • Commit or run git stash in the worktree before you archive the agent. That’s the most reliable way to make sure your changes are saved no matter what happens during teardown.
  • Note that unarchive only brings back the chat history. It does not restore a deleted worktree or any unsaved files in it, so it’s not a recovery option.
  • Keep in mind that Cmd+Shift+E in the Agents Window triggers Archive, not Explorer like in a normal editor. If you switch between Codex and Cursor a lot, it’s easy to hit out of habit. For the file tree in the Agents Window, use Cmd+G.

About remapping that shortcut in the Agents Window, custom keybinds aren’t supported there right now. That’s a separate request we’re also aware of. Let me know if you hit worktree loss again under other conditions.

7

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