Projects: create/delete fail on Windows; ghost projects stuck on “Preparing report”

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Creating a new Cursor Project from the Agents window fails with an error. Retrying a second and third time also failed.

Later, the projects still show up in the Agents list as if they exist, but they remain in a working/loading state (UI shows “Preparing report”). Trying to delete the first two ghost projects also failed with an error.

This appears to be a Windows URI bug in the Agents/Projects (glass) UI. Local renderer logs show _createBackgroundComposerUri throwing:

[UriError]: If a URI contains an authority component, then the path component must either be empty or begin with a slash ("/") character

The same error also fails environment setup:

[agent-demos-setup] Failed to start environment setup agent: [UriError]: If a URI contains an authority component...

Related (same UriError on Windows Projects): https://forum.cursor.com/t/projects-cant-acess-my-cloud-agents-on-cursor-desktop

Steps to Reproduce

  1. On Windows, open the Cursor Agents window.
  2. Create a new Project (in my case named “Zineps”).
  3. Creation fails with an error.
  4. Retry create two more times. Both retries also fail with an error.
  5. Later, open the Agents list / Projects sidebar. The failed projects now appear anyway.
  6. Open one of them: it stays on “Preparing report” / still working instead of becoming a usable project.
  7. Try to delete the first two projects in the list. Delete also fails with an error.

Expected Behavior

  • Creating a Project should succeed, or fail cleanly without leaving leftover entries.
  • Failed creates should not later appear in the Agents/Projects list as still-running projects.
  • A project that failed to finish setup should not stay stuck on “Preparing report”.
  • Deleting a failed/stuck project should succeed so the list can be cleaned up.

Operating System

Windows 10/11

Version Information

Version: 3.20.21
VSCode Version: 1.128.0
Commit: f09fca384ceca23f7bf21f9c23655b162641d740
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Default / Auto (selectedModels=default, maxMode=true in logs)

For AI issues: add Request ID with privacy disabled

Background Agent / composer IDs from local logs around the failed project setup:

bc-8b90e23d-482f-4458-92fc-004b3fc67272
bc-fb4d7818-d5a8-484a-a0b3-5b79ef3cd1b7

composerId=43ecfdf4-16a9-4640-824f-7a6ed2dcf5e6
composerId=31b43fe6-1324-4145-a97c-03b9d5a31a61

Also: agent-store-sync for bc-8b90e23d-482f-4458-92fc-004b3fc67272 repeatedly returned [not_found] while UI showed the project as still running / Preparing report.

Additional Information

Environment: Cursor Agents window (glass UI) on Windows 11. Repo involved: zineps-platform.

Relevant local log excerpts from %APPDATA%\Cursor\logs\20260915T114407\window1_wb0\renderer.log:

2026-09-15 17:48:06.829 [error] [agent-demos-setup] Failed to start environment setup agent: [UriError]: If a URI contains an authority component, then the path component must either be empty or begin with a slash ("/") character

Stack (createAgent path):

at Lvi._createBackgroundComposerUri (...workbench.glass.main.js:9057:97801)
at Lvi._createBackgroundComposerEnvironmentReference (...:9057:97944)
at Lvi._syncAgentHeaders (...:9057:89930)
at Lvi._registerOptimisticCloudAgentAndGetReference (...:9053:266599)
at Lvi.createAgent (...:9053:248035)
at async ttT.createAgent (...:22171:75023)

Later, opening a leftover project:

2026-09-15 20:09:12.409 [error] ENOPRO: No file system provider found for resource 'vscode-remote://background-composer%2Bbc-8b90e23d-482f-4458-92fc-004b3fc67272/workspace/PULL_REQUEST_TEMPLATE.md'
2026-09-15 20:09:12.113 [error] resolveAuthority(background-composer) returned an error after 26 ms Canceled

UriError also repeats periodically in the Agents window (same _createBackgroundComposerUri / _updateAgentHeader path), matching the other Windows Projects report from today.

