The cursor agent command with -p (print/non-interactive) flag hangs indefinitely and never returns a response, making it unusable for scripting.
Steps to Reproduce:
Ensure you’re logged in: cursor agent status (shows authenticated)
Run any prompt in print mode:
cursor agent -p --output-format text “Say hello”
Command hangs indefinitely (tested for 90+ seconds with no response)
Expected Behavior
Command should return the AI response to stdout and exit.
Command hangs indefinitely with no output. Tested with:
• --model gpt-4o-mini - still hangs
• Simple prompts like “Say hello” - still hangs
Trying to use cursor agent -p for automated commit message generation in a shell script.
Interactive mode (without -p): Works fine. cursor agent “Say hello” returns a response as expected.
Streaming output (--output-format stream-json):
cursor agent -p --output-format stream-json “Say hello” Completely silent. No output after 30+ seconds, had to kill the process.
Behavior when hanging:
Completely silent - no initial output, no error messages, no partial responses. Zero output to stdout or stderr.
Credentials:
✓ Logged in as
Different model (sonnet-4.5):
cursor agent -p --model sonnet-4.5 “Say hello” Also completely silent. Same hang behavior.
Summary:
• Interactive mode: Works
• Print mode (-p): All variations hang with zero output
• --output-format text - hangs
• --output-format stream-json - hangs
• --model gpt-4o-mini - hangs
• --model sonnet-4.5 - hangs
The issue appears to be specifically with the -p flag. Something in headless/print mode isn’t initiating the request or is blocking before any output is produced.
Adding more debugging details from our investigation:
Same issue here. Cursor 2.4.21 (arm64 macOS), cursor-agent version 2026.01.28-fd13201.
What we found with lsof/network analysis:
cursor agent status shows logged in ✓
cursor agent –print hangs with zero output
Critically: lsof -p <pid> shows the agent process has NO TCP connections — it’s stuck waiting on internal unix sockets, never making API calls to Cursor servers
Worker-server processes (worker-server) also have no network connections
Killing worker servers and retrying doesn’t help
Network connectivity to api2.cursor.sh is fine (verified with curl -v)
Streaming mode (--output-format stream-json) also hangs with no output
Use case: Running cursor agent as a subprocess from a Node.js Slack bot. The 5-minute timeout always hits.
This appears to be an IPC hang between the CLI process and internal worker-server, not an API/auth/network issue. The agent never even attempts to make network requests.
Hey Dean,
I took your debugging advice, here are my debugging results:
Environment: Linux Ubuntu, Agent CLI 2026.02.13-41ac335 (latest), team plan user, network egress via Singapore (Zenlayer/CorpLink corporate VPN).
Test results
Test
Result
agent “Say hello” (interactive, no -p)
Appeared to hang — no output for 20s
agent -p --output-format stream-json “Say hello”
Same — completely silent for 20s
agent -p --model sonnet-4.5 “Say hello”
Same — silent hang
agent --list-models
Works fine (3.4s)
agent login
Works fine
Root cause found via strace + ss monitoring:
The agent IS working, but TCP connections to some API backend IPs get stuck in SYN-SENT state (no SYN-ACK from server). The agent silently retries across different IPs until it finds a responsive one. This takes 10-15 seconds on my network, during which there is zero output (no loading indicator, no stderr, nothing).
With timeout 60:
agent -p --trust “Say hello” → Succeeded in 13s — replied in Chinese
agent -p --trust “What is 2+2?” → Succeeded in 11s — correct answer
TCP state timeline (monitored every 2s during a run):
2s: SYN-SENT → 107.21.32.129:443 (stuck, no SYN-ACK)
10s: ESTAB → 54.173.34.77:443 (connected to different IP)
Some AWS us-east-1 IPs respond fine from my network; others time out at the TCP level. All IPs are reachable via curl (HTTP 200 in ~0.8s), so it may be an intermittent issue or a protocol-level difference (HTTP/2 long-lived streams vs short requests).
Two issues I’d flag:
UX: Agent CLI produces zero output during connection retries — no spinner, no “Connecting…”, no stderr. Users see a completely frozen terminal.
Network: The retry/failover across API backend IPs adds 10-15s latency from Asia-Pacific networks. A shorter connect timeout per IP or regional endpoint selection could help.
@TerryZ great work with strace and tracking TCP states. This is really useful debugging.
Both issues you called out are on the team’s radar:
UX: Having no output at all (spinner, “Connecting…”, stderr) during TCP retries is genuinely bad UX, especially for headless use and automation.
Network failover: Long connect timeouts to some AWS backend IPs, adding a 10 to 15s delay.
I’ve shared your analysis with the team. There’s no timeline yet, but detailed reports like this help with prioritization.
@dhrubesh@SilasReinagel@Matan_Lasry as a workaround for now, based on TerryZ’s findings, commands in -p mode do finish, but the first connection can take 10 to 15+ seconds.
Let me know if -p mode never returns a result even with a long timeout. That would be a different issue.
Works fine. cursor agent “Say hello” returns a response as expected.
Completely silent. No output after 30+ seconds, had to kill the process.