Agents Window treats a multi-repo Cloud Environment as one repo at /workspace: Glass-created agents get empty Files/Changes, no per-repo diffs

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE → Agents Window (Glass) → Cloud Agents running on a multi-repo Cloud Environment.

Describe the Bug

In one sentence: the Agents Window assumes a cloud agent is “one repo checked out at /workspace”, but a multi-repo Cloud Environment is “N repos checked out under /agent/repos/<repo>”, and every symptom below falls out of that mismatch.

On the VM the layout is:

/agent/                 ← workspace root (not itself a git repo)
/agent/repos/repo-a/    ← git repo
/agent/repos/repo-b/    ← git repo
/agent/repos/repo-c/    ← git repo
/workspace/             ← exists, empty, not a git repo

The agent understands this fine: it edits, commits and pushes inside /agent/repos/*. The Agents Window UI does not.

Symptom 1 — Glass-created agents attach Files/Changes to empty /workspace.
Start a Cloud Agent on the environment from the Agents Window and the Files tab and Changes tab are permanently empty. The remote cursor-server has opened /workspace, finds no git repo there, and then looks for /workspace/repos/<repo> (which does not exist). Start the same environment from the web Cloud Agents dashboard and open it in the Agents Window, and it attaches to /agent and Files works.

Symptom 2 — The Changes tab is single-repo even when the path is right.
On a web-created agent (attached to /agent) the Changes tab still cannot show what the agent did: it did not show the commits the agent had made on a branch in one of the repos before pushing. There is no per-repo grouping, no per-repo branch, and no way to review “what changed in repo-b” separately from repo-a. It behaves as if there should be exactly one git repo at the workspace root.

Symptom 3 — The environment is displayed as a plain git repo.
In the project picker and the sidebar the Cloud Environment gets a folder/book icon and is stored as templateType: "gitRepo" (primary repo URL + additionalRepoUrls + an environment id bolted on), not as an environment. Hovering it correctly lists all the repos, so Glass knows it is multi-repo. “Remove” on that sidebar entry does not stick because it is re-derived from the live agents.

Symptom 4 — Restarting Cursor “fixes” an existing Glass agent.
Quit and relaunch Cursor and a previously broken Glass-created agent now attaches to /agent and works. Only newly created Glass agents are broken. That points at the create path, not at the VM or the cache (see root cause below).

This reproduces on two separate user-data directories, on two different environments, on a completely fresh user-data directory, and on both 3.18.25 and 3.19.3.

Steps to Reproduce

  1. Create a multi-repo Cloud Environment: the primary repo has .cursor/environment.json, repositoryDependencies lists the sibling repos, and extra sibling repos are added to the environment. Build it and take a snapshot.
  2. In the Agents Window project picker, pick that environment (hovering it lists every repo).
  3. Start a new Cloud Agent from there.
  4. Open Files and Changes: both are empty. Ask the agent ls /agent/repos and it lists every repo.
  5. Now start a Cloud Agent on the same environment from the web Cloud Agents dashboard and open it in the Agents Window: Files shows /agent, Changes shows diffs.
  6. Ask either agent to commit on a branch in one repo but not push: the Changes tab does not show those commits per repo.
  7. Quit and relaunch Cursor: the agent from step 3 now attaches to /agent.

Expected Behavior

  • A Cloud Agent created from the Agents Window on a multi-repo environment should attach to the environment’s real workspace root (/agent), exactly like a web-created agent does.
  • Better: the Agents Window should understand that /agent/repos/* are N git roots. Files should show all repos, and Changes should group diffs and commits by repo, show the branch per repo, and let me review each repo’s commits before they are pushed.
  • The environment should appear as a Cloud Environment in the picker and sidebar, not as a single git repo.

Multi-repo Cloud Agents are so close to being the only thing I need open to work. Right now Glass is unusable for it without the workarounds below.

Operating System

MacOS

Version Information

Reproduced on both:

Version: 3.18.25 (Universal)  VSCode 1.128.0  Commit 280eca2911f1774689696e5f1efa5a4f97a87af0  Stable
Version: 3.19.3  (Universal)  VSCode 1.128.0  Commit 3b4eb8dd5324607f195ea19f87a93013346a5410  Stable

macOS Darwin 25.5.0 (arm64)

For AI issues: which model did you use?

N/A — not model-specific.

For AI issues: add Request ID with privacy disabled

Matched pair, same environment, same snapshot, created 19 seconds apart:

Second user-data directory, different environment, same result:

  • Glass-created: bc-0be941aa-4d80-4f2d-bd24-a016e9f1e387
  • Web-created: bc-0ab1bbf0-8ba9-4d59-852d-1f4cab831ef7

After a full user-data reset on 3.19.3: Glass-created bc-ac8a6721-c2c9-45f0-82d3-54a5bfc0a1d2 and bc-536ba8de-d781-4c9b-9b8f-5efb7d8477a0 (both /workspace), web-created bc-004a819e-92a2-414e-81f6-5bbfb6873943 (/agent).

Additional Information

Likely root cause (from reading workbench.glass.main.js in 3.19.3)

  1. Glass has a constant "/workspace" for the workspace root.
  2. createAgent builds the Files/Changes project reference with that constant, and _createOptimisticCloudAgent stores workspaceRootPath: "/workspace" on the optimistic agent, before the server has said anything.
  3. The server then reports the real root (workspaceRootPath: "/agent") and the local cloudAgentRepository cache is updated, but ensureCloudAssignment keeps the already-assigned project, so the UI never re-binds from /workspace to /agent.
  4. On relaunch, Glass hydrates from the cached /agent value and everything works. Web-created agents never go through the optimistic create, so they hydrate from /agent on first open and are fine.

Suggested fix: use the environment’s workspace root (or the server-reported workspaceRootPath once known) instead of the constant, and re-bind the project when the server’s value differs from the optimistic one. Separately, Changes needs to treat /agent/repos/* as multiple git roots.

Evidence from the two VMs (matched pair)

Both pods:

  • Same Cloud Environment and version; environment.repos lists all repos
  • Live checkouts at /agent/repos/<repo> for every repo
  • /workspace exists, is empty (mtime 1970-01-01), is not a git repo and is not a bind of /agent/repos
  • Agent request context: workspacePaths = the /agent/repos/* folders; processWorkingDirectory = one of them

run-info differences: Glass source=desktop, repoUrl is a full HTTPS URL; web source=web, repoUrl is host/owner/repo. The environment object is identical.

On the Glass-created pod, cursor-server opened workspace storage against /workspace:

ripgrep   cwd: /workspace   directoriesWalked: 0   filesWalked: 0
git scan  /workspace → fatal: not a git repository → 0 repositories
ENOENT    realpath '/workspace/repos/<repo>'   (once per environment repo)

The exec daemon on the same pod kept working in /agent/repos/*.

Evidence from the local client

workspace.json after opening both agents in the Agents Window:

Glass agent:  vscode-remote://background-composer+<glass-bc-id>/workspace
Web agent:    vscode-remote://background-composer+<web-bc-id>/agent

cloudAgentRepository cache for both agents: workspaceRootPath: "/agent", same environment, same repoUrls. Only provenance differs: Glass source=16, cloudTargetKey=logicalEnvironment:<env-id>; web source=3, cloudTargetKey=dynamicMultiRepo:<repo-urls>.

Renderer log on the Glass-created window:

[GlassDiffService] getGitRoot returned empty for known cwd (cwd=/workspace, returnedValue=undefined)
[GlassDiffService] Refresh reports missing git repository (reason=immediate, cwd=<empty>, previousGitRepoRoot=<none>, hasGitContextProvider=true)

Picker cache cursor/glass.projectSelector.recentCloudTargets stores the environment as templateType: "gitRepo" with the primary repoUrl, additionalRepoUrls, and logicalEnvironmentId / logicalEnvironmentName.

Workarounds

  1. Create the Cloud Agent on the web Cloud Agents dashboard, then steer it from the Agents Window. It attaches to /agent, so Files works (Changes is still single-repo).
  2. Quit and relaunch Cursor after creating a Glass agent. It re-attaches to /agent.
  3. Leave the agent on /workspace and ask it to ln -s /agent/repos/<repo> /workspace/<repo>. Changes then has a git root to look at, one repo at a time. I have wrapped this in an agent skill, which is a fairly strong sign the UI is missing a feature.

Does this stop you from using Cursor

Yes. Without the workarounds above the Agents Window is unusable for Cloud Agents on a multi-repo environment: Files and Changes are empty, and even when they are not, Changes cannot show per-repo commits.

6

Hey @walke
Your read is right: this is on our side, not anything you misconfigured, and it’s not intended behavior.

For now the cleanest unblock is the one you found. Start the agent on cursor.com/agents, then open and steer it from the Agents Window so Files and Changes attach correctly. Quitting and relaunching Cursor also re-attaches an agent you’ve already started in-app.

We’re tracking this (including the per-repo Changes view you flagged). No timeline to share yet, but I’ll post here when there’s an update.