Deleting a Cloud Agent environment leaves non-desktop launch sources with `environmentPublicId: null`, creating a permanent phantom sidebar group

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor IDE — Agents sidebar / Cloud Agents

I had two Cloud Agent environments for the same repo and deleted the stale one from the dashboard. The dashboard now correctly shows exactly one environment. But the Agents sidebar still renders two cloud sections for that repo, and the second one keeps gaining new agents.

Inspecting cloudAgentRepository.agents.<userId> in globalStorage/state.vscdb, the second group is not the deleted environment — it’s agents with environmentPublicId: null.

The cause appears to be that each launch source held its own binding to the deleted environment, and only the desktop source re-resolved to the surviving environment. The others now emit null:

source Aug 12–25 After the environment change
16 (desktop) b27cdbbb… re-resolved to 5c57f37f… on Aug 26 18:03
4 b27cdbbb… null from Aug 27 16:58 onward
5 b27cdbbb… null from Aug 26 21:47 onward

Source 5 ran 22 consecutive agents on the old environment through Aug 25 21:18, and every agent since has had environmentPublicId: null. Source 4 shows the same break one day later. Desktop recovered; the non-desktop paths did not.

Because these agents have no environment ID, the sidebar can’t file them under logicalEnvironment:<id> and gives them a separate untitled section with the same repo name. Since the binding is still broken, the group grows with every new Slack/web/automation-launched agent — it does not age out.

This is also not fixable from the UI. Under groupBy: repository, the only section ID available for those agents is repo:github.com/<org>/<repo>, which is shared with the local (non-cloud) chats for the same repo. Using Remove from Sidebar on it writes that shared ID into removedSectionIds and hides the legitimate local chats too. The only workaround is switching Grouping to Updated/Status, which disables repo grouping entirely.

Happy to share full environment IDs and bcIds privately if useful — bcId is the one staff have asked for unredacted in prior threads.

Steps to Reproduce

  1. Have two Cloud Agent environments for the same repo.
  2. Launch cloud agents from a non-desktop source (Slack / web / automation) so they bind to one of them.
  3. Delete that environment from cursor.com/dashboard?tab=cloud-agents → Environments → … → Delete.
  4. Launch a new agent from that same non-desktop source.
  5. Observe in the Agents sidebar: a second section appears with the repo’s name, containing the new agent. Dashboard still shows one environment.
  6. Inspect cloudAgentRepository.agents.<userId> — the new agent has environmentPublicId: null.

Expected Behavior

When an environment is deleted, every launch source should fall back to the account’s remaining/default environment for that repo, the same way the desktop source does. Agents should not be created with a null environment. Failing that, env-less agents should be grouped into the repo’s existing environment section rather than a duplicate untitled one, and should be hideable independently of the shared repo section.

Operating System

MacOS

Version Information

macOS 15.6.1 (24G90), arm64

Version: 3.17.21
Commit: 8f2a112cb2845a97b75fd932ea5c470579ca4060
Date: 2026-08-25T01:05:08.089Z
VSCode Version: 1.128.0
Quality: stable

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey @descesc thanks for the detailed report, and for digging into state.vscdb. This isn’t anything you misconfigured, and it’s an issue we’re tracking. For now the cleanest workaround is switching Grouping to Updated/Status - and avoid Remove from Sidebar on that section, since it’ll take your local chats with it.

To pin it down, could you share the full environment IDs (deleted + surviving), one or two bcIds from the env-less group, and a quick screenshot of the duplicate section? Here or via mail, whichever’s easier.

One correction: in your data the affected sources are the Linear integration (4) and the iOS app (5), not Slack/web - 16 is the desktop app that recovered.