Cursor Agent hangs on “Planning next moves” and ends with ERROR_EXTENSION_HOST_TIMEOUT

[urbanx]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Agent consistently gets stuck at “Planning next moves” and eventually fails with ERROR_EXTENSION_HOST_TIMEOUT.

The Agent execution provider does not respond within the deadline, even though Cursor’s built-in Network Diagnostics reports successful DNS, SSL, API, Chat, Agent, Authentication, and Agent Endpoint tests.

The issue occurs even with a completely fresh Cursor profile and an empty workspace.

Steps to Reproduce

1. Open Cursor 3.20.21 on macOS 27.
2. Start Cursor with a completely fresh user data directory using --user-data-dir.
3. Use an empty workspace with no project files.
4. Open Agent mode.
5. Send a simple request such as: “Reply only with hello.”
6. The Agent remains stuck at “Planning next moves”.
7. After waiting, Cursor reports ERROR_EXTENSION_HOST_TIMEOUT / Agent Execution Timed Out.

The same behavior also occurs with extensions disabled and with GPU disabled.

Cursor 3.19.19 was also tested and shows the same behavior.

Expected Behavior

The Agent should process the request and return a response normally.

For a simple request such as “Reply only with hello”, the Agent should complete within a few seconds instead of remaining stuck at “Planning next moves” and eventually timing out.

Operating System

MacOS

Version Information

Cursor 3.20.21
Electron 42.10.0
macOS 27
Apple Silicon

For AI issues: add Request ID with privacy disabled

3451aa68-a5f1-44e8-9bad-3d46b143d524

Additional Information

Cursor Network Diagnostics:

DNS: Success
SSL: Success
API: Success
Ping: Success
Chat: Success
Agent: Success
Marketplace: Success
Authentication: Success
Authentication UI: Success
Cursor Tab: Success
Agent Endpoint: Success

The Agent diagnostic successfully receives streamed responses, but actual Agent execution consistently times out.

The Agents Window extension host is running while the issue occurs and has multiple established HTTPS connections.

I also tested:

• Fresh Cursor user profile
• Empty workspace
• Extensions disabled
• GPU disabled
• NODE_TLS_REJECT_UNAUTHORIZED=0
• Cursor 3.19.19

All tests show the same Agent timeout.

Error:

ERROR_EXTENSION_HOST_TIMEOUT

Agent Execution Timed Out [deadline_exceeded]

Request ID:
3451aa68-a5f1-44e8-9bad-3d46b143d524

Please check the server-side logs for this Request ID and determine where the Agent execution is timing out.

Does this stop you from using Cursor

Yes - Cursor is unusable

[ganapativs]

Facing same issue. agents are stuck on planning next moves, also Git functionalities does not work, unable to see changed files etc. Agents are totally unusable.

This is after upgrading to MacOS 27. Cursor Version 3.20.21.

[Kal]

@ganapativs

This is after upgrading to MacOS 27. Cursor Version 3.20.21.

Same here - and network diagnostic is not passing too

[Siyuan_Feng]

having the same issue.

SSH connection to remote servers failed within cursor too.

although in my case, all network diagnostic passes.

[Siyuan_Feng]

found the problem:

After updating to macOS 27 on Apple Silicon, Cursor was resolving old Intel Homebrew executables from /usr/local/bin.

I fixed the SSH and Git failures by forcing Cursor to use native Apple Silicon tools:

1. Set these Cursor settings:

"remote.SSH.path": "/usr/bin/ssh",
"git.path": "/Applications/Xcode.app/Contents/Developer/usr/bin/git"

2. Added native wrappers earlier in my PATH:

~/.local/bin/ssh

#!/bin/sh
exec /usr/bin/ssh "$@"

~/.local/bin/git

#!/bin/sh
exec /Applications/Xcode.app/Contents/Developer/usr/bin/git "$@"

3. Reloaded Cursor and reopened the project in a scoped workspace instead of opening /.

After this, Remote SSH connected successfully to marula, and the remote Cursor server started normally.

Bug details

My system is:

• macOS 27.0

• Apple Silicon

• Cursor 3.20.21

The failing SSH log contained:

/usr/local/bin/ssh: Bad CPU type in executable

/usr/local/bin/ssh was an Intel-only Homebrew OpenSSH binary. The native /usr/bin/ssh is arm64 and works.

Cursor’s local extension host also repeatedly logged:

Error: spawn Unknown system error -86

This occurred in Git, retrieval, and cursor-agent-exec. The workspace was also initially opened at /, causing Cursor Agent searches to scan the entire filesystem, which made the “Planning next moves” problem worse.

The forum-reported Agent timeout still appears to be an upstream macOS 27 and Cursor issue. Even after fixing the local executable and workspace problems, a harmless Agent request can remain stuck while “Planning next moves”. Network diagnostics pass, but Agent execution times out.

[urbanx]

Thanks for sharing this. I checked the SSH issue on my system as well.

I’m running:

• macOS 27.0

• Apple Silicon

• Cursor 3.20.21

However, on my system:

which ssh
→ /usr/bin/ssh

file /usr/bin/ssh
→ Mach-O universal binary, arm64e

And /usr/local/bin/ssh does not exist:

/usr/local/bin/ssh -V
→ zsh: no such file or directory

So in my case Cursor is already using the native /usr/bin/ssh.

