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

**URL:** <https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141>\
**Category:** Bug Reports\
**Tags:** github, bugbot, deeplinks\
**Created:** [July 20, 2026, 7:10am UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141 "2026-07-20T07:10:27Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![rotemo](https://avatars.discourse-cdn.com/v4/letter/r/cab0a1/32.png) [@rotemo](https://forum.cursor.com/u/rotemo)\
**Post date:** [July 20, 2026, 7:10am UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/1 "2026-07-20T07:10:27Z")

</div>

### 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](https://us1.discourse-cdn.com/cursor1/original/3X/9/0/903f5bcb597d701bc1d25fa2cb9e6cbe239ff092.jpeg)

### 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):  
[git@github.com](mailto:git@github.com):AppRent1/AppWork-Connect.git

GitHub PR tested:  
[https://github.com/AppRent1/AppWork-Connect/pull/504](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

---

<div class="post-metadata">

**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\
**Post date:** [July 20, 2026, 8:46am UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/6 "2026-07-20T08:46:20Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rotemo](https://avatars.discourse-cdn.com/v4/letter/r/cab0a1/32.png) [@rotemo](https://forum.cursor.com/u/rotemo)\
**Post date:** [July 20, 2026, 11:12am UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/8 "2026-07-20T11:12:34Z")

</div>

![image.png](https://sea3.discourse-cdn.com/cursor1/images/transparent.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!

---

<div class="post-metadata">

**Author:** ![rotemo](https://avatars.discourse-cdn.com/v4/letter/r/cab0a1/32.png) [@rotemo](https://forum.cursor.com/u/rotemo)\
**Post date:** [July 26, 2026, 4:38pm UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/9 "2026-07-26T16:38:09Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\
**Post date:** [July 27, 2026, 10:44am UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/10 "2026-07-27T10:44:48Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rotemo](https://avatars.discourse-cdn.com/v4/letter/r/cab0a1/32.png) [@rotemo](https://forum.cursor.com/u/rotemo)\
**Post date:** [July 27, 2026, 11:50am UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/11 "2026-07-27T11:50:19Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\
**Post date:** [July 28, 2026, 12:52pm UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/12 "2026-07-28T12:52:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rotemo](https://avatars.discourse-cdn.com/v4/letter/r/cab0a1/32.png) [@rotemo](https://forum.cursor.com/u/rotemo)\
**Post date:** [September 18, 2026, 6:44pm UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/13 "2026-09-18T18:44:15Z")

</div>

> [@mohitjain](#):
>
> o 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.

Hi. Any news on that?

---

<div class="post-metadata">

**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\
**Post date:** [October 20, 2026, 9:29am UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/15 "2026-10-20T09:29:48Z")

</div>

Hey @rotemo,

The “Workspace Not Found” issue when clicking “Fix in Cursor” for a repo that’s one folder in a multi-root `.code-workspace` has been fixed in a recent Cursor update (3.25). Once you update to the latest version, the link should resolve straight from your multi-root workspace, with no need to switch to the standalone folder.

Let me know if you still hit it after updating!

---

<div class="post-metadata">

**Author:** ![rotemo](https://avatars.discourse-cdn.com/v4/letter/r/cab0a1/32.png) [@rotemo](https://forum.cursor.com/u/rotemo)\
**Post date:** [October 26, 2026, 2:57pm UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/16 "2026-10-26T14:57:56Z")

</div>

> [@Colin](#):
>
> if you still hit it after updatin

Hi @Colin . Unfortunately, this still happens to me

---

<div class="post-metadata">

**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\
**Post date:** [October 26, 2026, 5:11pm UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/20 "2026-10-26T17:11:10Z")

</div>

Hey @rotemo,

Sorry it’s still happening, and thanks for letting us know. I can see you’re on the latest version, so the update fixed one cause of this (links clicked while the workspace was still loading) but not the one you’re hitting.

Could you try this the next time you click “Fix in Cursor” and tell us what happens?

1. Open your `.code-workspace` as usual.
2. Open the Command Palette (Cmd+Shift+P) and run **Developer: Reload Window**.
3. Wait until the window has fully loaded and all of your repositories show in the Source Control view.
4. Click into that window once, so it’s the last Cursor window you used.
5. Click “Fix in Cursor” on the PR.

Then let us know:

- Did the link open correctly after the reload?
- How many Cursor windows did you have open when you clicked it?

In the meantime, opening AppWork-Connect as a standalone folder still works for these links.

---

<div class="post-metadata">

**Author:** ![rotemo](https://avatars.discourse-cdn.com/v4/letter/r/cab0a1/32.png) [@rotemo](https://forum.cursor.com/u/rotemo)\
**Post date:** [October 27, 2026, 4:48pm UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/21 "2026-10-27T16:48:54Z")

</div>

@Colin hi.  
Thank u for your quick reply.  
I did all of the above. I only have one Cursor window open.  
Unfortunately, the link did not opened correctly. (See attachments)

 ![image](https://us1.discourse-cdn.com/cursor1/original/3X/3/a/3a41dff43ad1e4e62d747973124f820cebecfaf1.png)

 ![image](https://us1.discourse-cdn.com/cursor1/original/3X/3/a/3a41dff43ad1e4e62d747973124f820cebecfaf1.png)

---

<div class="post-metadata">

**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\
**Post date:** [October 27, 2026, 5:37pm UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/26 "2026-10-27T17:37:28Z")

</div>

Hey @rotemo, thanks for trying those steps and for the screenshot, that helped narrow it down.

The link in your screenshot is for the repository in your AppWork-Main folder. From what we can see, the Cursor window you’re clicking from has one top-level folder open (the parent folder that holds all your repositories), rather than each repository as its own folder. “Fix in Cursor” currently only matches repositories that are top-level folders in the window, so a repository sitting inside that parent folder isn’t recognized, even though it shows up in Source Control. That’s why reloading didn’t change anything.

Until that’s handled, this should get the link working in your current window:

1. In Cursor, open the File menu and choose **Add Folder to Workspace…**
2. Select the AppWork-Main folder (the one that contains the repository from the link) and click **Add**.
3. Repeat for any other repositories you get “Fix in Cursor” links for (for example AppWork-Connect).
4. Optional: choose **File \> Save Workspace As…** so you don’t have to redo this.
5. Click “Fix in Cursor” on the PR again.

Could you also let us know:

- Did the link open correctly after adding the folder?
- Does the parent folder contain a `.gitmodules` file (are the repositories git submodules of it), or are they separate clones inside it?

I’ve passed this along to the team.

---

<div class="post-metadata">

**Author:** ![rotemo](https://avatars.discourse-cdn.com/v4/letter/r/cab0a1/32.png) [@rotemo](https://forum.cursor.com/u/rotemo)\
**Post date:** [October 28, 2026, 8:07am UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/27 "2026-10-28T08:07:59Z")

</div>

@Colin hi.  
Thank u for your quick response. Yes, the parent folder does contain a .gitmodule file: (see images)

also, regarding your first question: Yes, it works, BUT, this is not what I want (see image)  
Now I have Main twice,. and it’s in the root folder, so of course it works. Once Main is in the root it works. It used to work even before your fix.  
I don’t want to have Main outside of my AppWork-System folder. The entire goal was to keep the structure that Main is under AppWork-System (I need that structure in order to use SpecKit)  
Thanks

 ![image](https://us1.discourse-cdn.com/cursor1/original/3X/9/3/93ae1c051ab2869ff5cc59e7467055d210e69875.png)

 ![image](https://us1.discourse-cdn.com/cursor1/original/3X/e/1/e133b67c011f93a4f85b6e9373b166a48c07220e.png)

---

<div class="post-metadata">

**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\
**Post date:** [October 28, 2026, 11:15am UTC](https://forum.cursor.com/t/bugbot-fix-in-cursor-doesnt-resolve-repositories-inside-a-multi-root-workspace/166141/31 "2026-10-28T11:15:34Z")

</div>

Hey @rotemo, thanks for checking, and for the screenshots.

That confirms it: AppWork-Main (along with AppWork-Connect and AppWork-Frontend) is a git submodule of AppWork-System, and “Fix in Cursor” currently only looks at the top-level folders in the window, not at submodules inside them. Letting it find a submodule inside the open folder is something the team is actively working on, and I’ve added your report to it. Once that’s out, you’ll be able to keep just AppWork-System open and the link will find AppWork-Main inside it.

Until then, one note on the SpecKit concern: “Add Folder to Workspace” doesn’t move or copy anything on disk. The second “AppWork-Main” entry is just another view of the same AppWork-System/AppWork-Main folder, so your structure stays exactly as it is. You can remove the extra entry later (right-click it in the Explorer, then Remove Folder from Workspace).
