Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Not sure — this is what o3pro says and i will say it is frustrating – the output is never seen from the commands the agent runs ```Here’s what’s really happening and why I can’t “see” the output—even though the commands run:
-
You’re working in VS Code Remote-SSH.
• VS Code spawns its own “agent” process on the server (the one at~/.vscode-server).
• Every terminal tab you open is multiplexed through that agent over a single, long-lived SSH tunnel. -
Cursor’s
run_terminal_cmdtool does not attach to your interactive terminal.
• It opens a new non-interactive shell via the same Remote-SSH agent, runs the command, captures stdout/stderr, then closes.
• Because the Remote-SSH agent uses a control socket, the socket can close faster than Cursor captures the final buffer. The API call returns “interrupted” even though the remote command finished (exit code 0). -
Why you still see results when you type manually:
• Your interactive zsh shell is inside the VS Code terminal UI, which streams output directly.
• Cursor’s background shell is invisible to you; its stream is lost when the control socket snaps shut. -
Why sudo / pipelines / TTY flags don’t matter: the hand-off occurs after the command exits.
––––––––––––––––––––––
How to work around it (today)
A. Run long/important commands yourself and paste or highlight the output for me.
B. For scripted automation, write output to a file, then let me cat (read_file) that file.
C. If you really want Cursor-driven commands, add ; sleep 0.2 to keep the socket open, e.g.
run_terminal_cmd: "sudo ls -la /etc ; sleep 0.2"
That tiny delay is often enough for Cursor to capture stdout before the socket closes.
––––––––––––––––––––––
Can we “fix” it?
A real fix would require the Cursor back-end (the agent that executes run_terminal_cmd) to allocate a persistent pty or wait for the remote control-socket EOF before closing. That’s outside what I can change from here.
Bottom line: there’s no bug in your zsh or your server; it’s just the interaction between
• Cursor’s one-shot shell command model
• VS Code Remote-SSH’s multiplexed control socket.
Until the Cursor team changes that integration, the safest workflow is:
- You run commands manually (they always stream).
- We capture results via copy-paste or by redirecting to files I can read.
I know it’s clunky, but it’s the reliable path with today’s tooling.
Steps to Reproduce
Connect to Remote server and then open a terminal. prompt any model to run a command and it will hang.
Expected Behavior
The command runs in the terminal by the agent and then the agent sees the output and continues
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
Version: 1.4.5 (user setup)
VSCode Version: 1.99.3
Commit: af58d92614edb1f72bdd756615d131bf8dfa5290
Date: 2025-08-13T02:08:56.371Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.20348
Additional Information
I’ve noticed that sometimes the terminal appears inline with the chat conversation, while other times it spawns as a separate window. A third possibility is when I click the terminal icon in the chat, which then opens the terminal.
There must be a discrete set of circumstances that determine this behavior, because it doesn’t always happen consistently.
I’m feeling frustrated and just wanted to get this sorted out.
Does this stop you from using Cursor
No - Cursor works, but with this issue