Agent execution provider consistently times out — agent-exec session acquisition fails even in empty workspace after clean reinstall

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Agent consistently fails with “Agent Execution Timed Out” / ERROR_EXTENSION_HOST_TIMEOUT. The failure occurs even for a trivial prompt in a completely empty workspace.

The request reaches buildComposerRequestContext / ExecutorResource.execute, then stalls for approximately 70 seconds. During that period, the renderer repeatedly reports [agent-exec] Session acquisition timed out, beginning with a 30-second timeout followed by repeated 5-second retries.

This reproduces after a clean reinstall of Cursor 3.21.13, resetting Cursor AgentStores and agent-host global storage, removing third-party OpenAI/ChatGPT extensions, and testing in a new empty folder.

There is also a consistent ~58-second delay during startup while anysphere.cursor-agent-host loads. The agent-exec extension host briefly reports as unresponsive and then responsive.

Because the same failure occurs in an empty workspace after a fresh install, it does not appear to be repository-specific.

Steps to Reproduce

  1. Launch Cursor 3.21.13 on macOS.
  2. Open a new empty folder. My clean reproduction used ~/Desktop/cursor-clean-test.
  3. Open a new Agent conversation.
  4. Send: Reply with exactly: AGENT_OK. Do not inspect files, run commands, or modify anything.
  5. Wait approximately 70 seconds.
  6. Cursor displays “Agent Execution Timed Out” with ERROR_EXTENSION_HOST_TIMEOUT / deadline_exceeded.

The failure is reproducible in both my normal project and the empty test workspace.

Clean-workspace reproduction Request ID:
9371275c-ecc3-4d7d-b5ef-b3ef7bb62864

Relevant log behavior:

  • Agent request begins at 14:29:42.731Z.
  • ExecutorResource.execute begins at 14:29:42.792Z.
  • Renderer reports Session acquisition timed out (attempt 1/9, timeout=30000ms), followed by repeated 5-second retries.
  • ExecutorResource.execute completes after approximately 70015ms.
  • The overall request ends after approximately 70245ms with the timeout.

Environment:

  • Cursor 3.21.13
  • macOS 26.6.2
  • Apple Silicon / ARM64
  • Reproduced after fresh Cursor reinstall
  • Reproduced with third-party OpenAI/ChatGPT Cursor extension removed
  • Reproduced in an empty workspace

Expected Behavior

Agent should successfully acquire an execution session and process the request normally. In the clean reproduction, the trivial prompt should return AGENT_OK within a normal response time rather than waiting approximately 70 seconds and terminating with ERROR_EXTENSION_HOST_TIMEOUT.

The cursor-agent-exec / cursor-agent-host runtime should also initialize without the consistent ~58-second startup stall and should remain available for subsequent Agent requests.

Screenshots / Screen Recordings

Screenshot 2026-09-19 at 8.49.49 AM.png
Screenshot 2026-09-19 at 8.49.49 AM.png2992×1934 318 KB

Operating System

MacOS

Version Information

Version: 3.21.13
VS Code Extension API: 1.128.0
Commit: e44a49c17e334d442e58bbde931d791200f014a0
Date: 2026-09-18T06:43:24.799Z
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: Darwin arm64 25.6.0

For AI issues: which model did you use?

Cursor Grok 4.6 High Fast. Also reproduced with GPT-5.6 Sol Medium. The failure occurs during agent execution/session acquisition rather than model response generation.

For AI issues: add Request ID with privacy disabled

Privacy mode status could not be verified/changed in Cursor 3.21.13 because no Privacy Mode setting is exposed in the current Settings UI.

Clean-workspace Request ID: 9371275c-ecc3-4d7d-b5ef-b3ef7bb62864

Additional Information

This reproduces in a completely empty workspace (~/Desktop/cursor-clean-test), so it is not specific to my repository or project configuration.

I performed a clean reinstall of Cursor 3.21.13, reset Cursor AgentStores and agent-host global storage, and removed the third-party OpenAI/ChatGPT extension before reproducing.

Cursor’s built-in cursor-agent-host takes approximately 58 seconds to activate at startup. After activation, even a trivial Agent request (“Reply with exactly: AGENT_OK”) fails.

The request trace shows ExecutorResource.execute / WorkbenchRequestContextExecutor.execute blocking for approximately 70 seconds. Renderer logs simultaneously show repeated:

Session acquisition timed out

beginning with a 30-second timeout followed by repeated 5-second retries.

Clean-workspace reproduction Request ID:
9371275c-ecc3-4d7d-b5ef-b3ef7bb62864

This behavior persists after a fresh application install and in an empty workspace.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report with logs and the Request ID. That makes debugging a lot easier.

The request is failing before it even leaves your machine, so an empty folder and a reinstall behave the same. This matches a known issue we’re tracking. Agent sends can hit a timeout when the Index Repositories for Instant Grep setting is turned off. Reinstall keeps your settings, so the state carries over.

Can you try this:

  1. Open Cursor Settings with Cmd+Shift+J.
  2. Go to the Indexing tab.
  3. Find Index Repositories for Instant Grep. If it’s off, turn it on and accept the Reload Window prompt.
  4. Fully quit Cursor with Cmd+Q, then open it again.
  5. Open an empty test folder, start a new Agent chat, and send “hello”.

Do you get a response within a couple seconds? If the setting was already on, or the timeout still happens, run Developer: Capture and Send Debugging Data from the Command Palette with Cmd+Shift+P right after a failed send, then post the approximate time you ran it so we can check the full logs.

Separately, the ~1 minute delay on startup while the agent runtime loads is a different issue we’re also looking into. It shouldn’t block sends once loading is done.

Let me know how it goes.

7

Thanks, Dean — that fixed it. “Index Repositories for Instant Grep” was turned off. I turned it back on, reloaded Cursor, fully quit and reopened it, and Agent is responding normally again.

I really appreciate you tracking this down. I had tried reinstalling Cursor and testing in an empty folder, so knowing that the setting persists across reinstall explains why none of that helped.

I’ll keep an eye on the separate startup delay as well. Thanks again!

8

Hey, glad that helped. Yeah, Index Repositories for Instant Grep is saved in settings, not in the app itself, so reinstalling and using an empty folder didn’t change anything since the state carried over. Makes sense that nothing was triggering before.

About the startup delay when loading the agent runtime, that’s a separate thing we’re tracking too. It shouldn’t block sends, but if you notice the delay growing or starting to get in the way, post here with the approximate time of your last launch and we’ll check the logs.

If the Agent starts timing out again, let us know in this thread.

10

Hey, quick update on this thread: the fix for that timeout issue that happened when Index Repositories for Instant Grep was turned off will ship in Cursor 3.21.18.

After you update to that version, Agent will keep working even if that setting is turned off again, so you won’t need to rely on the workaround anymore.

The startup delay when loading the agent runtime is a separate issue and we’re still tracking it. If you notice the delay getting worse or starting to get in the way, reply here with the approximate time of the last launch and we’ll check the logs.

Thanks again for the detailed report with logs and the Request ID.

11

Hi Dean,

Thanks for the update! I’ll keep an eye out for 3.21.18.

I did notice the startup delay again on my most recent Cursor launch. I got the spinning beach ball while the Agent runtime was loading, although I wasn’t timing it, so I can’t give you an accurate duration. It did eventually finish loading and everything has been working normally since.

I’ll time the next launch and let you know if it happens again.

Thanks again for continuing to look into it!