cursor-agent
Run Cursor Agent CLI as an independent coding agent for implementation, investigation, planning, or review in a local workspace. Use when asked to delegate work to Cursor, automate cursor-agent in hea
SKILL.mdskills/cursor-agent/SKILL.md
GitHubCursor Agent
Run cursor-agent from the intended workspace, give it a concrete outcome, monitor it at the task's time scale, and preserve its session ID whenever follow-up work is likely.
Read /cross-provider-agent first and apply its doctrine to the whole dispatch; this skill is only the Cursor transport.
Check the CLI and authentication
Treat the installed CLI help as authoritative because Cursor Agent is evolving:
cursor-agent --version
cursor-agent --help
cursor-agent status --format json
If authentication is missing, ask the user to run cursor-agent login, or use CURSOR_API_KEY when the user has already arranged it. Never print or embed an API key in a command.
agent permissions
Use the least authority suitable for the task:
- Add
--mode planfor read-only analysis and planning. - Add
--mode askfor read-only questions. - Prefer
--auto-reviewfor ordinary agent work. - Add
--forceonly when the user authorized changes and unattended command execution is necessary. - Use
--sandbox enabledwhen the task can run within Cursor's sandbox.
Start a worker
Run from the repository checkout or pass --workspace /absolute/path. For a headless task with structured progress:
cursor-agent -p --output-format stream-json --auto-review --trust \
"[message]"
Drop -p --output-format stream-json for an interactive task.
Every -p run requires --trust, including --mode plan and --mode ask; without it the run aborts immediately with Workspace Trust Required.
--auto-review prompts for tool calls its classifier does not deem safe, and in -p mode no one can answer, so the run can stall. For genuinely unattended work that must run any command, add --force instead.
Capture the session ID
When the ID must be known even if the first turn is interrupted, allocate it up front with cursor-agent create-chat and pass --resume="$cursor_chat_id" from the first run onward.
Otherwise capture session_id from the stream's system/init event or the terminal result object.
Resume a session
Resume with --resume="$cursor_chat_id" from the same workspace used to create the chat — chat discovery is workspace-scoped. Recover an unrecorded ID interactively with cursor-agent ls or cursor-agent resume.
Monitor and verify
Poll the NDJSON log often enough to surface approval prompts promptly. On completion require a clean exit and a successful terminal result event.
A cursor-agent or gh failure with transport errors naming the URL is the sandbox denying network, not bad credentials; rerun with the environment's required network escalation.
Profiled dispatch
Cursor takes permission and sandbox policy only from configuration files, so
profiled dispatch runs through the skill's transactional runner:
/absolute/path/to/cursor-agent/scripts/run-profiled.sh
The runner stages the profile for exactly one invocation, supervises the child, and restores the workspace byte-for-byte:
/absolute/path/to/cursor-agent/scripts/run-profiled.sh \
--workspace /absolute/path/to/workspace \
--profile github-pr-reviewer \
-- -p --output-format stream-json --trust "REVIEW_TASK"
Use stream-json for unattended runs. A long review with plain json prints nothing until the terminal result, so the caller can't tell progress, a tool denial, or a stall apart.
While the child runs, the workspace holds the staged .cursor/ files and the runner's .cursor-profile-txn/ lock and journal. That has two separate effects:
- A second Cursor runner on the same workspace hits the lock and exits 75. Give each Cursor dispatch its own workspace.
- Other providers are not locked out, but their clean-tree or diff checks in that workspace see the staged state:
git status --porcelainlists.cursor-profile-txn/and any staged.cursor/file the repo doesn't track, such as.cursor/sandbox.json, and shows a tracked.cursor/cli.jsonas an edit. Run them in a separate checkout, or before or after the Cursor run.
The staging has to stay in the workspace. Cursor reads the user sandbox.json from ~/.cursor/ regardless of CURSOR_CONFIG_DIR, and the workspace's own .cursor/sandbox.json takes priority over it, so overwriting the workspace copy is the only per-run way to stop a reviewed branch's Cursor config from widening the profile.
Run profiled dispatches with plain -p --trust (deny-unless-allowed), so the profile's allowlist is the whole command surface; the runner allowlists child arguments and rejects everything else.
available profiles
github-pr-reviewer : profiles/github-pr-reviewer/ encodes the profile from
/cross-provider-agent with cli.json as the canonical permissions object:
multi-word Shell(...) allows — live-verified but undocumented — for exactly
the profile's gh surface, paired with a sandbox.json GitHub-only network
allowlist as defense in depth.
The allowlist covers git only as git diff, git log, git show, and git status. git rev-parse has no allow entry, so the profile denies it.