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 No output from any command - Even the simplest commands (echo "hello", pwd, date) return empty output Commands appear to execute - Exit codes are not shown, but the shell prompt indicates the command completed Persistent across all command types - Affects simple commands, complex builds, piped commands, redirections Session started working, then broke - Earlier in the same session, terminal commands worked correctly and returned full output 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.” 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 Terminal output buffer overflow or size limit? Terminals folder cleanup/deletion during session? Pipe/PTY connection lost between agent and terminal? Session state corruption after extended use? 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

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: 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 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.

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

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.

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) :slight_smile: 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

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 Open Cursor Go to Settings → Terminal → Set shell to WSL Restart Cursor 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 :white_check_mark: WSL binaries exist in C:\Users\[user]\AppData\Local\Microsoft\WindowsApps\ :white_check_mark: WSL works correctly when accessed directly via Windows Terminal :cross_mark: Cursor terminal commands produce no output whatsoever :cross_mark: File creation commands don’t create files (verified via file system tools) :cross_mark: Even commands like nonexistent_command return exit code 0 (should fail) Attempts to Fix :white_check_mark: PowerShell works perfectly in Cursor :cross_mark: WSL restart (wsl --shutdown then restart) - No change :cross_mark: Legacy terminal mode - No change :cross_mark: Multiple Cursor restarts - No change :cross_mark: 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

This worked for me. ■■■■ solution, but it worked. Use specstory to save you important chats. [image] Cursor version 2.1.39 has terminal bug Bug Reports 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…

feels like CLI is completely broken now

@deanrie :face_with_peeking_eye: 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.

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.

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. [CleanShot 2026-01-22 at 08.41.32@2x]

Terminal Command Output Capture Completely Broken

Support Bug Reports

Ariel_Copello (Ariel Copello) January 16, 2026, 11:45pm 8

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

Topic		Replies	Views
Cursor version 2.1.39 has terminal bug Bug Reports	90	4149	December 17, 2025
Terminal commands 100% broken Bug Reports	56	2529	October 9, 2025
Agent Terminal not working Bug Reports java	151	8648	January 8, 2026
Agent loses terminal output Bug Reports	37	1014	December 6, 2025
Agent Run/Execute shows No output and does not return real stdout in project windows on macOS Bug Reports terminal , macos	4	211	March 11, 2026

Terminal Command Output Capture Completely Broken

Related topics