{"error":"ERROR_USER_ABORTED_REQUEST","details":{"title":"User aborted request.","detail":"Tool call ended before result was received","isRetryable":false,"additionalInfo":{},"buttons":[],"planChoices":[]},"isExpected":true}
On the contrary, I prohibit Agent from running background commands, as they don’t block its operation and Agent cannot access the results of their execution. I would even like a separate option to disable this functionality.
I use local CI in my projects (the concept can be seen in the abandoned Agent Enforcer). Currently, I’m working with the Rust language, and even with all sorts of compilation optimizations, the CI sometimes takes more than ten minutes.
The question is also that the Agent must wait for this terminal to be executed. If the terminal process takes 20 minutes, will Agent wait for it?
By the way, the OpenAI Codex has an interesting implementation: you can simply warn the agent to launch the terminal with a 20-minute timeout, and then it will know that the terminal can run for a long time and that if there was a timeout, the problem was the timeout.
Would the ideal scenario be that your agent is completely blocked for those 20 minutes, or that you can continue working? I’m thinking about something like a subagent who goes and runs the long-running terminal and reports back.
We do have a fix on the way (might already be merged) to distinguish between terminal timeouts and “user abort”, which you ran into.
We prohibit the agent from sending commands in the background because we basically just want to wait. In background mode it burns tokens unnecessarily because agent randomly checks whether the command has finished and can sometimes decide, for no reason, to kill the process. Here, the Cursor team should just KISS: we want to run commands in the foreground and simply wait for the result before iterating.
I use 4 Cursor IDE instances in parallel on 4 different repositories, and we have an isolation system that prevents port conflicts, etc.
We run test/build commands on huge applications, and those commands can take well over 10 minutes when the agent is iterating on complex issues and needs to run many tests to ensure nothing was broken in the process. For example, we don’t want the agent to “early-exit” tests when it sees a failure, because tests are co-located and other failures with a full test report can help it fully understand the failure context.
This is really annoying, and without a workaround our agent loop is currently completely broken. We can’t use Cursor correctly. Is there a way to downgrade? When was this change introduced? Does the legacy terminal have the same issue, and can we use it as a workaround?
Please, Cursor team, fix this ASAP.
Right now the agent loop is broken, and we do not want to use background processes because they generate noise in the chat and burn tokens for no reason.
Arbitrary wait, when the process finally resolve, we wait for nothing
The agent can mess up depending of the output
Please Cursor just allow no timeout on foreground commands it worked fine… or implement a hook to notify the agent when the background command is finished
I also have a separate additional User Rule defined in Cursor: Не запускай терминал в background - ты не сможешь получить к нему доступ после запуска. = Don't run the terminal in the background - you won't be able to access it after it starts..
At least in the last many weeks, the only background launch has been Sonnet 4.5, and it even seemed justified for that case (though not necessarily).
They are executed, but after completing the work, you need to write something like “continue” in the agent chat, since Cursor interrupts the execution.
I have built-in sound notifications into CI and frequently monitor the Agent Chat, so this is inconvenient, but not critical.
**CRITICAL SUPER IMPORTANT, TRES IMPORTANT A UTILISER: Monitoring background commands `while ! tail -n 2 {backgroundCommandOutputFilePath} | grep -q “^Exited with code:”; do sleep 1; done` In case the foreground command timeout just re use the same command to wait for the exit**
Why it’s smart to combine this with a background run:
As a human, you can view the full command log if needed.
The foreground while command exits as soon as the background command exits no “sleep” tricks involved and useless latency
The agent then uses tail to read the background terminal file, seeing only the summary text.
This avoids issues with long foreground processes where the entire command output is sent to the chat, potentially saving a large number of tokens.
What happened?