OS: Windows Server 2019, build 10.0.17763 (non-admin user)
Cursor version: 3.3.30 (user setup, stable)
Commit: 80b138a7a0a948e1a798e9ed7867d76a1ba9a310
Electron: 39.8.1 / Node.js 22.22.1
Problem
When the agent runs a terminal command (Shell tool / ShellExec), the shell
process starts (cmd.exe banner + prompt appear), but the command itself
never executes and no output is ever returned. The shell just sits idle
until the tool times out. The same machine works fine for the integrated
terminal (Terminal → New Terminal) — I can run commands there with no issues.
Also no issue when running VSCode using GHCP agent on same machine.
What I’ve tried
terminal.integrated.automationProfile.windows → cmd.exe, then PowerShell
Full kill + restart of Cursor (updated from 3.2.21 → 3.3.30 in process)
None of these changed the agent shell behaviour.
VS Code / GitHub Copilot comparison
Running VS Code with GitHub Copilot Chat on the exact same machine works
fine — agent terminal commands complete and return output normally.
Workaround
None found. Running commands manually in the integrated terminal and pasting
output to the agent is the current workaround.
Steps to Reproduce
ask in chat: get current time using terminal
Expected Behavior
Agent runs terminal commands - they execute and Cursorcan read output
Thanks for the thorough report and all the troubleshooting you’ve already done.
Windows Server 2019 (build 17763) has an older ConPTY implementation that can behave differently from Windows 10/11, and we’re seeing similar reports from other Windows users. To help our team narrow down the root cause, could you provide a few pieces of diagnostic info?
Developer Console output when a command hangs: press Ctrl+Shift+I (or Help > Toggle Developer Tools), click the Console tab, then trigger a shell command from the agent. Copy any red error messages that appear.
Code page: in the interactive terminal (which works fine), run chcp and share the output. Some non-UTF-8 codepages can interfere with the agent’s shell output parsing.
Security software: is there any endpoint protection or application control software on this machine (e.g., McAfee, CrowdStrike, AppLocker, Windows Defender Application Control)? These can silently interfere with process spawning or PTY I/O.
Other team members: do other colleagues on the same Windows Server 2019 setup see the same behavior? That would help us determine if it’s machine-specific or systematic.
In the meantime, you might also find this related thread useful, where another Windows user is reporting the same symptom.
well, this is an enterprise machine, for sure there are many security tools installed, but we have some machine on which it works and some machines on which it doesn’t , we can’t tell what makes it work on some and doesn’t on others
Thanks for providing this. Here’s what the diagnostics tell us:
The console errors are OpenTelemetry timeout messages, which are a side effect of the shell hang rather than its root cause. The telemetry layer times out because the underlying shell operation never completes.
Code page 437 is standard US English — that rules out codepage-related issues.
The most useful piece: it works on some machines but not others. That strongly points to a machine-level difference, most likely an endpoint protection or application control tool that’s interfering with Cursor’s agent terminal process.
To narrow this down, could you (or your IT team) compare a working machine against a non-working one? Specifically:
Endpoint protection software versions - McAfee/Trellix, CrowdStrike, Carbon Black, Symantec, or whatever Intel uses. Check if the versions or policy profiles differ between working and non-working machines.
Application control / allowlisting policies - some enterprise tools block unsigned or unrecognized processes from spawning child processes. Cursor’s agent shell runs in a separate agent-exec extension host process, which may not be in your IT’s allowlist.
Quick test (if IT allows it): temporarily disable endpoint protection on one non-working machine and see if the agent terminal starts working. That would confirm the security tool as the blocker.
If your IT team can identify the tool, we can work on specific guidance for whitelisting Cursor’s processes. If you’d prefer not to share security tool details publicly on the forum, feel free to email us at [email protected] and we can continue the conversation there.
Workspace:W:\WINX (also tested from C:\Users\charl)
Release track: was dev, now default
Legacy Terminal Tool: tried ON and OFF (both failed)
Describe the bug
When the agent runs any shell command (even echo cursor-terminal-test), the command does not return stdout/stderr to the agent. The background terminal log shows only metadata (pid, cwd, command, running_for_ms) — no output and often no exit_code. Commands time out (~15–25s) and get backgrounded.
The same command in Terminal → New Terminal returns instantly.
Actual behavior
Agent: hang or background after timeout; empty output
UI is getting to the stage where simple fixes (see my previous reports) are never getting done, and are increasing product frustration - this is silly given these should be quick fixes, easy to implement with CursorAI.
Fixed by downgrading to (and turning off all upgrades):
Version: 3.5.38 (system setup)
VSCode Version: 1.105.1
Commit: 009bb5a3600dd98fe1c1f25798f767f686e14750
Date: 2026-05-26T21:32:06.537Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200
