Windows 3.21.16: Agent stuck on “Planning next moves”; Extension host UNRESPONSIVE; Network Diagnostics all pass; HTTP/1.0 and HTTP/1.1 only help temporarily

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Summary

On Windows, Cursor Agent hangs on “Planning next moves” / infinite loading. Network Diagnostics are all OK. Switching HTTP Compatibility Mode (HTTP/1.1, then HTTP/1.0) only helps for a few minutes, then it hangs again. Reload Window / full restart also only helps temporarily.

This looks like a client-side Extension Host / Agent execution stall, not a connectivity failure.

Version / OS

  • Cursor: 3.21.16 (user setup)
  • Commit/distro: d5c0e77a0214208f36b56d42e8e787de88d02ea4
  • OS: Windows 10.0.26200 (x64)
  • Layout: unified Agent

Request IDs

  • 3c4cd8f7-1608-443b-8ffc-c20c8049f164
    Hung chat after attaching multiple local .txt files. No first token. agent.turn.simulated_thinking_timeout at 40s. buildIdeState span started and never completed.
  • This session also logged simulated_thinking_timeout on later turns (e.g. gpt-5.5 requests) while a second composer was open.

Privacy Mode is off for these IDs.

What we already tried

  • HTTP Compatibility Mode HTTP/1.1 (cursor.general.disableHttp2) → briefly better, not a fix
  • HTTP Compatibility Mode HTTP/1.0 → same: works a bit, then hangs again
  • Cursor Settings → Network → Run Diagnostics: all pass while the Agent is still stuck
  • Developer: Reload Window / full quit + restart: recovers for a while, then hangs again
  • Simple chats without file attachments often work; attaching several files, or running two Agent chats at once, hangs much more often

Local logs (this is the important part)

Repeatedly:

Steps to Reproduce

  1. Open Cursor 3.21.16 on Windows.
  2. Open a local workspace (no git installed).
  3. Start Agent chat. Simple text-only messages often work at first.
  4. Attach several local .txt files with @, or keep two Agent chats open at once.
  5. Send a request. The Agent stays on “Planning next moves” / infinite loading.
  6. Cursor Settings → Network → Run Diagnostics: all checks pass while still stuck.
  7. Developer: Reload Window or full quit + restart: works again for a few minutes, then hangs again.
  8. HTTP Compatibility Mode HTTP/1.1 then HTTP/1.0: same pattern, not a durable fix.

Expected Behavior

Agent should stream a first token and either complete or show a real error. It should not sit on “Planning next moves” indefinitely while Network Diagnostics are all green. Reload should not be required every few minutes.

Operating System

Windows 10/11

Version Information

Version: 3.21.16 (user setup)
Commit/distro: d5c0e77a0214208f36b56d42e8e787de88d02ea4
OS: Windows_NT x64 10.0.26200
Layout: unified Agent

For AI issues: which model did you use?

grok-4.6 (hung file-attachment turn). Also reproduced with gpt-5.5 on later turns while a second composer was open.

For AI issues: add Request ID with privacy disabled

3c4cd8f7-1608-443b-8ffc-c20c8049f164
Privacy Mode off.

Additional Information

Local logs from %APPDATA%\Cursor\logs\ (Cursor Structured Logs.log):

Repeatedly:
Extension host became UNRESPONSIVE
extensionHostKind: LocalProcess
activeComposersCount: 2
then shortly after: Extension host became responsive

For request 3c4cd8f7-1608-443b-8ffc-c20c8049f164:

  • stream starts
  • collectPrefetchedFileContents finishes quickly (~46ms)
  • buildIdeState never completes
  • “No first token received” warnings at 2s … 32s
  • agent.turn.simulated_thinking_timeout (threshold_ms=40000)
  • no Received first token, no stream error, UI stays loading

Also on every send:
Error getting git status: Git installation not found.
Git is not installed. Workspace is not a git repo.

System proxy exists but Cursor domains are bypassed. This does not look like ISP/HTTP/2: Diagnostics pass, HTTP/1.1 and HTTP/1.0 both regress after time, Reload recovers immediately.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

Hey @roughing953, thanks for the detailed report. Your read of the logs is right: these turns are stalling on your machine before the request is ever sent, which is why Network Diagnostics pass and HTTP/1.1 or 1.0 only help briefly (you can set HTTP Compatibility Mode back to Automatic). Nothing on your end is causing it, and it’s an issue we’re tracking on Windows in the 3.21 releases.

What helps in the meantime:

  1. When it hangs, run Developer: Restart Extension Host (Ctrl+Shift+P). It clears faster than a full restart.
  2. It’s much worse with several attached files or two Agent chats open at once, so sticking to one chat and fewer files per turn cuts how often it happens.
  3. If it’s really blocking you, the previous stable build (3.20.21) doesn’t have this.

Next time it hangs past ~40s, run Developer: Capture and Send Debugging Data and reply with the time plus the Request ID (⋯ menu → Copy Request ID). That’ll help us pin it down.

8

I think I’m experiencing the same thing on mac, v3.21.16. Came back to work after the weekend today and no agent will ever work, I can’t get anything to get started. Quitting cursor doesn’t work and restarting my computer didn’t work either, so it definitely seems like it updating 2 days ago to 3.21.16 is the only difference from things working fine last week.

I can’t even ask an agent to help me diagnose or sniff through logs to find what the root cause might be. If possible, I can try to give you some info, but you’ll have to tell me what you need and what you want me to do to provide that information for you.

9

@mohitjain follow-up as requested.

Time: 2026-09-22 11:19–11:21 JST (UTC+9)

Ran Developer: Capture and Send Debugging Data. Local zip:
debugging-data-1790043714695.zip (saved 11:21:56 JST)

Request IDs from that hang (same Agent chat, no first token 32s+):

  • accf9a02-c11b-441c-b4e2-95012a4e1b29 — started 11:19:53 JST
  • 932d4f70-aaad-47ba-b738-8290646c77d1 — 32s no first token at 11:21:19 JST
  • 68f747a0-1601-4543-b997-590b3360fdfa — 32s no first token at 11:21:42 JST

At 11:21:21 JST: Extension host became UNRESPONSIVE (activeComposersCount=3).

Developer: Restart Extension Host earlier did not visibly recover the stuck turn. HTTP Compatibility Mode is Automatic.

12

I am having the same behavior. It says it is taking longer than expected.
Version 3.21.16

13

I also encountered the same problem in version 3.21.16 I can work normally after rolling back the version to 3.20.21

14

Hey @roughing953, thanks for grabbing that capture. Those request IDs confirm it: the turns are stalling on your machine before anything is sent, so there’s no server-side trace for them. This is an issue we’re tracking, and captures like yours are what help us pin it down.

@swirle13, you’re hitting the same thing on Mac, and it’s not your setup either.

There isn’t a solid in-place fix yet, but a couple of things reduce how often it hits: keep to one Agent chat at a time with fewer attached files per turn, and if one does get stuck, a fresh window (Developer: Reload Window) clears it for a bit. I’ll post here as soon as there’s a real fix to share.

15

@mohitjain I appear to be reproducing the same issue, and I have additional controlled A/B evidence from Cursor 3.21.18.

In my environment, the Embedded IDE Agent problem was first observed on Cursor 3.21.9 and persisted through subsequent 3.21.x updates:

3.21.9 → 3.21.13 → 3.21.16 → 3.21.18

It is still reproducible on Cursor 3.21.18 Stable as of September 23, 2026.

Current environment:

Version: 3.21.18 (user setup)
Commit: c4730f7d93d787d9ab120af715999f0345ee5bc0
Build Type: Stable
Release Track: Default
OS: Windows_NT x64 10.0.26100
Model: GPT-5.6 Sol Medium

I performed a controlled A/B test using:

  • the same Windows machine
  • the same Cursor installation
  • the same local repository
  • the same Git state
  • the same model (GPT-5.6 Sol Medium)
  • the exact same minimal read-only prompt

Result:

Embedded IDE Agent = FAIL
Separate Agents Window = PASS (~20 seconds)

