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

**URL:** <https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663>\
**Category:** Bug Reports\
**Tags:** terminal, chat, context, wsl\
**Created:** [September 14, 2026, 8:12pm UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663 "2026-09-14T20:12:13Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![thibauld](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/thibauld/32/3844_2.png) [@thibauld](https://forum.cursor.com/u/thibauld)\
**Post date:** [September 14, 2026, 8:12pm UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663/1 "2026-09-14T20:12:13Z")

</div>

### 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](https://forum.cursor.com/t/taking-longer-than-expected-in-almost-every-grok-run/169673/30)

### 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

 ![Screenshot 2026-09-14 143940.png](https://us1.discourse-cdn.com/cursor1/original/3X/f/e/feb94161449409eee0b8a81d2144d3455a5b3166.png)

### 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

---

<div class="post-metadata">

**Author:** ![thibauld](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/thibauld/32/3844_2.png) [@thibauld](https://forum.cursor.com/u/thibauld)\
**Post date:** [September 14, 2026, 9:46pm UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663/5 "2026-09-14T21:46:37Z")

</div>

@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 👍

---

<div class="post-metadata">

**Author:** ![thibauld](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/thibauld/32/3844_2.png) [@thibauld](https://forum.cursor.com/u/thibauld)\
**Post date:** [September 14, 2026, 11:35pm UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663/6 "2026-09-14T23:35:35Z")

</div>

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:

 ![image](https://us1.discourse-cdn.com/cursor1/original/3X/d/a/da0a2edd7bcb851e9be744ed133e091d8f448830.png)

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.

---

<div class="post-metadata">

**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\
**Post date:** [September 15, 2026, 9:23am UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663/10 "2026-09-15T09:23:26Z")

</div>

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 [hi@cursor.com](mailto:hi@cursor.com) referencing this thread, that’d help a lot. I’ll post here when there’s an update.

---

<div class="post-metadata">

**Author:** ![thibauld](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/thibauld/32/3844_2.png) [@thibauld](https://forum.cursor.com/u/thibauld)\
**Post date:** [September 15, 2026, 1:00pm UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663/11 "2026-09-15T13:00:12Z")

</div>

Thanks @mohitjain Sent!

 ![image](https://us1.discourse-cdn.com/cursor1/original/3X/9/8/98229ec48d9c51a4c9815ed7ef5a402f353b4d8f.png)

---

<div class="post-metadata">

**Author:** ![thibauld](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/thibauld/32/3844_2.png) [@thibauld](https://forum.cursor.com/u/thibauld)\
**Post date:** [September 15, 2026, 8:02pm UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663/12 "2026-09-15T20:02:32Z")

</div>

**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 [hi@cursor.com](mailto:hi@cursor.com) 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.

```auto
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:

```auto
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:

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

```

```auto
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:

```auto
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:

```auto
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.

---

<div class="post-metadata">

**Author:** ![glebbb](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/glebbb/32/120872_2.png) [@glebbb](https://forum.cursor.com/u/glebbb)\
**Post date:** [September 18, 2026, 10:26am UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663/13 "2026-09-18T10:26:47Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![glebbb](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/glebbb/32/120872_2.png) [@glebbb](https://forum.cursor.com/u/glebbb)\
**Post date:** [September 19, 2026, 8:28pm UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663/14 "2026-09-19T20:28:11Z")

</div>

`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`😅

---

<div class="post-metadata">

**Author:** ![thibauld](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/thibauld/32/3844_2.png) [@thibauld](https://forum.cursor.com/u/thibauld)\
**Post date:** [September 23, 2026, 7:38pm UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663/16 "2026-09-23T19:38:40Z")

</div>

**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`:

```auto
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:

```auto
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 [hi@cursor.com](mailto:hi@cursor.com) referencing this thread.

---

<div class="post-metadata">

**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\
**Post date:** [September 24, 2026, 10:24am UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663/18 "2026-09-24T10:24:49Z")

</div>

@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 [hi@cursor.com](mailto:hi@cursor.com) 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.

---

<div class="post-metadata">

**Author:** ![glebbb](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/glebbb/32/120872_2.png) [@glebbb](https://forum.cursor.com/u/glebbb)\
**Post date:** [October 1, 2026, 8:53pm UTC](https://forum.cursor.com/t/agent-hangs-forever-on-taking-longer-than-expected-in-gatherterminalselections-after-wsl-terminal-restore-cursor-3-20-21/171663/19 "2026-10-01T20:53:50Z")

</div>

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!