Automate

Automating agent work means letting Claude Code, Codex or Cursor run without a person at the keyboard: toward a stated goal, on a schedule, on a cloud machine, or from a labelled issue to a pull request. It pays off only when deterministic gates, a budget and a named human merge check the result instead of someone reading every line.

This section is for developers who want the agent to keep working after they stop typing, and for tech leads who decide what may run unattended. Every “keep going” you type is a turn the agent could have taken alone.

Which automation guide fits your job?

You want to…	Start with
Keep one session working until a checkable condition holds	The /goal command
Re-run a prompt on a cadence: poll a deploy, babysit a PR	The /loop command
Choose between Claude Code cloud sessions, Codex cloud, Cursor Cloud Agents, Copilot and Jules	Background and cloud agents compared
Turn a labelled issue into a review-ready pull request with no one typing	Issue to PR pipeline
Carry a change past the merge: auto-merge by risk class, rollout, rollback	Intent to production
Branch in your own code on what the agent found	Agent SDKs compared
Split one job across several agents without multiplying cost	Orchestration patterns

Multiplexers, sandboxes and third-party orchestrators live in the agent tools catalog.

In what order should you automate?

Each step removes one kind of human involvement. Move on only when the previous step runs without rescue.

1. Make “done” machine-checkable. A single command (tests, type check, lint) must decide success. See Level 4: you write the specs.
2. Stop typing “keep going”. Use /goal for work with a finish line and /loop for work on a cadence inside a session you still watch.
3. Move the run off your laptop. Start the same bounded task as a background or cloud agent and review what comes back. Add an SDK or several agents only where one headless command is not enough.
4. Remove the trigger. Wire the issue-to-PR pipeline so a label starts the run and CI re-runs the gates independently.
5. Remove the merge and deploy steps for low-risk classes only. Follow intent to production and keep human approval for everything else.

Where does each tool start an unattended run?

Claude Code

In a session: /goal and /loop. From a script or CI: claude -p with --output-format json and a spending cap, --max-budget-usd (print mode only). claude --bg starts a background session that claude agents (agent view, research preview) lists and claude logs or claude attach follows. Routines (/schedule, research preview) run on Anthropic’s infrastructure. For code that branches on results, use the Claude Agent SDK. Checked against Claude Code 2.1.283 (the latest channel, 2026-09-26).

Codex

In a session: /goal (the goals feature is stable and on by default). Codex has no /loop (not in the 0.162.1 slash-command enum, binary strings or the developer-commands reference, checked 2026-10-12). From a script or CI: codex exec, with --output-schema for a typed result and --ephemeral to run without persisting session files. Scheduled work runs as Codex automations; code-driven runs use the Codex SDK. Checked against Codex CLI 0.157.1.

Cursor

Cloud Agents and Automations run in isolated cloud VMs. Cursor’s docs list Scheduled, Source control, Slack, Webhook, Linear, Sentry and PagerDuty triggers (checked 2026-10-12). /goal is still documented as rolling out (checked 2026-10-12), and /loop ships as a bundled skill. Scripts use the CLI’s print mode (-p) or the Cursor SDK.

Prompts to start automating this week

Copy-paste prompt: is this repository ready for unattended runs?

Audit this repository for unattended agent runs. Do not change any files.
Report, with the exact command or file path for each:
1. The single command that proves a change is done (tests, type check, lint).
   Run it and report its duration and whether it passes on a clean checkout.
2. Tests that failed or were retried in the last 20 CI runs, if CI history is visible.
3. Secrets or credentials a run would need, and whether any are readable from the repo.
4. Directories an agent must never edit (migrations, generated code, infra).
Finish with a verdict: READY, READY WITH LIMITS (name them), or NOT READY
(list the three fixes that would change that).

Copy-paste prompt: a goal with a finish line a checker can verify

/goal Migrate every handler in src/api/ from the callback signature to async/await.
Done when: npm test and npm run typecheck both exit 0, and
`grep -rn "function (req, res, next)" src/api` returns no matches.
Do not edit tests to make them pass, do not touch src/api/legacy/,
and stop and report if the same failure occurs twice.

How do you trust work nobody watched?

You read evidence, not the diff:

• Gates the agent cannot edit. CI re-runs tests, types, lint and security scans on the pushed branch, whatever the agent claims.
• An evidence bundle on every PR. The evidence bundle lists what was run, what changed and what was not checked; see reading evidence instead of code.
• Budgets and caps. A dollar or turn cap per run, and a fix loop capped at a small number of attempts.
• A trace of what the agent did. Agent observability ties tool calls and cost to each PR.
• A named human merge, until a risk class has earned auto-merge.

What breaks when agents run unattended?

Failure modes and how to recover

• The agent weakens the check. It deletes a failing test or loosens an assertion to reach “done”. Recovery: protect test and config paths in the prompt and in CI, and fail the build when test count drops.
• A run that never ends. A vague condition keeps spending. Recovery: state the finish line as a command, set a budget, and tell the agent to stop on a repeated failure.
• Too much access. A run holds credentials or full access it never needed. Recovery: revoke the token, use least-privilege scopes, and keep bypass modes such as --dangerously-skip-permissions for disposable, network-restricted sandboxes only.
• Parallel runs collide. Several agents edit the same file. Recovery: give each run its own module and worktree, and follow the orchestration patterns.
• Green checks, wrong behaviour. Weak tests pass bad code. Recovery: add acceptance tests from the spec before widening automation.

Where to go next with automation

No machine-checkable definition of done yet? Begin at Level 4. Otherwise, start with /goal today, then build the issue-to-PR pipeline. Level 5: you run the software factory describes where this section leads.

From issue to pull request with no hands on the keyboard