Screenshot: Agents window with Project “Zineps” selected, body stuck on “Preparing report”, multiple leftover project/agent entries in the sidebar.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

## Follow-up: Remote Control agents also fail, and removing them errors

Same Windows UriError, now also on **Remote Control** agents.

What happened

  1. Started several Remote Control agents (sidebar shows many leftover entries named `test`).
  2. They did not actually work / never became usable.
  3. Removing / archiving them also fails with an error. The ghost `test` agents remain in the Agents list.

Logs (same session, Cursor 3.20.21, Windows 11)

Loading a leftover cloud/remote agent:
```
[useGlassRootState] Failed to load agent after 5 attempt(s): Cloud agent not found: bc-fb4d7818-d5a8-484a-a0b3-5b79ef3cd1b7
```

Remove/archive hits the same URI crash:
```
at Lvi._createBackgroundComposerUri (…workbench.glass.main.js:9057:97801)
at Lvi._setCloudAgentArchived (…:9053:223641)
at Lvi.archiveAgent (…:9054:7567)
at ttT.archiveAgent (…:22171:76268)
[UriError]: If a URI contains an authority component, then the path component must either be empty or begin with a slash (“/”) character
```

Opening one of the leftover Remote Control agents:
```
ENOPRO: No file system provider found for resource ‘vscode-remote://background-composer%2Bbc-66948635-729d-4626-8b97-75e026da411d/workspace/…’
Cannot get default system shell when there is no backend for remote authority ‘undefined’
Timed out resolving the agent workspace after 30000ms
```

`agent-store-sync` also returns `[not_found]` for:

  • `bc-8b90e23d-482f-4458-92fc-004b3fc67272`
  • `bc-66948635-729d-4626-8b97-75e026da411d`
  • `bc-fb4d7818-d5a8-484a-a0b3-5b79ef3cd1b7`

So create, open, and delete/archive of both **Projects** and **Remote Control** agents are stuck behind `_createBackgroundComposerUri` building an invalid Windows URI. Failed agents remain as ghosts in the sidebar and cannot be cleaned up.

6

## Follow-up: switching an existing agent to Remote also fails

Tried converting a local agent to Remote Control. Dialog:

**Failed to migrate agent**

[UriError]: If a URI contains an authority component, then the path component must either be empty or begin with a slash (“/”) character

Same Windows URI bug as create / delete / Remote Control start.

Logs (20:56 local, Cursor 3.20.21)

[code]
[GlassAgentMigrationService] Pipeline migration failed. [UriError]: If a URI contains an authority component, then the path component must either be empty or begin with a slash (“/”) character
[/code]

New leftover agent after the failed migrate: `bc-e4cbc5eb-8b52-4e1f-8e19-d023424229d4`

[code]
ENOPRO: No file system provider found for resource ‘vscode-remote://background-composer%2Bbc-e4cbc5eb-8b52-4e1f-8e19-d023424229d4/workspace/…’
[/code]

This also happened earlier today at 14:03 in the same service (`GlassAgentMigrationService` pipeline migration failed with the same UriError).

So on Windows 3.20.21 this URI crash now covers:

  1. Creating a Project
  2. Starting a Remote Control agent
  3. Switching an existing agent to remote (migrate)
  4. Deleting / archiving any of the leftover agents
7

## Follow-up: Open in desktop from the web Agents page also fails

This was not in the original post. On the web Agents page (cursor.com/agent), clicking **Open in desktop** does not open a working agent in Cursor Desktop.

On Windows 3.20.21, opening those cloud agents locally hits the same URI crash:

[code]

[UriError]: If a URI contains an authority component, then the path component must either be empty or begin with a slash (“/”) character

[/code]

Desktop then also logs:

[code]

[useGlassRootState] Failed to load agent after 5 attempt(s): Cloud agent not found: bc-…

ENOPRO: No file system provider found for resource vscode-remote://background-composer…/workspace/…

[/code]

Same _createBackgroundComposerUri Windows URI bug as create / migrate / archive. Related existing report: Projects cant access my cloud agents on Cursor desktop (same UriError when opening cloud agents on desktop).

