Agent terminal tool appears non-functional: commands return empty output, 0ms, and exit 0 even for failing commands
Environment
Cursor (latest as of report time), but other versions failed as well (prerelease version, and older 2.4); reinstalling from scratch doesn’t help
macOS: Tahoe 26.3
Default shell: bash
Agent setting: either setting of Auto-Run (Ask Every Time/Run in Sandbox/ Run Everything (unsandboxed))
Legacy Terminal Tool = Enabled or Disabled (same failure for both)
Same behavior if starting Cursor with no ~/.cursor directory
It started doing this out of the blue; I have been running Cursor with no issues for a year
Summary
From Agent chat, terminal command execution appears broken. Commands report success instantly with no stdout/stderr, even when commands should fail (false) or produce output (date, pwd, whoami, echo)
Impact
Agent cannot run any CLI commands.
Any coding/debugging workflow requiring terminal execution is blocked.
Steps to Reproduce
Open Cursor and start an Agent chat.
Ask Agent to run terminal commands such as:
echo hello
date
pwd
whoami
false; echo $?
Expected Behavior
Commands should execute, but nothing happens.
Stdout/stderr should be visible to the Agent.
Exit codes should reflect command results (false should be non-zero).
Runtime should be realistic, not always 0ms.
Actual Behavior
Command output is always empty.
Reported runtime is always 0ms.
Exit code is always 0 (including when false is run).
This persists across restarts and settings changes.
For the benefit of others who might run into this scenario: the reason was that when launching its commands the agent was silently referring to a directory that does not exist anymore (it used to exist). The tool was failing immediately with no indication why.
Errors are not properly surfaced to the agent, let alone the user. This is a problem. I found out the cause by accident.
You’re right that silent failures when the working directory doesn’t exist are a serious issue. The agent should show a clear error, not return fake results like 0 ms and exit 0. The team is aware of this type of problem, and your report helps us prioritize it.
A couple questions to help the engineers:
Which directory was the agent trying to use? Was it a folder from a previous project or session that got deleted?
How did you fix it? Did you reopen the project, switch workspaces, or something else?
This info will really help us improve error handling in these cases. Let me know.
Yes, it was a folder that used to host the project in the workspace. That directory was renamed.
What was puzzling was that even after exiting Cursor, moving ~/.cursor to ~/.cursor-old, and starting Cursor anew, the error persisted even in a brand new chat, with the simplest of commands (e.g., just running false or ls).
At some point, the agent tried to echo into a file path prefixed by the non-existent directory, and that caught my eye. Before that command, there was no indication whatsoever that the agent was referencing the non-existent directory in any capacity. I suspect it was trying, silently, to specify the CWD to its internal cli tool, but the stale reference came from somewhere other than the configuration under ~/.cursor, and not from the context of the chat itself, since it kept failing in brand new chats.
All attempts to start fresh (restart Cursor, restart the Mac, move ~/.cursor, re-install Cursor) failed. After noticing the reference to the non-existent directory in the echo command, I simply told the agent that the directory didn’t exist. After that, the agent performed cli tasks successfully.
Thanks for the detailed follow-up. This is really valuable.
So, to sum up the two specific bugs:
Silent failure: If the agent’s CWD points to a directory that doesn’t exist, the terminal tool returns fake results (empty output, 0 ms, exit code 0) instead of showing an error. That’s clearly wrong. It should show an explicit error message.
Stale CWD persistence: The fact that this survived a full ~/.cursor removal and a clean reinstall is worrying. The CWD reference is probably stored in the VS Code workspace state (~/Library/Application Support/Cursor/), which isn’t cleared when you remove ~/.cursor. That would explain why telling the agent directly was the only thing that worked.
I flagged both of these with the team. No timeline yet, but your report is detailed enough for us to act on. The workaround “tell the agent the directory doesn’t exist” is a good tip for other users who hit this.
For any user who runs into the same symptoms, if all terminal commands return empty output and 0 ms, check whether your project directory was moved or renamed since you last opened the workspace. If it was, close the workspace and reopen it from the correct path, or just tell the agent the correct working directory.