I kicked off a simple agent from my command line to work on a change to my code in the cloud. This successfully completed, and the PR was opened, but I don’t see the agent in the Cursor agents UI on the website. The Cursor CLI also was blocked until the agent was finished, even though I would assume, based on the documentation, that kicking off a cloud agent is non-blocking.
Steps to Reproduce
Authenticate with Cursor CLI.
Authenticate with GH.
Run cursor-agent -c --yolo -p "Add a test comment to README.md in <user>/<repo> and open a PR"
CLI is blocked until completed
Cursor Agents page shows no new agent created
Expected Behavior
Authenticate with Cursor CLI.
Authenticate with GH.
Run cursor-agent -c --yolo -p "Add a test comment to README.md in <user>/<repo> and open a PR"
CLI is available and shows confirmation the cloud agent was kicked off
On the first issue (the CLI hangs), this is a known regression starting from CLI version 2026.02.27. It’s already being tracked, but there’s no ETA yet. More details here: cursor-agent create-chat hangs indefinitely.
As a workaround, you can roll back the CLI to the previous version.
Thanks for the quick response, its really blocking me kicking off swarms of agents!
CLI Version:
cursor-agent update Checking for updates… Already up to date > cursor-agent --version 2026.02.27-e7d2ef6
I can kick off another test cloud agent, but nothing was printed, no agent ID or link.
Some more information; when I run `cursor-agent ls` it shows the two agent sessions in the TUI interface, but they are both “New Agent”.
This is an example workflow. It would also be helpful to clarify that non-interactive use of cloud agents requires `-p` which is documented, but the Ask AI seems to hallucinate and not understand this is required, otherwise without `-p` the CLI requires input. Although this might be a bug, since there is a prompt and it goes straight to asking for another prompt without it.
> cursor-agent -c -p --yolo “Add a test comment to README.md in jjfantini/<repo> and open a PR”
Done. PR is open at **https://github.com/jjfantini/<repo>/pull/4**.
What was done:
Cloned jjfantini/<repo>
Created branch test/add-test-comment off <repo>-main
Added an HTML comment (<!-- This is a test comment to verify PR workflow - added by jjfantini -->) at the end of README.md
Pushed and opened the PR against <repo>-main
My goal of using the CLI is to let an agent control the `agent` CLI and use Cursors harness to work on code development while I have an agent of my own to orchestrate everything. I have come across some issues and a lack of clear documentation (e.g overlap and ambiguity of `-p/-trust/-yolo/` flag…they are all needed for non-interactive -c mode) and support for this type of use case.
perhaps would be better to use the API? I like the CLI tho….
I am just testing some commands manually to lock in the flow and usage before I can let my agent run free.
On the dashboard issue, the CLI version 2026.02.27 has a few known bugs, including the blocking behavior you ran into. Since cursor-agent ls shows sessions as “New Agent” but they don’t show up on cursor.com/agents, it looks like the cloud agent metadata isn’t syncing to the web dashboard correctly. I’ve flagged this to the team.
A few notes on the CLI workflow:
About the -p flag, yes, -p or --print is required for non-interactive mode. Without it, the CLI expects interactive input. The docs mention this here: Using Agent in CLI | Cursor Docs
Also, in your example, -p is separated from the prompt. Make sure the prompt is passed as the value to -p, like this: cursor-agent -c --yolo -p "your prompt here".
If you want to run multiple agents from a script, the Cloud Agents API might be a better fit than the CLI since it’s meant for programmatic use: Cloud Agents API | Cursor Docs
The CLI cloud mode -c is still getting better, and the blocking issue makes it harder to launch agents in parallel.
@deanrie It seems as though cloud mode is not getting kicked off, when going into the Agent that was spun up, it looks like it cloned on local, and did not execute on cloud. This happened for all 3 tests I ran on my local machine.
I have used -c on my agentic workflow on my VPS and was able to get a PR submitted, the work session was NOT shown on the Agents Dashboard, so I assume that this was also happening on my VPS.
cursor-agent ls
Cursor Agent v2026.02.27-e7d2ef6
~/Desktop/humblHoldings · main
Add a test comment to README.md in jjfantini/orghi and open a PR
Claude 4.6 Opus (High Thinking), large language model, updated 2025
Let me find the README.md and understand the current state of the repo.
⬢ Globbed “**/README.md” in .
Found 4 files
$ git remote -v 685ms
origin [email protected]:jjfantini/humblHoldings.git (fetch)
origin [email protected]:jjfantini/humblHoldings.git (push)
… truncated (1 more line) · ctrl+o to expand
This workspace is jjfantini/humblHoldings, but you want changes in jjfantini/orghi. Let me clone that repo
and work on it.
$ cd /tmp && git clone [email protected]:jjfantini/orghi.git exit 128 • 619ms
Cloning into ‘orghi’…
[email protected]: Permission denied (publickey).
… truncated (5 more lines) · ctrl+o to expand
SSH key issue. Let me try HTTPS.
$ cd /tmp && rm -rf orghi && gh repo clone jjfantini/orghi 2.8s
Cloning into ‘orghi’…
From
… truncated (10 more lines) · ctrl+o to expand
Got it - it’s your fork. Let me read the README, create a branch, add the test comment, and open a PR.
⬢ Read /tmp/orghi/README.md
$ cd /tmp/orghi && git branch -a && echo “—” && git log --oneline -5 360ms
* orghi-main
remotes/origin/HEAD → origin/orghi-main
… truncated (15 more lines) · ctrl+o to expand
Good - the default branch is orghi-main. Let me create a branch, add the test comment, push, and open a
PR.
$ cd /tmp/orghi && git checkout -b test/add-readme-comment-v2 orghi-main 791ms
Switched to a new branch ‘test/add-readme-comment-v2’ │
$ cd /tmp/orghi && git add README.md && git commit --trailer “Made-with: Cursor” -m "$(cat <<‘EOF’
test: add test comment to README.md
Verifying PR workflow from orghi fork.
EOF
)" 417ms
[test/add-readme-comment-v2 17b89df] test: add test comment to README.md
1 file changed, 2 insertions(+)
… truncated (1 more line) · ctrl+o to expand
$ cd /tmp/orghi && git push -u origin test/add-readme-comment-v2 1.0s
branch ‘test/add-readme-comment-v2’ set up to track ‘origin/test/add-readme-comment-v2’.
… truncated (7 more lines) · ctrl+o to expand
$ cd /tmp/orghi && gh pr create --base orghi-main --title “test: add test comment to README.md” --body
"$(cat <<‘EOF’
## Summary
- Adds an HTML test comment to the top of README.md to verify PR workflow from the orghi fork.
## Test plan
- [x] Comment is valid HTML and does not affect rendered README display.
Made with [Cursor](https://cursor.com)
EOF
)" exit 1 • 1.4s
pull request create failed: GraphQL: Head sha can't be blank, Base sha can't be blank, No commits between
HKUDS:orghi-main and jjfantini:test/add-readme-comment-v2, Base ref must be a branch (createPullRequest)
The gh CLI is defaulting to the upstream repo. Let me target the fork explicitly.
$ cd /tmp/orghi && gh pr create --repo jjfantini/orghi --base orghi-main --head test/add-readme-comment-v2
–title “test: add test comment to README.md” --body "$(cat <<‘EOF’
## Summary
- Adds an HTML test comment to the top of README.md to verify PR workflow from the orghi fork.
## Test plan
- [x] Comment is valid HTML and does not affect rendered README display.
Made with [Cursor](https://cursor.com)
EOF
)" 4.5s
https://github.com/jjfantini/orghi/pull/2
Done. PR is open at
.
What was done:
• Created branch test/add-readme-comment-v2 from orghi-main
• Added an HTML comment to the top of
README.md
• Pushed and opened the PR against orghi-main
What is the roadmap for Cursor to have an MCP I can install for my agent to have programmatic access to the Cursor service, without having to build out my own harness for the Agent to use the API?
I understand this is not currently implemented.
”MCP (Model Context Protocol) is not yet supported by the Cloud Agents API.”
Good catch. From the logs, the agent really did run locally: cloning into /tmp/, local git and gh commands. That explains why no sessions show up in the dashboard at cursor.com/agents. They simply weren’t started in the cloud.
Looks like the -c flag is silently falling back to local execution instead of sending the request to the cloud. I passed this to the team along with the earlier issues.
About MCP: there’s no official Cursor MCP server for programmatic access to Cursor services. For your use case, orchestrating agents programmatically, the best option is the Cloud Agents API: Cloud Agents API | Cursor Docs
Right now, the Cloud Agents API is the most reliable path for programmatically orchestrating multiple agents in parallel. CLI cloud mode -c is still being worked on.
Okay cool thanks, yeah looks like I will either wait until `-c` mode is made a bit more stable or add in the API tooling so my agent can kickoff some cloud agents.
Parallelism is the goal, but for now focusing on just getting one solid workflow down!
I ran into the same thing - -c silently falling back to local, agents not showing up on the dashboard. Ended up going the API route instead of the CLI.
So I actually built a TUI for this (called it agents-control-tower).
It wraps the Cloud Agents API, lets you launch agents (pick repo, prompt, model), send follow-ups, stop or delete them. Polls every 5 seconds so you see status changes in real time.