Timeout setting on terminal/shell Agent tool

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

There is unclear documentation and recent changes regarding how terminal commands run by the agent time out.

Some commands run by the agent can take up to 20 minutes or even 1 hour. It seems that despite adding CRITICAL timeout instructions, some commands still time out way earlier.

We know that our repository does not have timeout issues or dead commands, so it is fine for us to wait, we don’t mind.

Is there any workaround to disable the timeout on the terminal/shell tool?

This is painful because, in the case of long-running test commands, the agent gets stuck.

Is there any quick workaround, or is a feature planned that would allow us to customize this parameter?

Steps to Reproduce

Run a command for more than 5-10min via agent shell

Expected Behavior

Control timeout with a Cursor Setting for terminal/shell tool

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.3.35
VSCode Version: 1.105.1
Commit: cf8353edc265f5e46b798bfb276861d0bf3bf120
Date: 2026-01-13T07:39:18.564Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.2.0

Does this stop you from using Cursor

Yes - Cursor is unusable

2 Likes

Hey, thanks for the report. This is an issue the team is working on improving.

Related thread: Agent was interrupted after working in the console for a long time. Colin already discussed it there and mentioned a fix to better tell timeouts apart from a “user abort”.

Right now, there isn’t a workaround to fully disable the timeout. Rules or instructions can’t override system limits.

The team is looking at a few approaches:

  • Better timeout detection
  • A subagent option for long running commands
  • A configurable timeout as a feature

Could you add your use case (CI or tests that can run for up to an hour) to that thread? It helps the team understand the priority.

1 Like

My repository rules specify running local CI with a 25-minute timeout, and the Agent (and OpenAI Codex) seems to be following suit. However, the longest I’ve seen with this builder is 23 minutes, and usually it’s either 2-3 or 9-10 minutes, depending on the changes and the launch method.

The problem is that if the launch takes longer than ~ten minutes, the system assumes the connection with the Agent has been lost and aborts the request.

1 Like

Same issue here. Running a long test, where there is no benefit to the chat continuing while it runs… there is nothing to do until the test results are available.

I don’t understand why someone thought it was a good idea to add in arbitrary limits without the user option to control them. Better customer empathy, please!

1 Like

@deanrie you’re mistaken: your Agent terminal has a parameter called block_until_ms that the Agent can configure at startup.


Actually, I just discovered that G3F knows how to use it - apparently it just forgets about it during real operation :thinking:

1 Like

@Artemonim @deanrie

I can confirm that I switched my rules to use Block Until ms. Currently, it seems to work and forces the command to finish even if the process takes 15 minutes. I’m just hoping the Cursor team doesn’t break this feature again, it’s important.

Super important @Artemonim It also seems that tool usage is customized per model. Composer, for example, can’t use the Block Until ms option. I don’t know why. Codex and Claude seem to work properly.

I also had some issues steering Composer correctly with certain tools, so I stopped using it. Now I only use it for search, and honestly it’s too expensive and not very smart compared to Codex 5.2 Medium.

1 Like

I used to use Grok Code Fast if I needed information from the repository. I have now switched to Gemini 3 Flash. Although the default /explorer-subagent is Composer, and you can only prevent it from being used through rules. But I’ve accepted it :eyes: