Cursor version: 3.13.25 (VSCode base 1.128.0)
OS: macOS
The Source Control (SCM) panel shows zero changes for all repositories in a multi-root workspace, even though git status on the command line clearly shows modified files. This worked fine in a previous Cursor version and broke after updating.
Steps to Reproduce
Steps to Reproduce：
Open a multi-root workspace via a .code-workspace file with 4 folders, each an independent git repo (one folder is also the workspace root’s own repo; the other 3 are nested subdirectories with their own .git).
Make changes in one or more of the repos (confirmed via git status on the command line that real uncommitted changes exist).
Open the Source Control panel in Cursor.
Observe that the Changes list is empty, with no way to review or commit the actual changes.
Expected Behavior
The Source Control panel should list the changed files, grouped by repository, as it always did before.
In previous versions, I confirmed that the diff panel was grouped by repo, just like iShot_2026-07-30_13.31.37.png
Update: Found the root cause and a working fix, courtesy of the diagnosis in “Cursor not recognizing all of git repos within workspace” (agoodkind’s post there nailed it).
Cursor stores per-workspace SCM panel visibility in a SQLite DB:
All 4 repos were correctly detected in “all”, but “visible” only contained index 3 (the last repo, which happened to have zero uncommitted changes) — so the Changes panel rendered empty even though 3 other repos had real modified files. The Explorer git decorators still worked because that’s driven by a different code path.
Fix (do this with Cursor fully quit, Cmd+Q):
Find the storage folder for your workspace:
grep -l “your-workspace.code-workspace” ~/Library/Application\ Support/Cursor/User/workspaceStorage/*/workspace.json
Back up the db, then clear the bad key:
DB=“/state.vscdb”
cp “$DB” “$DB.bak”
sqlite3 “$DB” “DELETE FROM ItemTable WHERE key = ‘scm:view:visibleRepositories’;”
sqlite3 “$DB” “UPDATE ItemTable SET value = ‘{“closedRepositories”:}’ WHERE key = ‘vscode.git’;”
Reopen the .code-workspace file. Cursor regenerates the visibility key from scratch and all repos show up correctly again.
This confirms the underlying bug is state corruption in scm:view:visibleRepositories (the “visible” index array getting truncated/desynced from “all”), not a detection failure — the vscode.git extension is scanning and reading git status correctly the whole time. Hope this saves someone else the debugging time, and hope it helps the Cursor team pin down why “visible” gets desynced from “all” in multi-root workspaces.
Hey,
Your diagnosis is spot on: this is state corruption in scm:view:visibleRepositories inside state.vscdb, where the "visible" array gets truncated relative to "all". The Explorer decorators keep working because they’re driven by a different code path, exactly as you noticed. What you’re describing isn’t intended behavior, and it’s something we’ve seen before in multi-root workspaces with several nested repos - this is an issue we’re tracking. No timeline to share yet, but I’ll post here when there’s an update.
A couple of things worth adding:
The quickInputButtonLocation warning is a red herring. That API was promoted to stable and the leftover proposal declaration just logs a warning; the git extension is still fully active (your status-bar branch is proof of that). The warning is present in versions where SCM works fine too, so it isn’t the trigger.
Less-destructive recovery paths to try before touching SQLite:
In the Source Control view header, the ⋯ menu → View & Sort → Repositories, and re-check all repos. Enabling the Source Control Repositories section here also makes hidden repos easier to spot.
If those don’t stick, the SQLite steps you posted are the right fallback - the per-workspace state is what’s corrupted.
If you notice a specific action that triggers the desync (opening a particular folder first, moving folders around, worktrees, etc.), that would be very useful to share - pinning down the trigger is the main gap in what we know so far.
