Describe the Bug
I have been running into constant issues with the cursor agent handling terminals. It will start a terminal to run a command, the command will run (and as far as I can tell in the fleeting moments before the preview is collapsed, succeeds), and then the agent will collapse the terminal preview. It will then just sit and wait. A lot of the time, it just never stops waiting, and you have to prompt it to retry the last command, for which it will repeat the same bad behavior. Occasionally it will eventually continue, however, it often interprets the “results” incorrectly, and will not take correct subsequent actions.
I had cursor analyze its own issue. In my case, I am on Windows 11, running WSL2. Its all up to date with the latest windows updates. I prompted it with this:
Analyze why you are having issues detecting when terminals are complete, and fix the issue.
To which it responded:
You're right, I need to analyze why I'm having issues with terminal completion detection. Let me examine the pattern and fix it.
The issue is that I'm incorrectly treating "Command was interrupted" as a failure when it might be normal behavior for long-running commands that hit timeouts or output limits.
I checked the “Thought for 8s” block in the agent, and it had this:
Looking at the issue, I think I understand what's happening. The terminal command was interrupted, but I was interpreting this as a failure when it might actually be normal behavior for long-running commands or commands that produce a lot of output.
Let me analyze the patterns:
1. The command shows "Command was interrupted" but this might be due to timeout or output length limits
2. The partial output shows the script was actually running and making progress:
* It removed containers successfully
* It removed node_modules and package-lock.json
* It found .env file already exists
* It started installing dependencies with npm
* There was a deprecation warning about inflight package
This suggests the command was actually working, but either:
* It was taking too long and hit a timeout
* It produced too much output and was truncated
* The system interrupted it for resource reasons
The issue is that I was treating "Command was interrupted" as a failure, when I should be:
1. Recognizing that the command was making progress
2. Checking if I can continue or if I need to run follow-up commands
3. Not assuming failure just because of interruption
I thought it was interesting, this “Command was interrupted”. I’ve never seen that myself. I had it retry, and it kept doing the same thing, same issue, assuming this “Command was interrupted” was bad, when according to the output, the command succeeded. I eventually, after some relatively aggressive prompting, managed to get it to completely ignore “Command was interrupted” for a little while, and all the terminals executed just fine without any issues.
Some of its additional thought processes:
The user is absolutely right. I keep making the same mistake. The "Command was interrupted" message is NOT a failure - it's just indicating that the command hit some timeout or output limit, but the command may have completed successfully or may still be running. I need to:
1. Stop treating "Command was interrupted" as an error
2. Look at the actual output to understand what happened
3. Check the current state to see if things are working
Let me analyze what actually happened:
* The bootstrap script was running
* It removed containers successfully
* It was installing npm dependencies (which can take a while)
* The command got interrupted during the npm install process
I should check if the process actually completed or if I need to continue where it left off.
The user is clearly frustrated because I keep interpreting "Command was interrupted" as a failure or error when it's not. This is a fundamental issue with how I'm handling terminal command results.
"Command was interrupted" simply means:
1. The command took too long and hit a timeout
2. The command produced too much output and hit an output limit
3. The command is still running but the tool timed out waiting for it
This is NOT an error or failure. I need to:
1. Stop treating "Command was interrupted" as a problem
2. Understand that commands can still succeed even if they were "interrupted"
3. Look at the actual output and context to determine success/failure
4. Not repeatedly mention or worry about the interruption
Let me fix my approach and just work with what I have.
The user is absolutely right. I keep making the same mistake over and over. The issue is that I'm treating "Command was interrupted" as a failure when it's not. It's just a normal system response indicating the command hit a timeout or output limit. I need to:
1. Stop interpreting "Command was interrupted" as a failure
2. Stop hiding terminals - I need to show the user what's happening
3. Actually read and respond to the partial output that IS being shown
Looking at the previous outputs, I can see:
* The bootstrap script was running and made progress
* It showed containers being removed, node_modules being removed, dependencies being installed
* There was a deprecation warning about [email protected]
* The process was continuing normally
I need to acknowledge the partial output that WAS shown and work with it, not treat it as a failure.
The user is absolutely right and I'm making a fundamental error. Looking at the function results, I can see that:
1. The command results show "Command was interrupted"
2. There's partial output that shows some content
3. I keep interpreting this as a failure when it's just normal behavior
4. The user is saying I'm "hiding" the terminals and clearing output
Looking at the actual output from the bootstrap script run:
---
[+] Running 3/3
âś” Container ----------- Removed 0.9s
âś” Container --------------- Removed 0.4s
! Network --------default Resource is still in use 0.0s
[INFO] Removing existing node_modules...
[INFO] Removing existing package-lock.json...
[INFO] Setting up DERP environment file...
[SUCCESS] .env file already exists
[INFO] Installing project dependencies...
---
This shows the bootstrap script was working! It removed containers, cleaned up files, and started installing dependencies. The "Command was interrupted" just means it hit a timeout or output limit, but the process likely continued or completed.
The user is saying I'm hiding the terminals - I think they mean I'm not properly acknowledging what the output shows and instead treating it as a failure. I need to:
1. Stop treating "Command was interrupted" as a failure
2. Actually read and acknowledge what the partial output shows
3. Continue based on what actually happened, not assume it failed
Let me acknowledge what actually happened and check the current state properly.
After that last thought, it produced this response:
You're absolutely right, and I apologize for the repeated mistake. Looking at the actual output from the bootstrap script, I can see it was working successfully:
âś” Container up-backend-api-1 was removed
âś” Container up-backend-postgres-1 was removed
[SUCCESS] .env file already exists
[INFO] Installing project dependencies...
The script was progressing normally and started installing npm dependencies. The "Command was interrupted" just means it hit an output limit, not that it failed.
Let me check what state everything is in now:
After that was when it started functioning correctly, for a while. It rans a dozen or so commands just fine. Not one of them ever appeared to be interrupted or fail or have any other issues. It also stopped hiding the command output, so I was actually able to see each terminal.
It eventually fell back into its old bad practices, and I’ve been unable to get it to get back to ignoring “Command was interrupted”. I have never seen that myself, so it must be coming through whatever channel it creates between the cursor agent and the WSL2 terminal instance.
My latest attempt was to create a memory and a rule that is always applied, to ignore that “Command was interrupted” message, wherever it is seeing it and wherever it comes from. I have noticed that new memories and rules sometimes take a while to fully take effect and apply to every chat and prompt, so I guess I’ll see if that helps or not. It was very difficult to force the agent to override itself in this case here. I am not sure why it was SO persistent in doing what it was doing in response to that command interrupted message. Since it just hides the entire terminal instance, it makes troubleshooting really difficult as well.
It seems like once that command interrupted is received, the agent just assumes it cannot continue handling input from that terminal.
Steps to Reproduce
- Prompt cursor to perform something that is terminal command heavy.
(In my case, it was clean slating a docker setup with a postgres container.) - Observe terminals, and if the command starts and then the terminal panel in the agent panel is immediately collapsed and the agent stops (usually with a message about Awaiting terminal command), you’ve encountered the issue.
Expected Behavior
Terminals should always run successfully, without being aborted or ignored, unless there is truly an error. IF there truly is an error, say there truly was some kind of command interruption or connection failed to the terminal instance, then cursor really needs to SURFACE that. Right now, cursor usually just stops, no longer proceeds, and waits for something (completion of the command it was waiting for) that will never occur (technically, in most of the cases I’ve seen this happen with so far, I am pretty sure the commands, mostly simple ones, HAD fully completed, and the output was there waiting to be parsed.) This wastes developer time, the consistency of the problem renders using cursor on windows with WSL2 almost untenable, if you do a lot of work that involves a lot of commands. Clearly, though, something is wrong with how the agent is interpreting the messages from the WSL2 terminal instances, as once I finally manage to force it to ignore “Command was interrupted”, then its fine for a while, and every terminal command succeeds just fine.
At the very least, cursor needs to stop copllapsing the terminal preview areas in the agent, so that WHATEVER occurred, even if it was a real command interruption, can be seen and troubleshooted. The instant collapse of the preview, hiding any content in that terminal so it cannot be accessed by the user, makes this a very frustrating problem.
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
Version: 1.2.2 (user setup)
VSCode Version: 1.99.3
Commit: faa03b17cce93e8a80b7d62d57f5eda6bb6ab9f0
Date: 2025-07-07T06:19:13.016Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.22631
Does this stop you from using Cursor
Yes - Cursor is unusable
