Tool call timed out after 200000ms and Terminal Stuck

Bug Reports
1

Hey guys,
You’re all more intelligent than I am, so maybe you can help me solve this. Hope to hear from you guys soon.

There is actually 2 issues that are annoying me.

First is the constant stuck at terminal calls and actions. Very offten it stucks and I need to ^C but then it tries to do again and i loss all the tool call tokens.

Then the more important one is this Tool call timed out after 200000ms.

:white_check_mark: Check the forum to ensure the issue hasn’t already been reported
I didn’t find anything specific about solving this problem.

:lady_beetle: Provide a clear description of the bug
I’m encountering an issue when Composer generates code related to linting. Whenever the agent indicates there’s one linter error, it gets stuck, stops working, or displays a “Tool call timed out after 200,000ms” message. This happens repeatedly and randomly. It then tries again, but the timeout occurs again. Sending “continue” doesn’t seem to resolve it either. As a result, I have to start a new chat and redo everything. Sometimes, it also gets stuck on “Generating” and doesn’t proceed. In this particular case, the chat wasn’t even long—you can see that the “create a new chat” message isn’t shown.

  • Starting a new chat by copying all the markdown from the messages in the old chat doesn’t work well either. The agent loses context and starts redoing things that were already completed, turning it into a mess. Instead, I go back to the first prompt from the original chat and start over from scratch. Can you imagine the time I’m losing because of this?
  • It doesn’t always happen, but it occurs frequently enough to annoy me and ruin my productivity.

:counterclockwise_arrows_button: Explain how to reproduce the bug (if known)

  • I think the way to reproduce it is by asking the agent to handle multiple tasks at once.
  • Could it be due to a codebase that’s too large? (It’s a WordPress plugin, but there aren’t actually that many files.)
  • Could it be related to my context or rules?
  • I’ve ruled out the server, workstation, or ISP because it works most of the time, but when it does happen, it’s pretty annoying.

:camera: Attach screenshots or recordings (e.g., .jpg, .png, .mp4)

image
image758×826 30.6 KB

image
image721×947 35.4 KB

image
image595×568 19.9 KB

:laptop: Tell us your operating system and Cursor version (e.g., Windows, 0.x.x)

  • Version: 0.48.2 (user setup)
  • VSCode Version: 1.96.2
  • Commit: 7d6318dfcfbf7c12a87e33c06978f23167a6de30
  • Date: 2025-03-26T02:54:05.125Z
  • Electron: 34.3.4
  • Chromium: 132.0.6834.210
  • Node.js: 20.18.3
  • V8: 13.2.152.41-electron.0
  • OS: Windows_NT x64 10.0.26200

:prohibited: Tell us if the issue prevents you from using Cursor
Not really, but it’s annoying because I have to redo a lot of work. It also generates numerous tool calls, and it’ll go make me broke soon if I have to repeat things 2–3 times. I dont want to use an alternative.

Hope you can help me
Thanks

2

And again

image
image760×923 26.9 KB

3

Hi, have you tried a new chat? or restarting Cursor?

I personally dont have that issue anymore on 0.48.2. but i had it in the past on other versions.

4

Thanks for the quick response!

Yes, I’ve tried all of that: restarting, opening a workspace, and not opening a workspace, but it doesn’t solve the issue.

Interestingly, it happens when I use Cursor on Windows. Now that I’m running it on macOS, isn’t happening. I’ll keep monitoring it, and if it occurs again, I’ll post here.

Since this is a problem with a historical occurrence, is there a fix in the latest versions of Cursor? I ask because this could help clarify whether I should look for solutions locally or within the project itself.

By the way, I’ve encountered another issue where the chat’s terminal sometimes asks for permission to run a command, while other times it doesn’t—even when the commands are listed in the allowed field in YOLO. Often, it gets stuck, and I need to cancel it. I’ve noticed this tends to happen when the chat or context becomes too long. The problem is that we sometimes really need those long chats, and even with the option for large-context chats enabled, it still occurs.

I know it isn’t the topic subject, but I took advantage of the interaction. Sorry :blush:

5

There were various cases where Cursor servers were overloaded historically or had other issues due to an update (in last 24h).

So likely to have been an effect from that.

Yes you are right on longer chats. For me also when context becomes long from the thread it gets easier to see hallucinations from AI or mistakes in Yolo!

Thats why usually i keep chat focused on either Planning only, or Implementation (Act) only for specific features.

Also when i go back and forth with corrections it can confuse AI (tried several models) as the context is polluted with contradicting code inside.

I use a task.md file that AI writes plan into and updates it. That way i can tell it to focus on specific steps even if i start new chat.

20 000s or 200 000s is like a full timeout, can also be network related.
(hard to tell sometimes but i saw users having issue with their routers which when restarted worked for example, or firewall, antivirus on windows which caused interruptions etc..)

Also here is a related case.

6

I see it.

Yes, a couple of days ago, I started creating very specific and detailed plans for a project, breaking it down into small modules. I use it as a guide with the “Ask” feature.

This has solved most of the issues with long chats, but sometimes when it gets stuck and I need to start a new chat, I try to show the agent what was done earlier by using the logs generated by SpecStory, which I found on the forum. It’s quite interesting for this kind of workflow. However, it isn’t perfect, and sometimes I still need to restart a module from scratch.

What context size as rules do you guys recommend? Tried to simplify and reduce it but seems to be worse than the larger rules attatched at the start of a new chat. Could be it one of the cause or the issues we are talking?

image
image760×802 32.4 KB

image
image768×996 41.2 KB

This happens all the time too.

My worries are that it is using tools and we have a limited quantity.

7

Yes i saw also issues specially hallucinations with large rules. so i simplified my rules. removed anything that is not relevant to project.

Originally i had for the programming language and framework quite detalied best practices and rules. After 3.7 was announced and Cursor had to adjust context and API/tool usage i saw an issue. Now mostly using 3.5 as its more stable and not too eager to make unrelated changes.

Im not sure if context size directly on a fresh chat is causing such issues. If you can drop in request IDs cursor team would be able to see perhaps on their side if they saw requests coming in for that tool usage.

I also use specstory for export just in case history gets wiped or has to be wiped due to slowing down Cursor for some users when too many prompts.

There is no hard context size number as a rule from what i see.
Also I cant set a context size directly apart from having the option to use Large Context which makes sense mostly for larger files at begin of chat.

You can check in Developer Tools if requests to cursor are being made for those tool requests. or not.

8

Tool calls dont cost extra (up to 25 tools used per prompt in regular Agent usage after that its a new prompt when you click continue on very very long processes).

If the request times out i think it wouldnt count, but im not 100% sure.

Only in MAX mode do tool calls directly cost per call.

9

This is a known issue I’ve been experiencing on Cursor for Windows for months. I even started a thread on it a month ago and support replied once and then vanished. Exact same issue as you. Once the linter happens the chat is toast. Won’t respond further no matter what.