On Windows, Agent/Composer chat in the same Cursor window as an active Python debugpy session gets stuck on “Taking longer than expected…” and never streams a first token.
A brand-new chat in that debug window hangs the same way. A chat in a different Cursor window (no debug session) works normally. The Python program itself already finished — debug console printed the completion log — but the hung Agent request does not recover.
Steps to Reproduce
Open a Python project in Cursor IDE on Windows.
Start Run and Debug (debugpy). Hit a breakpoint, or let the script run to the last line.
In that same window, open a new Agent chat and send any short message (reproduced with Composer 2.5 Fast and Grok 4.6 Extra High Fast).
The chat stays on “Taking longer than expected…” indefinitely.
Let the Python process finish. Debug console shows completion. The hung chat still does not recover.
Open Agent in another Cursor window that is not debugging — that chat works.
Expected Behavior
Agent should stream a reply even while debugpy is paused. Finishing or stopping the debugger should not leave a new chat wedged. If IDE-state collection is slow, the request should time out with an error instead of hanging forever on “Taking longer than expected…”.
Hey, thanks for the detailed report. The logs and the Request ID help a lot.
Based on what you shared, this is what it looks like. The request gets stuck locally before it’s even sent. In your requestTraces.log, buildIdeState starts but never reaches span_completed. That’s why the chat stays on “Taking longer than expected…” with no error and no timeout. This also matches what you saw where another window works fine when there’s no active debug session. So it’s not a network issue, not the model, and not something in your setup.
This is a known issue and we’re tracking it on Windows. I’ve added your case to it. The detail about the debugpy session is new and really useful.
The workaround you already found is still the most reliable one for now. Keep Agent chat in a separate Cursor window from the one running the debugger.
To confirm the debugger is the trigger, two tests would help:
Create an empty folder and open it in Cursor via File > Open Folder.
Add one file hello.py with print("hi").
Start it via Run and Debug using F5 with Python Debugger.
While the debug session is active, open a new Agent chat and send “hello”. Does it reply, or does it hang on “Taking longer than expected…”?
Go back to your normal Python project, fully stop the debugger so there’s no active debug session, open a new Agent chat, and send “hello”. Does it reply?
If the chat hangs in any of these tests, please run Developer: Capture and Send Debugging Data in the same window via Command Palette using Ctrl+Shift+P with default settings, then reply here with the result of each step, the Request ID of the hanging request, and the send time including your timezone. That bundle will show exactly which local step it’s getting stuck on.
I can’t share an ETA yet, but I’ll post in the thread if there’s an update.
Follow-up for @deanrie — this is your test #2 (debugger fully stopped), and it still hung.
**When:** 2026-09-20 15:06 CST (UTC+8)
**Window:** same Python project as before (KingDeeCleaningBillSynBI). Source Control was open; PowerShell idle; **no active debugpy session** (yellow in the editor was git diff, not a breakpoint).
**Chat:** brand-new Agent chat, Grok 4.6 Extra High Fast. Same window hung; a different Cursor window without that project still worked.
**Request IDs**
Hung new chat: `46564b07-4e0a-4f46-bc97-d3f251a4703e` (composerId `669ecf8b-8e3a-4ebf-affd-2cd291654952`)
Hung older chat in the same window two minutes earlier: `bf24b8ad-c6c1-425f-a9f6-d03a11164c51` (composerId `5095385f-c515-4ac4-a221-ed1d2c663cd0`)
Both traces: `buildIdeState` started, never `span_completed`. `gatherTerminalSelections` completed in a few ms.
**What happened to the extension host in that window before the hang**
```
2026-09-20 14:32:08 [IdleTimeContribution] Hard stopping cursor builtin extension hosts after 30 idle minutes (threshold=30, freeMemory=7.7%, freeMemoryThreshold=10%).
```
After that, repeated:
```
Error fetching user privacy mode: No Connect transport provider registered.
Error: No Connect transport provider registered.
```
Then at 15:02 the window regained focus and restarted extension hosts, and at 15:04 / 15:06 the Agent requests stuck on `buildIdeState`.
So debugger is not required. After idle-kill of builtin hosts (low free memory), this project window still wedges Agent on `buildIdeState`. I can run `Developer: Capture and Send Debugging Data` from that hung window if you want the bundle.
Hey, thanks for running test #2 and sharing the log lines. That answers the question, the debugger isn’t the trigger. The common factor in both cases is that the built-in extension host was stopped by the idle killer in that window when free memory was low, freeMemory=7.7%, and then restarted. After that, the window hangs the Agent on buildIdeState. The No Connect transport provider registered lines are the window noting that the host was off at that moment, not the cause of the hang.
Yes, please send the bundle. In the hung window, open the Command Palette with Ctrl+Shift+P, run Developer: Capture and Send Debugging Data with the default settings, then reply here with the send time including your timezone and the Request ID of the hung message. It’s uploaded directly from your account, nothing else needed.
One more quick test will help narrow this down. Both times the hang happened with the terminal open in the window.
In the project window, run Developer: Reload Window from the Command Palette.
Close the terminal panel with Ctrl+J until it hides, and close Source Control.
Open a new Agent chat and send “hello”. Does it reply?
Now open the terminal again with Ctrl+J, keep it visible, open another new Agent chat, and send “hello”. Does it reply or hang?
No need to update. You’re already on the latest stable 3.21.16, and it reproduces there. This is a known issue we’re tracking on Windows, and your case is attached to it. Until it’s fixed, the reliable workaround is to keep the Agent chat in a separate Cursor window, or in the Agents Window via Open Agents Window in the Command Palette. I don’t have an ETA yet, but I’ll post here when there’s an update.
The fix for the Agent chat getting stuck on “Taking longer than expected” in your project window is included in the latest version of Cursor.
Looks like you’ve already updated, so this should be resolved for you. Can you confirm that new Agent chats in that project window (KingDeeCleaningBillSynBI) are responding normally now?
If anything is still getting stuck, let me know, include the Request ID from the stuck message, and we’ll take another look. Also, thanks again for the tests, they really helped us figure this out.