Bugbot "Fix in Cursor" doesn't resolve repositories inside a multi-root workspace

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

I use a .code-workspace containing multiple Git repositories:

AppWork-Main
AppWork-Connect
AppWork-Frontend
AppWork-Cypress-Tests

Clicking “Fix in Cursor” from GitHub fails to locate the repository.

If I instead open the exact repository (AppWork-Connect) as a standalone folder, the deeplink works immediately.

The Git remote matches the GitHub repository, git rev-parse --show-toplevel is correct, and the same Cursor account is logged in.

It appears the deeplink resolver doesn’t search repositories contained within a multi-root .code-workspace.

Steps to Reproduce

  1. Clone a GitHub repository locally (e.g. AppRent1/AppWork-Connect).

  2. Create a Cursor multi-root .code-workspace containing that repository and at least one additional Git repository.

  3. Open the .code-workspace in Cursor and verify the target repository appears in the Explorer sidebar.

  4. Open a GitHub Pull Request for that repository with a Bugbot “Fix in Cursor” button.

  5. Click “Fix in Cursor”.

Observed:
Cursor displays:
“Workspace Not Found. This link is for AppRent1/AppWork-Connect, but Cursor doesn’t have a local workspace open for that repository yet.”

  1. Close the workspace, open only the AppWork-Connect folder in Cursor, and click “Fix in Cursor” again.

Result:
The Bugbot deeplink works correctly.

Expected Behavior

When the target repository is already included in an open multi-root .code-workspace, Cursor should recognize it as an open local repository and resolve the Bugbot “Fix in Cursor” deeplink exactly as it does when the repository is opened as a standalone folder.

The workspace type (.code-workspace vs. standalone folder) should not affect repository detection.

Screenshots / Screen Recordings

Screenshot 2026-07-20 at 10.09.36.png
Screenshot 2026-07-20 at 10.09.36.png2534×645 205 KB

Operating System

MacOS

Version Information

Cursor Version: 1.3.12
Channel: Stable
Platform: macOS (Darwin, Apple Silicon)
Workspace Type: Multi-root .code-workspace
Git Repositories:

  • AppWork-Connect
  • AppWork-Main
  • AppWork-Frontend
  • AppWork-Cypress-Tests
  • appwork-team-ai-directives

Git Remote (target repository):
[email protected]:AppRent1/AppWork-Connect.git

GitHub PR tested:
https://github.com/AppRent1/AppWork-Connect/pull/504

The issue does not occur when AppWork-Connect is opened as a standalone folder. It only occurs when the repository is opened as part of a multi-root .code-workspace.

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey @rotemo,

This is something we’ve seen reported before: the “Fix in Cursor” deeplink doesn’t reliably resolve a repository when it’s inside a multi-root .code-workspace, even though the same repo resolves fine when opened as a standalone folder. It’s on our side, not your setup, and I’ve added your report to what we’re tracking.

A couple of things to unblock you in the meantime:

  1. The standalone-folder approach you already found is the most reliable workaround for now.
  2. Before reorganizing, it’s also worth fully quitting Cursor (Cmd+Q, not just closing the window), reopening the workspace, and clicking the link again. That sometimes temporarily restores resolution in the multi-root window.

And two quick things that would really help us pin down the exact cause:

  • Could you run git remote -v in each of the workspace folders (AppWork-Connect, AppWork-Main, AppWork-Frontend, AppWork-Cypress-Tests, appwork-team-ai-directives) and paste the output? We want to confirm whether any folder has a missing or unexpected origin.
  • Could you double-check your exact version via Help > About? The report lists 1.3.12, which looks like it may be a typo, and the current version string will help us reproduce on the right build.
8

image.png

VS Code Extension API: 1.128.0
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
Layout: IDE
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.256
OS: Darwin arm64 25.5.0

How fast can u solve this issue?? This bug is quite urgent!

9

It’s been a week. What is going on with that one?

10

Hey @rotemo,

Being straight with you: this is a confirmed bug on our side, not your setup, and your report is logged with our team alongside other reports of the same multi-root behavior. I don’t have a timeline I can promise you right now, and I’d rather not give you a date I can’t stand behind. Your report is attached to what we’re tracking, so you’ll be in the loop as it moves.

For now, the standalone-folder approach you already found is the most reliable way to keep going: open the target repo (e.g. AppWork-Connect) on its own when you need “Fix in Cursor,” then switch back to the multi-root workspace afterward. A full quit and reopen (Cmd+Q, not just closing the window) sometimes restores it in the multi-root window too.

If you’re able to grab it, one thing would genuinely help us pin down the exact cause: git remote -v run inside each workspace folder (AppWork-Connect, AppWork-Main, AppWork-Frontend, AppWork-Cypress-Tests, appwork-team-ai-directives). We want to confirm whether one of the non-primary folders resolves its origin differently in the multi-root window. No worries if not, the workaround above keeps you unblocked either way.

11

Repositories:

  • AppWork-Main → AppRent1 / apprent_accounting
  • AppWork-Connect → AppRent1 / AppWork-Connect
  • AppWork-Frontend → AppRent1 / AppWork-Frontend
  • AppWork-Cypress-Tests → AppRent1 / AppWork-Cypress-Tests
  • appwork-team-ai-directives → AppRent1 / appwork-team-ai-directives

All repositories use GitHub SSH remotes for both fetch and push.

Version: 3.12.17

12

Everything checks out on your side: all five folders have valid GitHub origins, and AppWork-Connect points to precisely the repo the PR is on. So this is firmly on us - Cursor isn’t detecting that repo when it’s one folder among several in a multi-root workspace, even though the remote is completely correct. Nothing wrong with your setup.

I still can’t give you a firm timeline, but your report (now with these remotes and your 3.12.17 version) is logged with the team, and you’ll hear back on this thread as it moves.

Two things for now:

  • The standalone-folder approach stays the most reliable way to use “Fix in Cursor.”
  • Worth a quick experiment: move AppWork-Connect to the top of the folder list in your .code-workspace, fully quit with Cmd+Q, reopen, and click the link. The first folder tends to resolve more reliably, so this sometimes gets it working in a multi-root window. No promises it’ll hold, but whether it works or not is a genuinely useful signal for us.