In the Embedded IDE Agent, the request progresses to “Planning next moves” and then remains stuck on “Taking longer than expected”.

The separate Agents Window completes the same request normally.

Affected Embedded IDE Agent Request ID:

60dd6f95-fff7-474f-bcb0-5aaa51dba511

I also ran Developer: Capture and Send Debugging Data while the failure was active.

For this affected request, the captured logs show:

  • “No first token received within 4s”
  • “No first token received within 6s”
  • “No first token received within 8s”
  • “No first token received within 10s”
  • “No first token received within 12s”
  • “No first token received within 14s”
  • “No first token received within 16s”

During the same affected session, the logs also recorded twice:

“Extension host became UNRESPONSIVE”

with:

extensionHostKind: LocalProcess
activeComposersCount: 1

I am reporting these as observed diagnostic facts and am not asserting a specific root cause.

One potentially useful difference from the original report is that my controlled reproduction does not require multiple Agent chats or several attached files. A minimal read-only workspace health check is sufficient to reproduce the Embedded IDE Agent failure.

The separate Agents Window continues to work on the same machine, repository, Git state, and model while the Embedded IDE Agent fails.

Privacy note:

My current Cursor setting shows “Privacy Mode (Legacy)” as enabled. I have not changed this setting during this investigation. I am therefore providing the Request ID above, but I am not assuming what server-side request data is available from that ID.

I captured the full debugging-data package while the failure was active. The capture included logs, feature flags and extension summary, and process diagnostics.

I am not attaching the debugging-data ZIP publicly because the collected logs contain account identifiers, local filesystem paths, workspace/session identifiers, and local-environment metadata.

I can provide the original debugging-data package privately to Cursor staff through an appropriate private support channel if that would help the investigation.

Please let me know if the Request ID is useful with my current privacy configuration, or if you would like the debugging-data package provided privately.

16

I have thesame issue while using cursor on windows 10. Since Tuesday evening still now i am unable to work.

17

Update: no longer reproducible for me after upgrading to Cursor 3.22.7

A controlled retest after upgrading from Cursor 3.21.18 to 3.22.7 (Windows, Stable) produced a different result.

I repeated the same strict read-only health check in the Embedded IDE Agent, explicitly using GPT-5.6 Sol Medium.

Result on 3.22.7: PASS

The Embedded IDE Agent successfully:

  • accessed the same workspace;
  • read the same roadmap file;
  • returned the current Git branch and HEAD;
  • verified the worktree as clean;
  • completed normally without getting stuck on Planning next moves or Taking longer than expected.

The repository state remained unchanged:

CURRENT_GIT_BRANCH = main
CURRENT_HEAD = 1a58f392d579fb48db331d3be7166ad64e2c3fd8
WORKTREE = CLEAN

This gives me the following controlled comparison:

Cursor 3.21.18
Embedded IDE Agent + GPT-5.6 Sol Medium = FAIL
Separate Agents Window + GPT-5.6 Sol Medium = PASS (~20s)

Cursor 3.22.7
Embedded IDE Agent + GPT-5.6 Sol Medium = PASS

I did not make repository changes to obtain the successful result.

So, at this point, the issue is no longer reproducible in my environment after the upgrade to 3.22.7.

I am not claiming that 3.22.7 definitively fixed the underlying issue or establishing causality — only reporting the controlled before/after result observed on the same machine/workspace.

@mohitjain, do you know whether 3.22.x included any changes related to the Embedded IDE Agent, Agent Host / Extension Host, or the local pre-request path that could explain this change in behavior?

I still have the previously captured debugging-data package available for private submission if it would be useful for comparison with the earlier 3.21.18 failure.

19

Hey @roughing953,

The Agent hang on “Planning next moves” / “Taking longer than expected” was fixed in a recent Cursor update (3.22/3.23). Updating to the latest version should resolve this.

Thanks for the request IDs and debugging capture, they helped track this down. If you rolled back to an older version to work around it, it should be safe to update again.

Let me know if you still hit it after updating.

cc @swirle13 @Chamila_R @li_zhifa @Marcelo_Tomaz @Wendy_Djoumessi