Post-execution delay where agent remains in “running command” state after output is already returned

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After running a command from the agent, the command output appears normally but Cursor continues showing the command as “running” for an additional ~10–20 seconds. During this time the agent is stuck waiting for the command to finish even though the output is already visible. If I manually press Cancel after the output appears, the delay disappears and the agent proceeds immediately. This happens with all commands and models and makes short operations take much longer than they should.

Steps to Reproduce

Open Cursor on native Windows.

Run any command through the agent.

Wait for the command output to appear in the UI.

Observe that Cursor still shows the command as running for ~10–20 seconds.

Optionally press Cancel once output is already visible.

Notice the agent proceeds instantly with no delay once cancelled.

Reproduces consistently across multiple machines and networks.

Expected Behavior

Once the command output is returned and displayed, the agent should immediately exit the running state and continue execution without additional waiting time.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 2.4.36 (user setup)
VSCode Version: 1.105.1
Commit: f9919bf991f247689f9ead605b5c5a3239a2a790
Date: 2026-02-12T21:00:33.976Z
Build Type: Stable
Release Track: Early Access
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Model name: occurs with all models tested

For AI issues: add Request ID with privacy disabled

890e4df8-6afd-4604-ba64-a11bcbdd0ce9

Additional Information

Reproduced on 3 different Windows laptops

Tested across multiple networks

No VPN or proxy in use

Privacy mode disabled during testing

Does not happen in Codex or Claude Code

Only happens after command output is already returned

Pressing Cancel immediately clears the delay, which suggests the command lifecycle state is not updating correctly on Windows

Does this stop you from using Cursor

No - Cursor works, but with this issue

1 Like

Hey, thanks for the detailed report. This is a known issue with detecting when a terminal command has finished, and a few users on Windows have seen something similar.

Can you try enabling Legacy Terminal as a workaround?

  • Settings > Cursor Settings > Agents > Legacy Terminal, turn it on
  • Restart Cursor
  • Check if the delay still happens

Also, a couple of questions:

  • Which shell are you using, cmd, PowerShell, or Git Bash?
  • Does the behavior change across different shells?

The team is aware of this category of terminal lifecycle issues on Windows. Let me know if Legacy Terminal helps.

Thanks for the quick response, turnin on legacy terminal actually made Cursor crash completely when i click “Run” on the command prompt, im using powershell. Im not aware on how to change the type of terminal cursor has access to.

EDIT: It crashed the first time only, after restarting Cursor a second time it fixed it yeah, thanks!

1 Like

I’m encountering a similar issue where the model actually started a sleep command after the previously run commands had returned. When I switched to the legacy terminal, the model (Sonnet 4.6) responded that “PowerShell script execution was disabled,” although I’m unsure if that was actually the case or just the AI not using tools correctly.

For now I’m turning off the Legacy Terminal. I’ll keep an eye on this situation and report any other patterns.

Version: 2.5.17 (system setup)
VSCode Version: 1.105.1
Commit: 7b98dcb824ea96c9c62362a5e80dbf0d1aae4770
Date: 2026-02-17T05:58:33.110Z
Build Type: Stable
Release Track: Default
Electron: 39.3.0
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100

Hey @Leland_Hepworth, the model running sleep after a finished command looks like the same bug with detecting when a command has completed. The model “thinks” the command is still running and tries to wait.

A couple of questions to help narrow this down:

  • What execution policy are you using in PowerShell? You can check with Get-ExecutionPolicy in a normal terminal.
  • Was the message “PowerShell script execution was disabled” something the model wrote in chat, or an actual error in the terminal?
  • Can you share the session Request ID where this happened?

We’re aware of this category of Windows terminal issues. As a possible workaround for now, try switching Cursor’s default integrated terminal profile to cmd or Git Bash instead of PowerShell (Terminal > Integrated > Default Profile: Windows) and see if it still reproduces.

Let me know how it goes.

@deanrie