I also tested Cursor with /usr/bin explicitly placed first in PATH:

PATH="/usr/bin:/bin:/usr/sbin:/sbin:$PATH" /Applications/Cursor.app/Contents/MacOS/Cursor

Unfortunately, the Agent still gets stuck on “Planning next moves” and eventually fails with:

ERROR_EXTENSION_HOST_TIMEOUT

What makes this particularly interesting is that Cursor’s Network Diagnostics reports all of the following as successful:

• DNS

• SSL

• API

• Chat

• Agent

• Authentication

• Agent Endpoint

The Agent diagnostic itself successfully receives streamed responses.

I also reproduced the issue with:

• a completely fresh Cursor profile

• an empty workspace

• extensions disabled

• GPU disabled

• Cursor 3.19.19

So for me it seems to be a different issue than the Intel SSH binary, although the timing with macOS 27 and Cursor 3.20.21 appears to be the same.

Request ID: 3451aa68-a5f1-44e8-9bad-3d46b143d524

Maybe the server-side logs for this Request ID can help identify where the Agent execution is getting stuck.

[urbanx]

I think I found another important clue on my system.

I checked Git because the cursor-retrieval extension appears to call which git and then spawn Git processes.

On my Apple Silicon Mac I had two Git installations:

which git
→ /usr/local/bin/git

file /usr/local/bin/git
→ Mach-O 64-bit executable x86_64

Trying to execute it directly gives:

/usr/local/bin/git --version
→ zsh: bad CPU type in executable

The native Git is:

/usr/bin/git
→ Mach-O universal binary
   x86_64
   arm64e
   arm64e.x1

and works correctly:

/usr/bin/git --version
→ git version 2.54.0 (Apple Git-157)

This is interesting because the Cursor cursor-retrieval extension log was showing:

Error: spawn Unknown system error -86

and the stack trace pointed into cursor-retrieval/dist/main.js.

I temporarily moved the old Intel-only Git out of /usr/local/bin, so which git now resolves to /usr/bin/git.

I’m now restarting Cursor and testing Agent again to see whether this removes the ERROR_EXTENSION_HOST_TIMEOUT.

If the Agent works after this change, the combination of cursor-retrieval → which git → Intel-only Git → spawn error -86 may have been the cause.

I’ll report back with the result.

Solution works for me.

[mohitjain (Mohit)]

Hey all, thanks for the reports, and @Siyuan_Feng for the digging. A few different things are landing here after the macOS 27 update:

Agent stalls / Agents Window times out but Network Diagnostics pass (@urbanx, @Siyuan_Feng): it’s timing out locally before anything reaches us, so it’s not your setup - a macOS 27 issue we’re tracking. For now, run the agent from the classic Editor window (Cmd+Shift+P → “Open IDE”), which usually still works. If you can, grab logs right after a timeout (Cmd+Shift+P → “Developer: Open Logs Folder”), zip them, and attach here.

Git broken / can’t see changed files (@ganapativs): point Cursor at native arm64 tools and reload — "git.path": "/usr/bin/git", "remote.SSH.path": "/usr/bin/ssh" (macOS 27 drops the Intel Homebrew ones @Siyuan_Feng found).

Network Diagnostics failing (@Kal): which checks fail? If DNS/SSL, check System Settings → Privacy & Security → Local Network (enable Cursor) or set DNS to 1.1.1.1. If it’s the Agent checks, it’s the same timeout as above.

I’ll update here when there’s news.

[Kal]

@mohitjain its the Authentication UI, a cursor tab and Agent Endpoint. DNS/HTTP/SSL are loading indefinitely.

DNS is already to 1.1.1.1 and Local Network is enabled for Cursor. Did restart multiple times. To me the login never happn

[ganapativs]

So, the git issue is solved with config update. Thanks for that. Regarding the agent stuck issue, its happening both on IDE and agent window for me. it’s not timing out. just this showing message forever. it’s been more than 1hr of waiting, still same issue.

[ganapativs]

Update: After new update, agent in agent window is working fine now, IDE one is still stuck.

Version: 3.21.9
Commit: 9998796a6096ce83d83a9332bfe7473b985db750

[hokwanhung]

Having a similar issue on Windows, with:

version 3.21.9 (user setup)
VS Code Extension API: 1.128.0
Date: 2026-09-17T02:16:48.732Z
Layout: IDE
Build Type: Stable
Release Track: Default
Node.js: 24.18.1
OS: Windows_NT x64 10.0.22631

[Colin]

Hey @urbanx,
Thanks for digging into this, and glad moving the Intel-only Git out of the way got you unblocked.

We’ve landed a fix for the agent getting stuck on “Planning next moves” and timing out after the macOS 27 upgrade. When an Intel-only git is first on your PATH (macOS 27 doesn’t carry Rosetta over from the previous install), Cursor will now fall back to the system Git instead of hanging. The fix will be included in an upcoming version of Cursor.

Until then, either of these avoids the hang:

1. Remove or rename the Intel-only git in /usr/local/bin so the native one is found first, or
2. Reinstall Rosetta by running softwareupdate --install-rosetta --agree-to-license in Terminal, then restart Cursor.

Setting git.path fixes the Source Control view but not the agent, so one of the steps above is still needed for now.

cc @ganapativs @Kal @Siyuan_Feng