So this URI crash now also covers the web to desktop handoff from the **Open in desktop** button.

8

## Follow-up: Open in desktop now shows the agent, but chatting still fails

Partial progress after a full Cursor restart: **Open in desktop** now opens the cloud agent in the Agents window (conversation history is visible). Sending a follow-up message still fails with the same UriError.

UI error:

[code]

[UriError]: If a URI contains an authority component, then the path component must either be empty or begin with a slash (“/”) character

Request ID: 41f4df35-285b-483d-9d2f-50fd0120c32a

[/code]

Logs (21:21 local, Cursor 3.20.21, agent `bc-6ee53383-335f-4b88-b8f8-02fe275783ad`):

[code]

[useAgentFollowup] submitMessage failed: [UriError]: If a URI contains an authority component, then the path component must either be empty or begin with a slash (“/”) character

[/code]

Same `_createBackgroundComposerUri` crash also fires on `_syncAgentHeaders` while the agent is open.

Separately, workspace attach fails because this is a self-hosted / private worker agent:

[code]

[failed_precondition] This Cloud Agent runs on a self-hosted worker, which does not host a cursor-server workspace. (cursorServerUrlReason=WORKSPACE_ON_PRIVATE_WORKER)

[/code]

Then ENOPRO on the background-composer remote folder, and:

[code]

Timed out resolving the agent workspace after 30000ms

[/code]

So Open in desktop can now show the UI, but chat (`useAgentFollowup` / `submitMessage`) is still blocked by the Windows URI bug, and the remote workspace never attaches for private-worker cloud agents.

9

## Follow-up: local agent chat pane is empty after Cursor API HTTP2 drop

Separate from the Windows URI crash. Opened a local (This PC) agent titled “Agent list on Kevin’s PC”. Sidebar selects it and the composer is in **Send follow-up** mode, but the chat body is completely empty.

The agent actually ran. Composer `1cad7917-446e-407e-912d-26f9bf2760e4` acquired a wakelock, ran shell tool calls, then generation-ended twice (23:50 on Grok 4.6, 23:53 on Auto). The pane still shows no bubbles.

Just before the second run:

[code]

An unknown error occurred. Please consult the log for more details. {“code”:“ERR_HTTP2_INVALID_SESSION”}

[/code]

Same Cursor API / HTTP2 drop happened earlier today (15:31, 15:43, 15:59, 17:29). Also seen:

[code]

{“name”:“ConnectError”,“rawMessage”:“PING timed out”,“code”:14}

[/code]

Cursor status currently shows a Grok 4.6 (non-fast) service degradation. That matches the first run of this empty chat.

Other logs around this empty chat:

- Promoting a draft agent `05934ec9-…` into `1cad7917-…` then `Draft workspace archived` errors

- `agent-store-sync`: un-pushed writes stuck passive for 120s, “the holder may be wedged”

- Local agent store for `1cad7917` has only `.sync/mount.json` — no conversation files

So after the Cursor API HTTP2 session dies, the Agents window can leave a local chat selected with Send follow-up but no history rendered, and the store never gets the bubbles.

10

## Follow-up: empty chat pane reproduced; now duplicated in the sidebar

Reproduced ~25 minutes later. Same local agent title “Agent list on Kevin’s PC”. After generation ended, the Agents window went blank again.

Sidebar now shows **two** rows with that same title (1m and 25m). Clicking the new one: Send follow-up, empty body.

Same `Draft workspace archived` + `migration_tab_transition.promote_noop` pattern:

- 23:50: draft `05934ec9-…` promoted to `1cad7917-…`

- 00:05: draft `13b6d7af-…` promoted to `81206319-…`

The second chat actually ran on Auto (wakelock 00:05, 00:09, 00:17). The jsonl transcript still has the user prompts and replies. The Agents window does not render them.

So this is repeatable: the local Agents window can fork a duplicate empty row while the on-disk transcript is intact.