I ran the command once with Legacy Terminal Tool disabled and another time with it enabled, and both times the output was “Restricted.” I ran the command manually in the terminal. If you need me to get an agent to do it and check the output, let me know.

That message was written by the model, but I went back to the chat, and here is the output when it tried to run the PowerShell command:

npm : File C:\Program Files\nodejs\npm.ps1 cannot be loaded because running scripts is disabled on this system. For 
more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:65
+ ... <the_command_was_here> ...
+                                                               ~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

Here’s the request ID, but privacy cannot be disabled on my team account:

002a3257-bbe3-4f49-ac8c-5d64be685433

For visibility to other users, I want to link to this post:

So not only are the erroneous sleep command calls wasting execution time, they are also increasing the number of tool calls and interactions with the LLM, which has an impact on the amount of Cache read used and therefore the cost of that chat.

@Leland_Hepworth, the Restricted execution policy explains the error. PowerShell is blocking .ps1 scripts, including the npm wrapper at C:\Program Files\nodejs\npm.ps1. That makes the agent misread the state and run extra sleep and retry loops.

Two ways to fix it:

  1. Switch the default terminal to cmd. This avoids the PowerShell restriction. Go to Terminal > Integrated > Default Profile: Windows and set it to Command Prompt. This should remove both the execution error and the fake sleep commands.

  2. Change the execution policy. If you need PowerShell, run Set-ExecutionPolicy RemoteSigned -Scope CurrentUser in an elevated PowerShell. If this is a team machine, you might need admin approval.

About the cache read token impact, good point. The extra tool calls from failed retries and sleep loops do add up. Switching to cmd should reduce that since the root cause goes away.

Let me know if using cmd fixes it for you.

I’m not seeing that in the menu:

Also couldn’t find something similar in the Cursor Settings or VS Code settings.

There is the following file that might be relevant:

C:\Users\leland.hepworth\AppData\Roaming\Cursor\User\settings.json

{
    "window.commandCenter": true,
    "git.autofetch": true,
    "cursor.composer.usageSummaryDisplay": "always",
    "terminal.integrated.defaultProfile.windows": "Command Prompt",
    "workbench.editor.splitOnDragAndDrop": false,
    "terminal.integrated.automationProfile.windows": {
        
    }
}

But, it looks like the default integrated terminal is already being set to Command Prompt there.

Is there anything else to try in the settings?

I’ll look out for if the chat tries to perform a sleep command again.

Hey, based on your settings.json, "terminal.integrated.defaultProfile.windows": "Command Prompt" is already set, so that looks correct and cmd should already be the default terminal.

To double-check it’s really working, open a new terminal in Cursor and see if the terminal header/title says cmd, not powershell. If it opens as cmd, the setting is applied.

Main question: after cmd became the default, is the agent still running extra sleep commands? If not, then the issue is fixed. If yes, send the Request ID for the session where you reproduced it and I’ll pass it along.

I didn’t manually edit that setting when you asked, so it should have always been using cmd, unless something automatically changed that setting at some point. I have noticed that the chats frequently try to use commands that work in powershell but not in cmd. After that chat tries that and gets the error message, it usually doesn’t make that mistake again, but new chats tend to have the same issue. But that’s still an extra erroneous tool call, with the associated real time and cache read token waste.

The chat hasn’t tried to perform a sleep command for me recently, but I’m not doing quite the same things that I was doing when I first had that issue. Although here’s a link to another person reporting a similar issue:

@Leland_Hepworth, glad the sleep issue is gone.

About the agent using PowerShell commands when cmd is the default terminal, that’s a known bug. The agent doesn’t always correctly detect which shell is active, so it may send PowerShell commands.

As a temporary workaround, you can add something like this to your project-level .cursor/rules:

When running terminal commands, always use cmd.exe syntax, not PowerShell. The default shell is Command Prompt.

This won’t guarantee a 100% fix, but it should reduce the number of wrong PowerShell calls.

Thanks for the link to the sleep thread, it’s helpful for tracking.