Terminal Command Output Capture Completely Broken

[art_m]

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Summary

The run_terminal_cmd tool stops returning any stdout/stderr output mid-session. Commands appear to execute successfully (shell exits cleanly, files may be created), but zero output is captured and returned to the agent.

Symptoms

1. No output from any command - Even the simplest commands (echo "hello", pwd, date) return empty output
2. Commands appear to execute - Exit codes are not shown, but the shell prompt indicates the command completed
3. Persistent across all command types - Affects simple commands, complex builds, piped commands, redirections
4. Session started working, then broke - Earlier in the same session, terminal commands worked correctly and returned full output

Steps to Reproduce

1. Open a workspace with a C project
2. Use the agent to run several terminal commands (e.g., make, ls, etc.) - initially these work
3. Continue using the agent for an extended session with many terminal commands
4. At some point, all terminal commands start returning empty output - the “Command output:” section is blank, followed by “The previous shell command ended, so on the next invocation of this tool, you will be reusing the shell.”

Diagnostic Tests Performed

Test 1: Simple echo command
Command: echo "Terminal test" && pwd && date
Result: Empty output

Test 2: With full permissions
Command (with required_permissions: [“all”]): echo "hello"
Result: Empty output

Test 3: Redirect to file in /tmp
Command: make -B xxxx > /tmp/foo.log 2>&1
Result: Command completed, but file could not be read back (file not found in workspace)

Test 4: Redirect to file in workspace
Command: cd /Users/foo/bar/ && make -B xxx > build.log 2>&1
Result: Command completed, but build.log could not be read with read_file tool

Test 5: Touch a file
Command: touch /Users/art/foo/bar/build.log
Result: Empty output, file not visible to read_file tool

Test 6: Direct file creation
Command: echo hi > /tmp/foo_testfile
Result: Empty output, file not readable

What Still Works

• list_dir tool - correctly lists directory contents
• read_file tool - can read pre-existing files
• grep tool - returns search results correctly
• search_replace / write tools - file edits are applied successfully
• User can run same commands manually in their terminal and see output

What Does NOT Work

• run_terminal_cmd - no stdout/stderr captured for ANY command
• Files created by terminal commands are not visible to read_file

Timeline

• Working: Commands like make 2>&1 | head -80 returned full compiler output
• Broken: At some point during extended use, output stopped appearing
• No clear trigger: No specific action appears to have caused the break

Impact

This completely blocks the agent from:

• Seeing build errors/warnings
• Debugging compilation issues
• Verifying command success
• Reading command output of any kind

Workaround

User must manually run commands and paste output into chat.

Additional Notes

• The session involved many terminal commands over an extended period
• Multiple workspaces are open: /Users/art/foo/bar and /Users/art/foo/baz
• The terminals folder path shown in system info: /Users/art/.cursor/projects/Users-art-Library-Application-Support-Cursor-Workspaces-1767549399189-workspace-json/terminals
• When checked, the terminals folder did not exist: “Error calling tool: Directory … does not exist or it’s not a directory”

Suggested Investigation Areas

1. Terminal output buffer overflow or size limit?
2. Terminals folder cleanup/deletion during session?
3. Pipe/PTY connection lost between agent and terminal?
4. Session state corruption after extended use?
5. Race condition in terminal output capture?

---

To Cursor Team: This is a critical issue that completely breaks the agent’s ability to assist with build/compile tasks. The agent cannot see any command output, making iterative debugging impossible.

Steps to Reproduce

Open a workspace with a C project
Use the agent to run several terminal commands (e.g., make, ls, etc.) - initially these work
Continue using the agent for an extended session with many terminal commands
At some point, all terminal commands start returning empty output - the “Command output:” section is blank, followed by “The previous shell command ended, so on the next invocation of this tool, you will be reusing the shell.”

Expected Behavior

things would work

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.2.43
VSCode Version: 1.105.1
Commit: 32cfbe848b35d9eb320980195985450f244b3030
Date: 2025-12-19T06:06:44.644Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.0.0

For AI issues: which model did you use?

all agents are experiencing the problem

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the report.

This is a known issue with capturing terminal output. Most cases were on Windows, but your macOS report is important for the team.

Please try this:

1. Enable the Legacy Terminal Tool:

• Cursor Settings CMD+Shift+J > Agents > Inline Editing & Terminal > enable “Legacy Terminal Tool”
• CMD+Shift+P > “Terminal: Kill All Terminals”
• Fully restart Cursor

2. We need a bit more info for the engineers:

• The Request ID from the chat (top right of the chat > Copy Request ID)
• Logs from Help > Toggle Developer Tools > Console (a screenshot of any errors, if there are any)
• Does it still happen after a full restart of Cursor?
• Which shell are you using (bash or zsh)?

Details here: Cursor version 2.1.39 has terminal bug

Let me know if the Legacy Terminal option helps.

[art_m]

i am using zsh on macos, latest everything. terminal output capture began working as expected by simply starting a new chat in the same cursor session. the original chat remained broken, the new chat worked fine. i can’t find the cursor instance where the bug appeared so i can’t provide the console logs

[jpcody (Joshua Cody)]

Just noting that I’m having what I believe is the same issue on MacOS 15.6.1 running Ghostty 1.2.3 and fish shell. In agent mode, my Rails tests report as failed in the embedded terminal’s status bar, but the agent happily responds “All tests pass!”

Opening a new agent session and asking:

Please get the current date from the embedded terminal.

Results in the agent trying a few different ways before stating:

The terminal is executing commands (exit code 0), but the output isn’t appearing here.

I get the same with the legacy terminal tool (request f0f6360a-5daf-44ee-abd1-076c3c22e100) or the standard terminal tool (request b2145366-46ca-455c-ba6c-d0ea92c4bd81).

Note: also tried the latest nightly, but it didn’t work there either. Also tried downgrading to 2.3.34, which works for a coworker, and that didn’t work either.

[jpcody (Joshua Cody)]

I reached out to support a few days ago as well but haven’t heard back. I’ll just keep chiming in on every update to report whether it fixes things or not, as this is a significant hindrance to getting quality output from the agent (since it can’t iteratively read output to fix tests)

Version: 2.3.41 (Universal)
VSCode Version: 1.105.1
Commit: 2ca326e0d1ce10956aea33d54c0e2d8c13c58a30
Date: 2026-01-16T19:14:00.150Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 24.6.0

No dice, output still can’t be read. Request a7a43434-9e4d-44d2-9b8e-40d0b5e0b718

[Ariel_Copello]

The shell broke for me too immediately after the last update. Normally I use wsl. Completely broken now, bot tells me the commands are executed, but only receives code 0 and no output. Powershell works only if i open cursor with it pre-selected, legacy or not legacy works ok. If i change to wsl, to see that it’s still not working, and then try to go back to powershell, now is broken like wsl. Bot report:

Cursor WSL Integration Bug Report

Problem Summary

Cursor’s WSL (Windows Subsystem for Linux) terminal integration is completely broken. Commands appear to execute successfully (exit code 0) but produce no actual output or effects, indicating the terminal is running in a simulation mode rather than connecting to real WSL.

Environment

• OS: Windows 10 (Build 26200)

• Cursor Version: [Please check Help → About]

• WSL Version: WSL2 (confirmed installed via WindowsApps directory)

• Shell Configuration: Set to WSL in Cursor settings

Steps to Reproduce

1. Open Cursor

2. Go to Settings → Terminal → Set shell to WSL

3. Restart Cursor

4. Open terminal and run any command (e.g., echo “test”, pwd, ls)

Expected Behavior

• Commands should execute in WSL environment

• Output should be visible in terminal

• Files should be created/modified when running commands like echo “test” > file.txt

Actual Behavior

• Exit code: Always 0 (success)

• Output: Completely blank/empty

• File operations: No files created or modified

• Error handling: Even nonexistent commands return exit code 0 with no error messages

Diagnostic Results

• WSL binaries exist in C:\Users\[user]\AppData\Local\Microsoft\WindowsApps\

• WSL works correctly when accessed directly via Windows Terminal

• Cursor terminal commands produce no output whatsoever

• File creation commands don’t create files (verified via file system tools)

• Even commands like nonexistent_command return exit code 0 (should fail)

Attempts to Fix

• PowerShell works perfectly in Cursor

• WSL restart (wsl --shutdown then restart) - No change

• Legacy terminal mode - No change

• Multiple Cursor restarts - No change

• Different WSL configurations - No change

Root Cause Analysis

The issue is not with WSL itself (works fine externally) but specifically with Cursor’s WSL integration. Commands are being “simulated” successfully but not actually executed in the WSL environment. This suggests a bug in Cursor’s terminal backend or WSL detection/connection logic.

