Agent project list goes empty after GitHub remote name collides with SSH workspace folder name

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When a local workspace gets a Git remote whose repo name matches an existing SSH remote folder name (corplangosite), the Agents UI label/navigation becomes ambiguous. Chats for the SSH prod workspace still exist and open correctly via Agent Search, but opening/leaving the prod project in the project list shows an empty agent list.

Steps to Reproduce

1 Have an SSH remote workspace with chats at /root/corplangosite (host alias h-test).
2 Separately create/open a local folder named ws_corplangosite and work with Agents there.
3 Add Git remote origin pointing to GitHub repo named corplangosite (same basename as the SSH folder).
4 Observe project label in Cursor Agents UI shifts toward corplangosite (repo name), losing the distinguishing ws_ context.
5 Open prod SSH project from the project picker → agent list appears empty.
6 Search Agents for an existing prod chat title (e.g. “Corporate site Git integration”) → chat opens correctly into the SSH /root/corplangosite workspace.
7 Leave that chat / go back to the prod project view → list is empty again.

Expected Behavior

1 Project identity should stay tied to workspace URI (file://…/ws_corplangosite vs vscode-remote://…/root/corplangosite), not GitHub repo basename.
2 UI label should not collapse two different workspaces into the same display name.
3 Opening the SSH project should list its Agents normally, not only via search.

Operating System

MacOS

Version Information

Version: 3.14.27 (Universal)
VS Code Extension API: 1.128.0
Commit: 047548b00c1a079373d74d00183f32510a4a41e0
Date: 2026-08-04T03:29:11.183Z
Layout: Agent Window
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.291
OS: Darwin arm64 25.6.0

Additional Information

Suspected root cause.
Agents project labeling / grouping prefers Git remote repository name over folder basename / workspace URI. When local GitHub repo name equals remote SSH folder name, the UI conflates workspaces and breaks the project-scoped agent list (while search still resolves the correct conversation → correct workspace).

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. Let’s break it down, since this is actually two different behaviors.

About the label and grouping. Cursor intentionally groups agents by repo identity git remote, not by folder path, so chats from the same repo across local, SSH, and cloud show up in one section. That’s why after you added the origin remote pointing to the GitHub repo corplangosite, the local folder label switched to the repo name and lost the ws_ context. This is expected behavior, not a bug.

About the empty agent list for the SSH project. That part is not expected. It’s a known issue we’re tracking. Chats for a Remote SSH workspace sometimes stay tied to the workspace identity and don’t get pulled into the repo section, so the project entry in the picker looks empty even though Search can find all the chats. I can’t share a timeline yet, but it’s on our radar.

Workarounds that should help right now:

  • Switch grouping in the Agents panel to Group by: Workspace. Then the SSH workspace won’t collapse into the repo section and your agents should show up again.
  • Pin important SSH chats so they’re always easy to find.
  • Always connect to the SSH host using the same host alias h-test. Different host address forms create different workspace identities and make the split worse.

If you can, please share the output of git remote -v on the SSH machine and tell me which Group by mode you’re currently using. That’ll help confirm the exact scenario. Let me know if switching to Group by: Workspace fixed it.

6

@deanrie thanks a lot for your help! Switching to Group by: Workspace has fixed everything (before it was by repository) and proved it was not a bug but lack of my knowledge of the Cursor interface. Have a good day!