Agent execution timed out - regression on Linux .deb release

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On the Linux .deb release I am getting “Agent execution timed out” errors on all chat/agent requests. I have tried the --disable-extensions and it did not help and I have tried disabling HTTP2 and it did not help.

Downgrading to cursor_3.7.27_amd64.deb and everything works fine again.

Please let me know what logs etc I can provide to try get this fixed.

Thanks

Steps to Reproduce

Install latest linux.deb
Send a message to an agent or try to create a new chat
timeout occurs

Expected Behavior

It should behave as normal

Operating System

Linux

Version Information

Cursor IDE 3.9.16

Additional Information

Downgrading to Cursor 3.7.27 deb file and everything works fine

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report, and especially for finding a working workaround.

It looks like the built-in agent execution provider isn’t coming up fast enough on 3.9.16 in your environment, so requests fail before any network call happens. That also explains why --disable-extensions (it only disables third-party extensions) and disabling HTTP/2 didn’t change anything. This seems specific to your Linux setup, not a general regression.

For now, you can safely stay on 3.7.27. As a temporary fix, that’s totally fine.

To dig deeper, could you share:

  1. Logs from the broken 3.9.16: Command Palette Ctrl+Shift+P → Developer: Open Logs Folder. From there we need main.log and the Extension Host log exthost.log.
  2. Your distro and version like Ubuntu 24.04, Fedora 41, etc.
  3. Your glibc version: output of ldd --version.
  4. Whether you have an active sandbox like AppArmor or Landlock, or any antivirus or security agent.

With that, it’ll be clearer what’s breaking between 3.7.x and 3.9.x on your machine.

6

I’ve attached the logs.
Distro is PikaOS (it is rolling release with a Debian base, I am a maintainer if you need any more specific info)
Glibc is 2.42
No sandbox, no apparmor, no antivirus or security

exthost1.log (6.1 KB)

main.log (1.2 KB)

7

Second exthost log attached

exthost2.log (5.7 KB)

as there were two “window” folders with these logs

8

Thanks, I got the logs, and the extra environment details too.

Here’s what the logs show: in one of the two windows, the built-in cursor-agent-exec extension host activates normally (in about 300 ms). In the other window, activation stalls for about 11 seconds and the provider never registers. Because of that, the request hits a timeout before any network call is even made. That also explains why --disable-extensions and disabling HTTP/2 didn’t change anything. This stall doesn’t happen on 3.7.27. It looks like something specific to very new glibc 2.42 or kernel 7.1.2 on PikaOS, not a general regression in 3.9.16.

To narrow it down, a couple questions:

  1. Does it reproduce if you open one window on a clean or empty workspace? The logs had two windows, and only the second one failed, so I’m wondering if it’s related to having multiple windows.
  2. Is it consistent on every launch of 3.9.16, or does it sometimes start fine?

For now you can stay on 3.7.27 as a temporary workaround. Since you maintain PikaOS, if you can share what native components or glibc-related dependencies changed recently in the distro, that would really help pin down the root cause. Once you’ve checked the points above, reply here.

9

Nothing distro side has changed recently - I just tested on a fresh VM with a fully updated distro and it works so that implies it is something in my settings/cache/.cursor folder? or a conflicting package not in a bare fresh install?

  1. I don’t think I am opening multiple windows? At least not on purpose - what is classed as a window in this context? Just opening cursor once from terminal or launcher on the new agent tab and typing hi and it still times out.
  2. Every launch yes

What are all the caches, config etc folders for cursor on linux? - I can try clearing them out. It couldn’t also be a problem that one of my workspaces is a massive nested monorepo?

10

Great that it worked on a clean VM, that narrows things down a lot. If a fresh install works, then it’s not really about glibc or the distro. It’s either your user config and cache, or a specific workspace. Let’s check both.

About “window”: each Cursor window is one editor instance with one folder or workspace open. When you start it from the terminal or launcher, it usually opens one window, but Cursor restores the previous session, so the logs showed two window folders. If it crashes on every launch even with one window and a simple “hi”, that points to local state, not the number of windows.

Config and cache paths on Linux:

  • ~/.config/Cursor/ main app data:
    • Cache, Code Cache, GPUCache
    • User/globalStorage global state
    • User/workspaceStorage/<hash> state for each workspace
    • logs
  • ~/.cursor/ extensions and CLI

How to test with a clean config, fastest way to reproduce the fresh VM effect:

mv ~/.config/Cursor ~/.config/Cursor.bak
mv ~/.cursor ~/.cursor.bak

Then start 3.9.16. If it works, the issue is definitely in the old config or cache. Note this will log you out and reset local UI state and chat history, so rename to .bak instead of deleting so you can restore it.

About the monorepo, yeah, it’s a real suspect. A big nested monorepo can slow down extension host activation due to file scanning and watching, and the provider might not register before the timeout. Test it like this: in 3.9.16 open a small or empty folder, not the monorepo. If it works instantly there but hangs on the monorepo, the cause is that workspace. You can then delete only its entry in ~/.config/Cursor/User/workspaceStorage/. You can find the right <hash> by running grep for your project path in the workspace.json inside those folders.

Let me know what fixed it, the config reset or switching the workspace. That’ll make it clear what to dig into next.

Also for the future, if the problem comes back after resetting config, check folder permissions. On Linux, ~/.config/Cursor sometimes ends up owned by root after running sudo, and then Cursor can’t write its state. Fix:

sudo chown -R $USER:$USER ~/.config/Cursor
11

Looks like ~/.config/Cursor was the culprit - renaming then regenerating that even with the same codebases loaded seems to work fine!

12

Awesome, glad that helped. So it was a local state issue, not the distro or glibc. That takes suspicion off 3.9.16 itself.

If you want to dig into what exactly from the old ~/.config/Cursor.bak was breaking the extension host, and also restore your chat history, you can move folders back into the fresh ~/.config/Cursor in parts and test after each step:

  • First, the caches: Cache, Code Cache, GPUCache. It’s safest to just delete these since they’ll be regenerated.
  • Next, User/globalStorage (global state) and then User/workspaceStorage/<hash> one by one. If the timeout comes back after a specific workspace hash, for example from that monorepo, then the cause is in that workspace state and you only need to delete that one entry.

Totally optional though. If everything works now, you can leave it alone. If the issue comes back, post here.