Adding Folder to Existing Workspace Bug - Cursor IDE

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Title: Add Folder to Workspace silently drops the new folder; agent root-move then fetches the wrong repo’s branch

Where: Cursor IDE / agent workspace (multi-root)

Error log (agent path, not GUI):

Failed to move agent root: Failed to checkout migrated branch “bugfix/scp_permission_denied_error”:
Command failed: git fetch origin +refs/heads/bugfix/scp_permission_denied_error:refs/remotes/origin/bugfix/scp_permission_denied_error --no-tags --recurse-submodules=no --no-write-fetch-head
fatal: couldn’t find remote ref refs/heads/bugfix/scp_permission_denied_error
Describe the bug

Two unrelated git repos, A and B (different remotes). Open a chat in A on a branch that does not exist on B (bugfix/scp_permission_denied_error in the log above).

GUI

File → Add Folder to Workspace → pick B → Save. The save dialog dismisses with no success toast and no error. The sidebar never shows B. Opening the workspace-folders UI again still lists one folder. B is gone. Save was offered as if the add would work; failure is silent.

Agent

The conversation stays bound to A. Asking the agent to move its root to B only runs git fetch origin <A’s branch> inside B and fails (log above). That fetch is wrong: B is not a clone of A.

Expected

After Save, B stays in the workspace. Sidebar and the folders UI both show A and B.
If the add cannot complete, show an error instead of offering Save and then dropping B.
Moving the agent to B must not fetch A’s branch from B’s remote. Rebind as multi-root [A, B], or fail with a message that A and B are different remotes.
Actual

GUI: add looks like it will save, then B is silently missing. Sidebar unchanged.
Agent: still on A. Root-move to B does a cross-repo fetch and errors.

Steps to Reproduce

Steps to reproduce

Open Cursor on a single git repo (folder A). Workspace has one folder. Sidebar shows only A.

File → Add Folder to Workspace and pick a second, unrelated git repo (folder B). Different remotes; B does not have A’s current branch.

When Cursor asks to save the workspace, save it. The dialog goes away with no success message (no toast, no confirmation).

Look at the sidebar: it still shows only A. B never appears.

Open the workspace-folders UI again. Still one folder. B was never added.

Expected: After save, the workspace has A and B. Sidebar and the folders UI both list two folders.

Actual: Save dismisses quietly. Nothing is added. No error. The extra folder is just gone.

Notes: Use two git remotes that are not the same project. Same-repo worktrees may not hit this.

Expected Behavior

Adding multi workspace should not be this hard.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.20.21
VS Code Extension API: 1.128.0
Commit: f09fca384ceca23f7bf21f9c23655b162641d740
Date: 2026-09-13T19:02:51.781Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report and the recording. It makes it clear what’s going on. There are two separate things here.

  1. Edit Workspace > Add Folder > Save on a project that has only one folder doesn’t update that project. It creates a new workspace next to it with two folders. Your chats stay on the old entry, so when you open Edit Workspace again it shows one folder, and in the sidebar you now see gac-automation-pipeline - 2/-3/-4 with No agents yet. Each Save created another copy. Nothing was lost, the new workspace just isn’t marked as the current one. This is a known issue we’re tracking, and I added your report to it. I can’t share an ETA yet.

How to work with both repos right now: click one of the gac-automation-pipeline - N entries. That one already has both folders. You can rename it via Edit Workspace on that entry. Then start New Agent there and pull the needed context from the old chat via @. You can remove extra copies via right click > Remove from Sidebar.

  1. Moving the agent to dev-pipeline fails because the move tries to check out the chat’s current branch bugfix/scp_permission_denied_error inside dev-pipeline, and that branch doesn’t exist on its remote. Moving an existing chat between two repos with different remotes isn’t handled right now. I passed this to the team so it’s either handled correctly or fails with a clear message instead of a git error.

Workaround, not guaranteed in every setup: ask the agent to move into a multi-root workspace where gac-automation-pipeline is listed first, for example: “Move this agent to a multi-root workspace with /Users/maharta/Development/Work/gac-automation-pipeline and /Users/maharta/Development/Work/dev-pipeline, in that order.” Let me know if it helped.