Git Graph + Agent: multi-root workspace uses first folder only

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have several sibling git repos (childA, childB, childC) under one parent directory. I open a multi-root workspace from that parent, with each child listed in folders.

When I do that, only the first entry (childA) is treated as the effective workspace root:

Agent write access works only in childA (source files and .git). I can read the other repos, but writes fail.
Git Graph commit details work only when I click commits belonging to childA. Clicks on childB / childC nodes fail to load commit info.
Workaround: add a prefix folder { “name”: “parent”, “path”: “.” } as the first entry. That restores agent write access across all children, but breaks Git Graph commit inspection for every child repo — git show runs from the parent path, which is not a git repository.

Steps to Reproduce

  1. Create a parent directory with three sibling git repos, e.g. parent/childA, parent/childB, parent/childC (each with its own .git and at least a few commits).
  2. Create parent/parent.code-workspace:
    {
    “folders”: [
    { “path”: “childA” },
    { “path”: “childB” },
    { “path”: “childC” }
    ]
    }
  3. Open that workspace in Cursor (File → Open Workspace from File…).

Bug A — Agent git access + Git Graph details broken for all but first repo

  1. In Agent mode, ask the agent to create or edit a file in childB (or run git status / git commit there).

  2. Observe: read works; write fails (Operation not permitted or similar).

  3. Repeat for childC — same result.

  4. Repeat for childA — write succeeds.

  5. Open Git Graph (or Source Control graph) for childB.

  6. Click a commit node that belongs to childB.

  7. Observe: commit details fail - error text shown in tab

  8. Click a commit node in childA’s graph.

  9. Observe: commit details load correctly.

Bug B — Parent prefix workaround breaks Git Graph for all children

  1. Edit the workspace to put a non-git parent first:

{
“folders”: [
{ “name”: “parent”, “path”: “.” },
{ “path”: “childA” },
{ “path”: “childB” },
{ “path”: “childC” }
]
}
14. Reload the window.
15. In Agent mode, edit a file or run git in childB / childC — writes should now succeed.
16. Open Git Graph for childA, childB, or childC.
17. Click any commit node in any of those graphs.
18. Observe: commit details fail - error text shown in tab

Expected Behavior

Cursor should switch cwd to childX depending upon the repo where the activity is occurring, there should be no need for a paren entry in the workspace folders list.

Operating System

MacOS

Version Information

Version: 3.7.36 (Universal)
VS Code Extension API: 1.105.1
Commit: 776d1f9d76df50a4e0aeca61819a88e7c1b861e0
Date: 2026-06-13T00:31:56.287Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Both halves of this are known limitations with multi-root workspaces, and the Git Graph half in particular is something we’ve already confirmed.

The most reliable workaround today is to open each repo in its own Cursor window (point Cursor at the repo root rather than the parent folder). That clears both symptoms at once: Git Graph commit details load because the window’s root is the actual git repo, and agent writes work because there’s no multi-root root to fall outside of.

You’ve already found the catch with the parent-prefix approach: adding { "path": "." } as the first folder restores writes but then breaks Git Graph for every repo, since commit lookups run from the non-git parent. So it trades one issue for the other rather than solving both.

One thing that would help us pin down the write-access half: when writes fail in childB/childC, are you seeing a hard “Operation not permitted” error, or an “Allow all edits in…” approval prompt? Those two point to different underlying causes, so knowing which one you hit lets us route it correctly.

7

Unfortunately, I require consistent actions applied over all of these repositories informed by common context. So, having separate chats/agents for each repository defeats this purpose.

8

For that workflow, the parent-prefix layout is the one to keep. With { "path": "." } as the first folder, you get a single workspace, one chat with every repo in context, and agent writes landing across all the children. You already confirmed that part works. The parent folder becomes the effective root, so the children sit inside it and stay writable.

The only thing it gives up is Git Graph commit inspection, since commit lookups then run from the non-git parent. When you need a specific repo’s history, the terminal is the reliable path:

git -C childB log
git -C childB show <commit>

git -C always runs against the repo you point it at, so it sidesteps the first-folder fallback entirely. If you’d rather use the graph UI for a deeper dig, briefly opening that one repo in its own window still works.

Both halves are known issues we’re tracking, and I’ll update this thread if that changes.