Shell commands in Agent mode are not returning output

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Shell commands in Agent mode are not returning output

Steps to Reproduce

I ask this the “Agent” window that I start from PowerShell or CMD on Windows 11

“what is the current date and time?”

It tries to run various commands in Powerhell, bash, Pyhthon. and none are able to return an output
$ date exit 0 • 0ms

$ powershell -Command “Get-Date” exit 0 • 0ms

$ echo %DATE% %TIME% exit 0 • 0ms

$ python -c “from datetime import datetime; print(datetime.now().strftime(‘%A, %B %d, %Y %I:%M:%S %p’))” exit 0 • 0ms

$ node -e “console.log(new Date().toString())” exit 0 • 0ms

$ cmd //c “echo %DATE% %TIME%” exit 0 • 0ms

The shell commands aren’t returning visible output. Based on the system information provided, today’s date is
Sunday, March 22, 2026. Unfortunately I’m unable to determine the exact current time, as the shell isn’t producing
output on your system.

Expected Behavior

Be able to read the output and tell me the date and time

Operating System

Windows 10/11

Version Information

Cursor Agent v2026.03.20-44cb435

For AI issues: which model did you use?

Opus 4.6 1M

Additional Information

I have same version of Cursor as my coworkers, and they don’t have the issue
The one difference may be that I have WSL installed and they don’t
I don’t expect Cursor Agent to use WSL, It is configured to use PowerShell
Also the command return immediately with code 0 (success) but no output.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

Hey, thanks for the report. The exit 0 • 0ms with empty output usually means the shell process isn’t actually executing. A few things to check:

  1. Check your working directory

Make sure you’re running agent from the actual project directory - not through a symlink or a path that was recently moved or renamed. Try cd-ing into the project root explicitly and running agent from there. A stale or invalid working directory is the most common cause of this exact symptom.

  1. Check your PATH for WSL bash

WSL can interfere with how Cursor CLI resolves the shell on Windows. Run this in PowerShell and share the output:

where.exe bash
where.exe sh
$env:COMSPEC

If bash.exe from WSL appears in your PATH, that’s likely what’s confusing shell detection.

  1. Check MCP servers

If you have any configured in ~/.cursor/mcp.json or .cursor/mcp.json, try temporarily disabling them:

Rename-Item ~/.cursor/mcp.json ~/.cursor/mcp.json.bak

Then relaunch the agent. A stuck MCP server can silently block command execution.

Start with step 1 - it resolves this symptom more often than the WSL angle. Let me know what you find.

5

Thanks for the quick reply
The folder is not stale, I created new folders and running “agent” from there I get same behavior.

Here is the output of these commands

PS C:\dev\ai\cursor> where.exe bash
C:\Windows\System32\bash.exe
C:\Users\\AppData\Local\Microsoft\WindowsApps\bash.exe
PS C:\dev\ai\cursor> where.exe sh
INFO: Could not find files for the given pattern(s).
PS C:\dev\ai\cursor> $env:COMSPEC
C:\WINDOWS\system32\cmd.exe

So, for second one, it finds “bash” twice. When I run “bash” it starts my WSL terminal,
I start Cursor Agent from PowerShell and instructed Cursor Agent to user PowerShell as terminal program.

Is it using “bash” if it finds one regardless?

6

Any update on this?

7

Hey, thanks for the follow-up and for running those commands. That confirms it.

The issue is that C:\Windows\System32\bash.exe WSL is in your PATH, and the agent shell detection is picking it up instead of using PowerShell. This is a known problem. The agent doesn’t always respect the configured terminal profile on Windows.

A couple of things to try:

  1. If you’re using Cursor IDE, not just CLI, go to Cursor Settings Cmd+Shift+J > Agents > enable Legacy Terminal Tool. Then restart Cursor. This bypasses the newer terminal v3 that has the shell detection issue.

  2. For CLI specifically, try temporarily removing WSL bash from your PATH to see if that fixes it. You can test by running this before launching the agent:

$env:PATH = ($env:PATH -split ';' | Where-Object { $_ -notmatch 'WindowsApps' -and $_ -notlike '*System32*bash*' }) -join ';'
agent

This is a temporary test. If it works, it confirms the root cause.

  1. MCP servers. Did you check the MCP piece from my earlier reply? If you have any in ~/.cursor/mcp.json, try disabling them too.

The team is aware of the shell detection issue on Windows with WSL installed. Your report helps with prioritization. Let me know if the Legacy Terminal workaround resolves it.

8
  1. The Legacy Terminal Tool was already enabled
  2. Seems like the “bash*” was not in the PATH, but the file was in /windows/system32 so it was picked up automatically. I renamed it and also rename it in \Users\\AppData\Local\Microsoft\WindowsApps from where it was resolving after that, so now calling “bash” form PS or CMD is not finding a command with that name
  3. I renamed the mcp.json too

None of these worked for me, I still get the same issue:
”I tried reading the system time from the shell, but the command output came back empty, so I can’t report an exact time for you.”

I am using Cursor Agent v2026.04.08-a41fba1.

FYI, if I run Claude from PowerShell it tells me the time, a bit slower than when I run from the “wsl” installation, but it returns the time.