Impact

• Complete inability to use WSL terminal in Cursor

• Forces use of PowerShell as workaround

• Blocks development workflows requiring Linux tools

Additional Context

• PowerShell terminal works perfectly in same Cursor instance

• Issue persists across Cursor restarts and WSL restarts

• WSL works correctly in Windows Terminal and other applications

Workaround

Use PowerShell instead of WSL in Cursor settings - this works perfectly.

Version: 2.3.41 (system setup)
VSCode Version: 1.105.1
Commit: 2ca326e0d1ce10956aea33d54c0e2d8c13c58a30
Date: 2026-01-16T19:14:00.150Z (4 hrs ago)
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26200

[Ariel_Copello]

This worked for me. ■■■■ solution, but it worked. Use specstory to save you important chats.

Cursor version 2.1.39 has terminal bug

Got the same bugs on version 2.1.50 (WSL). It goes beyond the model failing to use the terminal (exit code 0, no output); it also breaks the auto-apply feature, forcing manual approval everytime. It seems to happen specifically in workspaces with a heavy chat history/large database. To fix the problem I deleted the project’s folder located in %APPDATA%\Cursor\User\workspaceStorage. It looks like the database gets corrupted or something. But this solution clears the chat history which is not s…

[banth31]

feels like CLI is completely broken now

[jpcody (Joshua Cody)]

@deanrie Any chance you could ack whether there are any known Mac workarounds or if the team is making progress on a fix? I never got any traction via support email.

[deanrie]

Hey, I can see there are a few different issues mixed into one thread.

@art_m: You already found a fix. Starting a new chat helped. This is a known bug where the terminal breaks after a long session. If it happens again, try:

• Start a new chat (your workaround)
• Or delete the project folder from ~/.cursor/User/workspaceStorage (this clears chat history, but fully fixes it)

@jpcody: Try the workspaceStorage workaround above. On macOS with non-standard shells (Ghostty, fish), this shows up more often. If that doesn’t help, can you share:

• Logs from Help > Toggle Developer Tools > Console (a screenshot of the errors)
• Your Ghostty version and your fish shell config

The team knows about the issue, but there’s no ETA yet. Your report plus the request IDs help us prioritize.

General: This is a known production terminal bug. The Windows version was fixed in December, but macOS and WSL cases are harder. Legacy Terminal doesn’t always help. Best workaround for now is starting a new chat or clearing workspaceStorage.

[jpcody (Joshua Cody)]

Thanks for the response, @deanrie. Some updates.

• Clearing ~/Library/Application\ Support/Cursor/User/workspaceStorage/ does not fix the issue for me.

• A new chat does not fix the issue for me

• Here are the console logs, cleared before and after issuing a prompt of “Please get the current date from the embedded terminal.” cursor-logs.txt (14.5 KB) (Screenshot also attached, with verbose filtered out). This was interesting, because /bin/zsh seems to be getting involved. That exists and is executable, though it’s not the shell I want to be using.

• I’m using Ghostty 1.2.3 Build 12214, and fish is version 3.7.1. Attached is my zipped fish config.

  fish-cursor.zip (17.4 KB)

I’ve also tried the solutions in this thread to no luck.

[ravirahman]

Hi @jpcody, it’s a bit suspicious that the logs indicate it is trying to spawn bin/zsh, not /bin/zsh. Can you double check your terminal configurations (and the $SHELL environ) to make sure this is set correctly?

[rumburakusai]

Try CTRL+SHIFT+P → Search for Reload with Extensions Disabled .. I wonder if this can help.. I used this method to tackle another issue with the terminal when my commands were just hanging and you could wait forever..

[jpcody (Joshua Cody)]

I totally agree that this seems odd that it’s zsh and there’s no leading slash. I feel like I’ve tried every setting in the world to get this warning suppressed and checked every part of my terminal configuration. Below is a screenshot of the console, the agent using the wrong shell and not being able to read output, and the terminal using the right shell.

[jpcody (Joshua Cody)]

Great call. Unfortunately, no dice.

[rumburakusai]

Hm.. I see semi-automatic upgrade (actually downgrade) kicked in. Now I am on 2.4.21..

[ravirahman]

Could you expand the spawnargs in one of those errors?

[jpcody (Joshua Cody)]

Yep: