Where does the bug appear (feature/product)?
Cursor CLI
Describe the Bug
Summary
When two cursor-agent processes are launched nearly simultaneously in a non-TTY environment, one exits immediately with status 1 and no output. Sequential or delayed starts succeed, but true parallel execution is unreliable. Blocking multi-agent orchestrators from running concurrent sessions.
Impact
Any automation (e.g., MCP orchestrators) that needs to run multiple cursor-agent sessions concurrently must serialize them, drastically reducing throughput.
Workaround
Run the agents one at a time with a small delay (≈100 ms) before starting the next command. This avoids the crash but sacrifices parallelism.
Steps to Reproduce
sh -c '
cursor-agent --approve-mcps --model=composer-1 --print agent "List three popular pizza toppings." &
pid1=$!
cursor-agent --approve-mcps --model=composer-1 --print agent "Share a quirky pizza trivia." &
pid2=$!
wait $pid1; status1=$?
wait $pid2; status2=$?
echo "status1=$status1 status2=$status2"
'
Expected Behavior
Both processes complete with status 0, each printing its pizza response.
Actual behavior
One process prints a normal response with status 0. The second exits almost instantly with status 1 and no output (status1=1 status2=0 or vice versa). This persists even if you add a short delay (100–250 ms) between starts when they’re still launched “in parallel” from the same script. Fully sequential runs with a deliberate gap work reliably, but they are no longer truly parallel.
Operating System
MacOS
Current Cursor Version (Menu → About Cursor → Copy)
Version: 2025.11.06-8fe8a63
Additional Information
tested the same with claude and codex and they both worked even if launched in parallel
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor