Glass 3.4.17 — "Workspace folders changed to none" + agent chat messages dropping mid-session (macOS, Apple Silicon)

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Three connected symptoms, recurring in Glass 3.4.17 on macOS:

  1. Workspace folders silently drop to none mid-chat. A system reminder appears: “Workspace folders changed from file:///… to none. Your workspace path has changed…” The project hasn’t been closed or moved — it happens spontaneously, often after a long-running agent turn.

  2. Agent chat messages stop arriving. The composer says “taking longer than expected” and stalls. New assistant messages never render in the UI, even though the agent transcript file on disk at ~/.cursor/projects//agent-transcripts/.jsonl keeps growing — so the agent is still working, but the UI is no longer subscribed to its output.

  3. Recent assistant messages disappear from the UI scrollback, even though they exist in the on-disk transcript. Forces a context reset every time.

Looks like the same family of issues reported in:

i.e. workspaceStorage/state.vscdb corruption, possibly tied to the anysphere.cursor-socket extension host. The nuke-workspaceStorage workaround is destructive (loses sidebar chat history) so a real fix would be ideal.

Steps to Reproduce

Intermittent — no consistent trigger I can isolate. Most reliably happens during:

  1. Open a single-folder workspace in Glass (no multi-root, no worktree).
  2. Start an agent chat that involves many parallel tool calls (e.g. 20+ MCP calls in one turn) and/or long-running tool work.
  3. Wait — often after 1+ hour of the workspace being open, or after macOS sleep/resume, the symptoms appear.
  4. Composer shows “taking longer than expected” and never recovers; the “Workspace folders changed to none” system reminder appears in the next turn.

Quitting Cursor fully (Cmd+Q) and reopening fixes it for 5-15 minutes, then it recurs.

Expected Behavior

  • Workspace folders should remain bound to the open project for the duration of the session.
  • Assistant messages should render in the UI when the agent emits them, matching what’s being written to the on-disk transcript file.
  • Long agent turns and parallel tool calls should not destabilise the chat sync layer.

Operating System

MacOS

Version Information

IDE:
Version: 3.4.17
VSCode Version: 1.105.1
Commit: 93e603f703cd553a6bb3644711a3379bbbb31180
Date: 2026-05-13T21:39:55.724Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0
Hardware: Apple Silicon (arm64)

For AI issues: which model did you use?

Auto (default model selection)

Additional Information

Workspace is single-root, not a multi-root .code-workspace, no git worktrees. Cursor was updated to 3.4.17 directly from 3.3.x; the symptoms started after the 3.4 update.

The on-disk agent transcript surviving the UI desync is the most useful diagnostic — it confirms the agent process is still running and producing output, the UI just stops receiving it. Suggests the desync is in the renderer/IPC layer rather than the agent process itself.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

8

These are known bugs that our team is actively working on. You’re right that the on-disk transcript surviving is the key diagnostic clue — it confirms the issue is in the UI rendering layer, not the agent process itself.

The three symptoms you’re seeing actually map to two separate issues our team is tracking:

  1. “Workspace folders changed to none” — This happens when the IDE’s workspace context briefly reports empty during a transition (like sleep/resume). The agent detects the change and logs the reminder, but the workspace data isn’t actually lost. This is cosmetic, not a data loss concern.

  2. “Messages stop rendering / disappear from scrollback” — This is a rendering pipeline bug where the UI stops receiving agent updates even though the agent continues running. Multiple engineers on our team have reported the same behavior.

What to try instead of Cmd+Q:

  • Press Cmd+Shift+P and run Developer: Reload Window — this is faster than quitting entirely and should restore the workspace context and message rendering without losing your current session state.

  • You do not need to delete workspaceStorage — the issue is transient, not corruption-related.

We have active fixes in progress for both issues. I don’t have a specific timeline, but the team is actively debugging this family of bugs.

9

Hi Mohit,

Thanks for the update! I originally used Cursor to generate the content for this bug/issue flag so I don’t fully understand the technicals myself. Will wait for the bug resolution when it’s ready.

Thanks!

11

Hey @zendesk_kk!

Since you posted, we’ve shipped a number of fixes in the Glass chat/composer area, particularly around messages not rendering and disappearing from the chat view. Could you update to the latest version of Cursor (3.6.31+) and let me know whether any of the three behaviors (workspace folders dropping to none, messages stopping mid-turn, or recent messages vanishing from scrollback) still happen?

12

Hi @Colin !

I’ve upgraded to 3.6.31 on macOS arm64, but I haven’t seen any of the three symptoms in the first session after upgrade yet, although I haven’t stress-tested yet (long agent turns / MCP-heavy work / sleep-resume).

Will report back if any recur.

13

Adding a detailed 3.6.31 data point, since @Colin asked whether this still happens after the recent fixes. Short answer: yes, it still occurs — and it surfaced spontaneously mid-session, not on a restart. (One difference from the original report: my setup is a multi-root workspace with 8 folders, whereas the OP was single-root — so this isn’t limited to single-root.)

Environment

  • Cursor 3.6.31 (commit 81fcf2931d), macOS, Apple Silicon
  • Multi-root workspace with 8 folders, working primarily in the Glass / Agents window

What happened

The agent received the verbatim reminder mid-session:

Workspace folders changed from file:///Users/<user>/workdir/<...8 repos...> to none.
Your workspace path has changed, and all future edits should be performed in the new workspace folders.

…while all 8 folders were still present in the UI and on disk. Cosmetic as noted — but it still reaches the agent and instructs it to “edit in none,” which is a real correctness hazard for an autonomous agent.

It fired spontaneously after a long, tool-heavy agent turn (following a sleep/resume), matching the “often after a long-running agent turn” pattern.

Triggers I tested deliberately — these did NOT surface it

Trigger Confirmed by Agent got “to none”?
Developer: Reload Window new per-window log dirs No — rebinds to real workspace
Real sleep/resume cycle pmset -g log → Entering Sleep 12:51/12:53/12:57, Wake 12:57:38 No

The reminder instead appeared spontaneously during normal interaction afterward.

Log evidence (sanitized)

1. Glass workspace/git context intermittently reports empty even when the cwd is known. The “smoking gun” line, twice in window3_wb*/renderer.log:

[warning] [GlassDiffService] getGitRoot returned empty for known cwd
  (cwd=/Users/<user>/workdir/<repo>, returnedValue=undefined)

2. These come in bursts of repeated failures at transition points (each timestamp ~= 14 lines of getGitRoot failed (cwd=<empty>...) + Refresh git-root lookup errored):

2026-06-03 14:17:35   (x14)
2026-06-03 15:28:11   (x14)
2026-06-03 17:54:13   (x14)
2026-06-04 11:53:53   (x14)
2026-06-04 12:40:17   (x14)

3. On Reload Window, the Glass window still spawns a transient empty-window workbench context alongside the real one — e.g. a fresh window3_wb0/output_<ts>/cursor.hooks.workspaceId-empty-window.log logging No workspace folder found, created at the moment of reload, even though window3_wb1 holds the real workspace (all 8 folders).

4. The agent-facing “to none” reminder itself is NOT written to any renderer/exthost log — nothing in the workbench logs references it around the time it fired. It appears to originate in the composer/agent workspace-folder subscription (not the hooks service, which logged no empty-window event at that moment). That may be why it’s hard to repro/diagnose from logs alone; the closest on-disk correlate is the GlassDiffService empty-cwd bursts above.

Happy to share raw (sanitized) log excerpts or a specific timeframe if that helps narrow it down.