Agent hangs forever on “Taking longer than expected…” in gatherTerminalSelections after WSL terminal restore (Cursor 3.20.21)

[thibauld (Thibauld Favre)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Cursor 3.20.21 with a WSL remote workspace, Agent requests can stall indefinitely on Taking longer than expected… and never reach the model.

Client traces show the hang is not network, Grok, or first-token latency. Every sibling context step finishes in 0–2 ms. The only span that never
completes is:

span_started name="gatherTerminalSelections"
# never span_completed

The stuck message stores a live terminal-instance pointer, not just copied text:

uri: vscode-terminal://1
range: lines 7–93
text: ~3609 chars of git status output

After a window reload or wsl --shutdown, the pty host renumbers terminals (old id …-4 → new id 1, later …-2 → new id undefined). The stored URI no
longer resolves. gatherTerminalSelections never times out, so the request is wedged forever.

Worse: the attachment is copied into later bubbles. Sending a new message in the same chat (“just reply OK”, no terminal selected) still hangs in the
same span. Reloading Cursor / shutting down WSL does not unbrick that chat.

A different chat in the same window, with no terminal attachment, recovered after Stop + Reload Window.

Note: This is following up on this discussion with @Colin here: Taking longer than expected in almost every Grok run - #30 by Colin

Steps to Reproduce

Open a WSL remote workspace (Ubuntu 24.04) in Cursor 3.20.21, Agent layout.
2. Open an integrated terminal, run a command with a lot of output (e.g. git status during a merge).
3. Select that terminal text so it attaches to the Agent input (terminal chip / vscode-terminal: URI).
4. Send a prompt.
5. Reload the window, or quit Cursor, run wsl --shutdown, reopen. Persistent terminals revive under new pty IDs.
6. Retry the same chat (or send any new message in that chat).

Expected Behavior

Context gathering should fail fast if the terminal URI is gone, then send the request using the already-stored text / rawText (or drop the
attachment).
• gatherTerminalSelections / buildIdeState should have a timeout and surface an error, not hang the Agent loop forever.
• A later message in the same chat should not inherit a dead terminal URI from history.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.20.21 (user setup)
VS Code Extension API: 1.128.0
Commit: f09fca384ceca23f7bf21f9c23655b162641d740
Date: 2026-09-13T19:02:51.781Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200Version: 3.20.21 (user setup)
VS Code Extension API: 1.128.0
Commit: f09fca384ceca23f7bf21f9c23655b162641d740
Date: 2026-09-13T19:02:51.781Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Auto: balance

For AI issues: add Request ID with privacy disabled

All stall in gatherTerminalSelections (same composer 45513b17-ca45-40ac-b401-2e97de461a93):

• e78b2165-77c3-480d-bc65-f39c281d2195
• 17f64942-9aca-429c-8d71-4fc011d9adf4
• 3dcd4a4b-ae82-41fc-ad0a-547d811770b9
• 9ede7ce2-f62f-4b4f-81d1-e7e10f0f54e1
• 1bcefbc2-b89c-4cd2-aea4-1f988d4970e1 (after full WSL shutdown + Cursor restart)
• f714ada1-250d-4a58-a5e6-aa36d1dcebc2 (fresh “just reply OK” in the same chat — still hung)

Related, different composer (74987073-…), no terminal attachment — hung in buildIdeState after a brief Remote Extension Host unresponsive event,
recovered after Stop + Reload Window:

• hung: 5e8a8884-37d4-42a2-bd29-2aef0e36be46
• recovered: 4f129285-7572-40a9-9e77-35eedd3df887 (same chat, after reload; reached networkPhase / rpc.run)

Additional Information

Cursor: 3.20.21 (f09fca384ceca23f7bf21f9c23655b162641d740), Windows client, unified Agent layout
• Remote: WSL Ubuntu 24.04 (wsl+Ubuntu-24.04)
• Model: not Grok. Earlier turns used DeepSeek V4 Pro; later Auto. Provider registration completed in ~1 ms. No HTTP/2 / 503 / transport errors.
• Logs:
• %APPDATA%\Cursor\logs\window1\output_*\cursor.requestTraces.log
• %APPDATA%\Cursor\logs\window1\renderer.log — Extension host (Remote) is unresponsive. around the second hang
• WSL ~/.cursor-server/data/logs//ptyhost.log — Revived process, old id … → new id 1 then Couldn’t get layout info… Could not find pty 2
on pty host
• Persisted state: two bubbles in that composer have context.terminalSelections pointing at vscode-terminal:/home-thibauld-fairmint-v2-api/1.
Composer-level terminalSelections is empty. The poison is in message history, which is why retries keep hanging.
• Workaround that does not work for the poisoned chat: Stop, reload, wsl --shutdown, new message in the same chat.
• Workaround that does work for an unrelated chat: Stop + Reload Window when there is no terminal attachment (the buildIdeState case).
• Workaround that should unbrick the poisoned chat: quit Cursor, strip terminalSelections from those bubbles in state.vscdb, reopen. Do not use
Restore Checkpoint / Revert Files if the workspace has real uncommitted work.
• Prevention: paste terminal output as plain text; do not attach a live terminal selection.

This looks like a missing timeout on buildComposerSelectedContext children. A dead vscode-terminal: URI or a dropped remote-ext-host RPC leaves the
Agent loop waiting forever, and the UI only shows “Taking longer than expected…”.

Happy to share the request-trace files / composer IDs privately.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[thibauld (Thibauld Favre)]

@Colin besides the above I can tell that the latest Cursor release seems more stable so far. I’ve been working on several chats during a couple hours without having the issue

[thibauld (Thibauld Favre)]

It was too good to last unfortunately…
Follow-up: a second hang mode with no terminal attachment, plus a leaked extension host on Reload Window

Still on 3.20.21 (f09fca384ceca23f7bf21f9c23655b162641d740), WSL Ubuntu 24.04 remote. New hang today, request ID 473cd040-67d6-417c-b92c-4ea78a48d704,
composer 1bcda646-2949-4e96-b44b-a3b65fed7f49.

This one is not the gatherTerminalSelections case from the original report. It hangs one level up, in buildIdeState:
23:02:24.407 span_started name="buildIdeState"
23:02:24.407 span_completed name="gatherTerminalSelections" durationMs=0
23:02:24.407 span_completed name="gatherCursorRules" durationMs=0
23:02:24.407 span_completed name="gatherCursorCommands" durationMs=0
23:02:24.407 span_completed name="gatherImageSelections" durationMs=0
23:02:24.407 span_completed name="gatherPlans" durationMs=0
→ buildIdeState never completes, so buildComposerSelectedContext and client.ttft never complete

I verified against the persisted state that 0 of the 247 bubbles in this composer have context.terminalSelections, and composer-level terminalSelections is empty. So there’s no dead vscode-terminal: URI involved at all.

Three things that I think narrow this down:

1. The extension host was healthy. In my earlier buildIdeState hang (5e8a8884-37d4-42a2-bd29-2aef0e36be46) there was an Extension host (Remote) is unresponsive event 51 s before. Not here — the last unresponsive event in renderer.log was at 16:58:45, and this request was submitted at 19:02:24 local. So an ext-host stall is not a precondition; buildIdeState can simply never settle on its own.

2. Intermittent, not corrupted state. In the same trace log, buildIdeState started 30 times and completed 29, all in 0–2 ms. This exact composer completed it four times earlier the same session (21:31, 21:51, 22:12, 22:20 UTC) before hanging on the fifth. Unlike the terminal-selection case, resending in the same chat is not deterministically poisoned.

3. Developer: Reload Window leaks the remote extension host. This is the part I’d most like someone to look at, because Reload Window is the workaround for hang mode 2. After reloading at 15:53, the old remote extension host never exited:

PID 1187 elapsed 04:30:20 RSS 842 MB ← orphan, from the 15:01 session
PID 30823 elapsed 03:34:51 RSS 1048 MB ← live host, from the 15:53 reload

Both are children of the same server-main.js (PID 918). The orphan has logged this every 5 s for 3.5 hours in
~/.cursor-server/data/logs//exthost1/remoteexthost.log:
[warning] [ExtHostCursor] Failed to check unresponsive extension host diagnostics gate Canceled
[warning] [ExtHostCursor] Failed to flush aggregating metric batch Canceled

The spam begins at 15:53:45.363, exactly matching remoteagent.log:
15:53:45.328 [ManagementConnection] The client has disconnected gracefully, so the connection will be disposed.
15:53:48.792 [ExtensionHostConnection] New connection established.
15:53:48.813 [ExtensionHostConnection] <30823> Launched Extension Host Process.

So each reload costs ~840 MB and a process that keeps polling forever. It also seems like a plausible mechanism for the intermittent buildIdeState hang: with two extension hosts registered against one server, a main-thread RPC could be routed to the disconnected one and never answered.

Also: the composer’s persisted state ends up inconsistent. status is “aborted” while unfinishedRunAt is still set to the submit timestamp and latestChatGenerationUUID points at the hung request. state.vscdb had not been written for 20 minutes after the hang, which is presumably why the UI spinner never clears even though the run is considered aborted.

Environment note, in case it’s relevant: that conversation was at 85.7% context (219,388 / 256,000 tokens, 247 messages). I doubt it’s causal — the hang is before any network call, and smaller requests hung too — but including it for completeness.

Summary of the two modes so far:

Both are unresolved children of buildComposerSelectedContext. A timeout with an error surfaced to the UI on each child would turn all of this from “wedged forever with no information” into a retryable error.

Happy to send the full request-trace logs, renderer.log, and ptyhost.log privately.

UPDATE:
After 473cd040 hung in buildIdeState, two later requests in different composers (fef68e2f, aeb68d3e) hung at the same span with gatherTerminalSelections completing in 1 ms. No buildIdeState has completed in this window since 19:02. ComposerWakelockManager stacked three unreaped agent-loop wakelocks (ids 33–35). So a single unsettled buildIdeState appears to poison the whole window until Reload Window.

[mohitjain (Mohit)]

Thanks for the detailed follow-up, and for splitting the two so clearly. Confirming from our side: the follow-up request never left your machine, so this is entirely client-side, not your setup. We’ve let the team know about both - the context-gathering step wedging the window, and Reload Window leaving the old remote host behind.

While it’s looked at:

• Wedged window (no terminal attached): Reload Window unblocks it but, as you found, leaves the old remote host running. Since that host lives on the WSL side, a full quit of Cursor + wsl --shutdown, then reopen, clears the leaked hosts more completely. Heads up: wsl --shutdown stops everything in WSL, so save any other WSL terminals/servers first.
• Terminal-attachment chat: that one’s stored in the chat history, so reload/shutdown won’t clear it - edit the first message with the terminal chip, remove it, and resend (or start a new chat). Pasting terminal output as plain text avoids it entirely.

If you can send the full request-trace, renderer.log, ptyhost.log and remote exthost log to [email protected] referencing this thread, that’d help a lot. I’ll post here when there’s an update.

[thibauld (Thibauld Favre)]

Thanks @mohitjain Sent!

[thibauld (Thibauld Favre)]

Update: the two hangs are separate bugs with separate fixes, and the buildIdeState one is caused by the leaked extension host I reported as a side note. Quitting and restarting Cursor does not kill the WSL-side hosts — it adds another one.

Thanks for confirming it’s client-side, and for passing both along. I’ve emailed the logs to [email protected] referencing this thread.

I’ve now fixed one of the two hangs on my machine and, in doing so, isolated the other. This supersedes a couple of things I said earlier, including a hypothesis from my own last post that turned out to be wrong. Still 3.20.21 (f09fca384ceca23f7bf21f9c23655b162641d740), WSL Ubuntu 24.04 remote, multi-root workspace.

---

Summary

	Hang A	Hang B
stalled span	gatherTerminalSelections	buildIdeState
cause	a vscode-terminal: chip whose pty id no longer exists	a main-thread RPC to an orphaned remote extension host
trigger	Ctrl+L on a terminal whose pty was renumbered	accumulating leaked ext hosts; hits unrelated chats
survives Reload Window	yes	yes
survives full app restart	yes (persisted in state.vscdb)	yes — the WSL server and its hosts outlive the client
fix	strip terminalSelections from the composer in state.vscdb	full quit + wsl --shutdown

1. Hang A: Ctrl+L on a renumbered pty (reproducible)

Request e0aa4e88-dd84-4f3f-bc8f-94408bb61b0d, composer eb867dd9…. Hung the instant I pressed Ctrl+L.

18:40:38.348 span_started   buildComposerSelectedContext
18:40:38.348 span_started   buildIdeState
18:40:38.348 span_started   gatherTerminalSelections     <-- never completes
18:40:38.349 span_completed gatherPlans           durationMs=0
18:40:38.349 span_completed gatherImageSelections durationMs=1
18:40:38.349 span_completed gatherCursorRules     durationMs=1
18:40:38.349 span_completed gatherCursorCommands  durationMs=0
18:40:38.349 span_completed buildIdeState         durationMs=1

Small correction: gatherTerminalSelections is a sibling of buildIdeState under buildComposerSelectedContext, not a child.

At session start the pty host had renumbered a terminal:

ptyhost.log
00:22:04.326 [info] Revived process, old id 02497afbb57e16142f7ecba58c7d0494-4 -> new id 1

The message carried 7 chips. Numbers 1–6 were replayed history (ids 2 and 4); number 7 was the fresh Ctrl+L at id 1, the pty renamed from 4. Chips replayed from history do not hang — three earlier requests in that chat carried 1–6, including the nonexistent id 4, and completed in 0–1 ms. Only a fresh attachment wedges it, which suggests that’s the only path where the URI is really resolved against the pty host.

Incidental: the message had no text at all, just chips. text is "", richText one empty paragraph.

Repro: open a WSL-remote workspace with a persistent terminal; get the pty renumbered (reload, or wsl --shutdown and reconnect) and confirm Revived process, old id <ws>-N -> new id M in ptyhost.log; press Ctrl+L on that terminal and submit.

Correction to my earlier “no terminal attachment” claim. I previously reported that the buildIdeState hang occurred in a chat where “0 of 247 bubbles have context.terminalSelections”. That read the wrong field. In 3.20.x chips live in context.mentions.terminalSelections, a dict keyed by a JSON blob; the legacy context.terminalSelections list is empty in every chat, so checking it looks like clean confirmation. That composer actually had 7 chips across 11 bubbles at ids 1, 2 and 4. 24 of my chats carry chips this way.

Confirmed fix for Hang A. With Cursor fully quit, I emptied terminalSelections for that composer — both shapes on every bubble plus the composer-level copy. Result: gatherTerminalSelections now runs and completes 4 of 4, and the chat sent successfully. Reload Window does not fix this; worse, it flushes the wedged message’s chips into conversation history (it added two more poisoned bubbles and populated the composer-level copy where it had been null), turning a recoverable hang into a permanent one.

2. Hang B is the extension host leak — and I had the cause backwards

In my last post I suggested a stuck gatherTerminalSelections might precede every buildIdeState hang, based on 2 of 2 sessions. That hypothesis is dead. After stripping the chips I got a clean counterexample in a single renderer window:

window output_20260915T163916
  gatherTerminalSelections  started=4  completed=4   <-- all fine
  buildIdeState             started=4  completed=2   <-- 2 stuck

20:43:48.407 span_started buildIdeState   req=27e24d07-…  composer=eb867dd9…   never completes
20:47:05.849 span_started buildIdeState   req=012fd351-…  composer=2e105369…   never completes

Two different chats, no stuck terminal span anywhere in the window. So buildIdeState wedges on its own, and the correlation I reported was coincidence — both reloads and terminal hangs cluster around the same events.

What does track it is the orphaned extension hosts, which is the thing I reported last time as an incidental side effect of Reload Window. The critical part I had wrong: quitting Cursor entirely does not kill them. The WSL-side server-main.js outlives the client, so every client restart adds another host rather than replacing it. Right now:

server PID 1208, started 08:33:58, up 8h15m

remote extension hosts, all children of 1208:
  PID   1476   started 08:33:58   1068 MB
  PID 141637   started 15:19:51    837 MB
  PID 157861   started 16:17:32    960 MB
  PID 171543   started 16:38:31    989 MB
                                  ------
                                   3.7 GB across 4 hosts

All four are alive and all four are still writing this to their own remoteexthost.log, every few seconds, concurrently:

16:49:40.718 [warning] [ExtHostCursor] Failed to check unresponsive extension host diagnostics gate Canceled
16:49:39.339 [warning] [ExtHostCursor] Failed to flush aggregating metric batch Canceled

I reloaded once and restarted the app twice today; that’s exactly the four hosts. And buildIdeState’s hit rate degraded as they accumulated — with three hosts it completed 4 of 4 in the preceding window, with four it completed 2 of 4. Small sample, but it matches the mechanism: with N hosts registered against one server, a main-thread RPC can be routed to a disconnected one and never answered. buildIdeState is the span that does that, which is why every one of its traced children completes while it does not.

This also explains why it takes down unrelated chats and why it looked triggerless: it has nothing to do with the conversation, only with which host the RPC lands on.

ComposerWakelockManager behaves consistently with this: the successful request acquired id 0 at 16:39:26 and cleanly released it at 16:40:31 (generation-ended), while the two hung ones acquired ids 1 and 2 at 16:43:48 and 16:47:05 and never released.

Fix for Hang B: a full quit of Cursor plus wsl --shutdown, exactly as you suggested. A client restart alone is not enough, and it makes things worse over time. Worth putting that in your guidance explicitly, because “quit and restart Cursor” is the natural reading and it’s counterproductive here.

3. Asks

• A timeout on each buildComposerSelectedContext child, with the error surfaced in the UI. All hangs here would have become retryable errors instead of indefinite spinners.
• Dispose the previous remote extension host on reload and on client disconnect. This looks like the root cause of Hang B, not a memory-leak footnote. Alternatively, have the main-thread RPC reject when its target host is disconnected.
• Reconcile the renderer’s terminal URIs against the pty host’s ids after a revive, so a chip can’t reference an id that no longer exists.
• Don’t flush an unsent, wedged message’s context into conversation history on reload.

For anyone hitting these: they need different fixes. If gatherTerminalSelections is the stalled span, strip terminalSelections from that composer in state.vscdb with Cursor closed, checking context.mentions.terminalSelections and not just the legacy list. If buildIdeState is stalled, quit Cursor completely and run wsl --shutdown — reloading or restarting the client will not clear it.

[glebbb (Gleb)]

I"m on version 3.20.19 and also seeing hang b without using WSL or remote sessions.

It managed to nuke my long running window with a ton of agent chats i kept cloning, a pretty big context loss

Cursor 3.21.9 (4ca72da3…), Windows 10 10.0.26200, local workspace (not WSL remote)

1. Request IDs (from traces, so they can look them up even if the UI is dead):
   • 6d7574e5-31df-4321-985e-4b125d9cbe6c (VERY LAST REV, 02:05:23)
   • 550c506d-8d28-41f0-83b1-f85d5eb97f29 (HARDWARE TEST, 02:11:56)
2. Zip of C:\Users\gleb\AppData\Roaming\Cursor\logs\20260918T020249\
   Especially window1\output_20260918T020257\cursor.requestTraces.log, window1\renderer.log, and main.log
3. Short description: Hang B, not Hang A. gatherTerminalSelections completed in 1–3ms; buildIdeState never completed in 2/2 requests in window1. Window2 in the same session completed buildIdeState in 2ms. Agent-exec host pid 55560 went unresponsive at 02:05:00, 23s before the first hang. Window1 then died at 02:17:04 with ipc-client-disconnect after ~11.7 min, releasing 2 orphaned agent-loop wakelocks. Full quit does not restore the chats to a sendable state; this is Windows local, so wsl --shutdown does not apply.
4. Ask for a timeout on buildComposerSelectedContext children and for main-thread RPCs to fail if the target extension host is disconnected, instead of spinning forever.

sent the logs to hi@cursor

[glebbb (Gleb)]

If anybody else sees this, I got this advice from another thread,press “Ctrl+Shift+P” and run “Developer: GC Agent KV Blobs”-- this managed to restore the window... or maybe a day or 2 passed and it's a coincidence

[thibauld (Thibauld Favre)]

Hang C: buildIdeState hangs when the plugin MCP census times out at startup — not Hang A, not Hang B

@mohitjain follow-up. Same “Taking longer than expected…” UI, same buildIdeState span as Hang B, different cause. Confirmed on a later Cursor build (after 3.20.21), Windows + WSL Ubuntu 24.04, multi-root workspace.

Hang A (gatherTerminalSelections / dead terminal chip) and Hang B (leaked remote extension hosts) are still real. This is a third path into the same spinner.

---

What happened

On Sep 22 every Agent request hung at buildIdeState until I recovered the MCP census. gatherTerminalSelections completed in ~4 ms. The hung composer had zero terminal chips. There was exactly one remote extension host, ~9 minutes old, responsive, no “Canceled” spam — so this is not Hang B.

A brand-new empty chat hung identically (b0eec6da-e793-4bbd-bbcf-e5de4701a19b). That rules out poisoned chat history.

The correlating signal is in window1/workbench.mcp.files.log:

17:44:05  Plugin MCP census: {"trigger":"reset","providerOutcome":"timeout",
          "descriptorsReceived":0,"pluginServersAssigned":0,"effectiveTotal":1}
17:44:35  [error] Error creating client: MCP IPC timeout:
          mcp.runCommand.mcp.createClient exceeded 30000ms

Eight plugin MCP servers never registered (cloudflare ×4, google-drive, linear, sentry, slack). After toggling one plugin server off and on:

18:13:04  Plugin MCP census: {"trigger":"plugins_changed","providerOutcome":"ok",
          "descriptorsReceived":8,"pluginServersAssigned":8,"effectiveTotal":10}

New chats then completed immediately (efe28b4a, c51ad252). No reload, no wsl --shutdown.

Every request I have logs for:

Local time	Request	Census	Result
12:59	b7f0ca5d	ok, 8 descriptors	ok
16:28	2c94ab96	ok	ok
16:35	c6413d1b	timeout, 0 descriptors	hung, buildIdeState
17:37	298609a2	timeout	hung, client.ttft
17:51	61c59fbe	timeout	hung, buildIdeState
18:08	b0eec6da (empty new chat)	timeout	hung, buildIdeState
18:15	efe28b4a / c51ad252	ok after toggle	ok

The census timed out at startup on every app launch that day (16:27, 17:36, 17:43). It only went healthy via plugins_changed. It had been healthy on Sep 20.

---

Two-layer workaround

1. Unwedge the window: Settings → MCP & Integrations → toggle any plugin server off, then on. New chats work as soon as providerOutcome is "ok".
2. Unwedge a chat that already hung: Reload Window. After the census recovered, resending in the original chat still hung at abortChatAndWaitForFinish waiting on the phantom in-flight request. Reload cleared that. Confirmed the next morning: original chat works after Reload Window only (no wsl --shutdown, no state.vscdb edit).

Reload is safe here because there are no terminal chips. It is not safe for Hang A.

Expect the MCP census to time out again on the next cold start / reload. Toggle a plugin server before sending, or you land back in Hang C.

Restarting Cursor / wsl --shutdown does not fix Hang C; the census just times out again.

---

Asks

• Timeout (and fail) buildIdeState if MCP tool enumeration never settles. Same ask as before: don’t spin forever.
• Plugin MCP descriptor provider on WSL remote: trigger:"reset" currently times out (descriptorsReceived:0). plugins_changed succeeds. Startup should use the path that works, or retry after timeout instead of leaving the Agent loop wedged.
• Don’t block abortChatAndWaitForFinish forever on a request whose context gather already deadlocked.

Happy to send workbench.mcp.files.log, mcpprocess.log, and cursor.requestTraces.log from session 20260922T174320 to [email protected] referencing this thread.

[mohitjain (Mohit)]

@thibauld Hang C is a separate third path, confirmed on our side. To unblock: toggle any plugin MCP server off then on to bring the census back to “ok” so new chats send again, then Reload Window to clear a chat that already hung (safe here, no terminal chip). The fix you keep pointing to, a timeout on buildIdeState so it errors instead of spinning, is what we’re tracking, and the MCP-census startup timeout is now in as one of its triggers. If you can, send workbench.mcp.files.log, mcpprocess.log, and cursor.requestTraces.log to [email protected] referencing this thread.

@glebbb same buildIdeState wedge but local with no WSL, so wsl --shutdown doesn’t apply. Since a full restart didn’t clear it, “Developer: GC Agent KV Blobs” from the command palette is your best lever for a stuck window. Your logs and IDs are in with the same issue we’re tracking, and the local repro helps since it shows this isn’t remote-only.

[glebbb (Gleb)]

Hey Mohit, are there any news on the buildIdeState wedge? It keeps happening and I’m getting real frustrated perma losing Cursor windows with many agent tabs. This is a a serious bug that causes people serious amounts of rework and lost tokens.

GC KV Blobs and restarting the extension host does not reliably fix this issue, it kills that window with no recourse.

I sent another email with all the logs attached but also posting for visibility!