The inner loop in Cursor is already running. Agent reads, edits, shells, and tests until the task completes — that is a coding agent harness doing loop engineering on every prompt. The question this guide answers is the next one: how do you put a standing agent loop around that inner loop so you are not the person who has to type the next prompt.
This is the Cursor how-to for the loop-engineering hub. The definition lives in what loop engineering is; the catalog and course are at /loops and Introduction to Loop Engineering. Sister setup posts cover Claude Code, GitHub Copilot, and Codex CLI.
The split that matters in Cursor is simple: local /loop dies when you close the laptop. Automations persist.
TL;DR
| Question | Direct answer |
|---|---|
| What already loops? | Editor Agent — tool calls (read / edit / terminal / test) until the task completes. No documented cap on tool calls. Plan Mode for big work. |
| What repeats a prompt on a timer? | Built-in /loop skill: /loop [interval] <prompt>. Official product skill, not a community gist. |
Does /loop survive sleep? | Local: no. Cloud Agent: yes, via Cursor's subscription timer — local sleep does not work in cloud. |
| What survives closing the laptop? | Automations — Cloud Agents on a schedule or GitHub / GitLab / Slack / Linear / webhook / PagerDuty. |
| How do I create one from chat? | /automate — describe the workflow in plain language; Cursor configures triggers and tools. |
| Where do cloud hooks live? | .cursor/hooks.json in the repo. ~/.cursor/hooks.json does not exist on the VM. |
| Unofficial? | --max-turns, 20s ticks, state.md as CLI flags — community patterns. Point persistence at Automations. |
The three Cursor loops (and which one you actually want)
Cursor exposes three different clocks. Mixing them up is why people think /loop is "always on" and then wonder why nothing ran overnight.
| Layer | Where it runs | Survives laptop closed? | Start it with |
|---|---|---|---|
| Agent inner loop | Your editor (or CLI agent) session | No | A normal prompt, or /goal for a long-lived objective |
/loop skill | Same session locally; Cloud Agent uses a server timer | Local no / cloud yes (that agent) | /loop 5m check the deploy |
| Automations | Cursor-managed Cloud Agent VMs | Yes | /automate, cursor.com/automations, or the Agents Window |
The inner loop is the agent harness: instructions, tools, model. Official Agent docs: there is no limit on the number of tool calls during a task. That is the observe-act-check cycle on one job. /loop is the outer clock that re-prompts that harness. Automations are the outer clock that does not live on your machine.
For the craft of trigger / goal / verification / memory — independent of Cursor — see how to turn skills into loops and the loop-engineering hub.
Step 1: Close the inner loop (Agent + Plan Mode)
Before you schedule anything, make one Agent run able to finish without you. Cursor's own Cloud Agent docs put this bluntly: an agent that can write code but cannot run tests, query services, or reach APIs cannot close the loop.
Copy-paste — editor Agent
Implement the failing tests in apps/web for the billing page.
Do not stop on the first green file. Re-run the targeted test command
until it passes or you have a concrete blocker. Then summarize:
what changed, what you ran, what is still red.
For a large change, switch to Plan Mode first (/plan, Shift+Tab, or --mode=plan in CLI). Cursor's Plan Mode workflow is: questions → codebase research → reviewable plan → you approve → Agent builds. That is cheaper than looping a vague prompt.
Copy-paste — long-lived objective
/goal fix all flaky tests and make CI green
/goal is rolling out in Agent (docs: if you do not see it, try a new chat). Cursor's Agent overview says to pair a goal with a Custom Mode playbook, or with the built-in /loop skill for recurring check-ins while the objective is still open.
CLI equivalent: install from cursor.com/docs/cli, then agent for an interactive session. Prepend & to a message to hand the conversation to a Cloud Agent so it continues while you are away. Slash-command map: Cursor CLI slash commands.
Step 2: Run /loop (official Cursor skill)
/loop is a built-in Cursor skill, listed next to /automate and /babysit in Cursor's skills docs: runs a prompt or skill repeatedly at a specified interval. The grammar comes from Cursor's own loop skill, not from a Medium recap.
Parse (product skill): /loop [interval] <prompt>
| You type | What it means |
|---|---|
/loop 5m /foo | Every 5 minutes, run skill /foo |
/loop 30s check status | Leading interval |
/loop 2h run report | Hours |
/loop check deploy every 5m | Trailing interval |
/loop check the queue | No interval = dynamic mode — the agent chooses the delay and may change it tick to tick |
/loop with an empty prompt | Usage: /loop [interval] <prompt> |
Use intervals like 30s, 5m, 2h, 1d. Cron-style phrases ("every weekday at 9am") belong on the cloud timer path, not as undocumented CLI flags.
Copy-paste — babysit a PR locally
/loop 5m check this PR: failing CI, review comments, merge conflicts.
Fix what you can. If nothing changed, say so in one line and wait for the next tick.
Stop when CI is green and there are no unresolved review threads.
Local /loop dies with the session
On a local IDE or CLI session, Cursor's loop skill wakes the agent with a monitored shell: while true; sleep; echo AGENT_LOOP_TICK_.... That process is attached to the session. Close Cursor, sleep the laptop, or kill the terminal and the ticks stop. That is not a bug in your prompt. It is the local mechanism.
Do not try to "fix" local /loop with OS cron unless you are deliberately leaving a machine on. If the work has to run at 3am, you want Automations (next section), not a sleep loop on your MacBook.
Cloud /loop uses a subscription timer, not sleep
If you are already in a Cloud Agent, local sleep loops do not work. Cursor's loop skill switches to the cursor-subscriptions timer MCP (subscribe_timer) with either delaySeconds or a cron expression. The first prompt runs immediately so the first server tick is not a cold start. The server keeps firing until you unsubscribe or the timer expires.
Changing a live cloud timer: subscribe_timer does not update in place. Re-arming the same timer name is a silent no-op — the new delay/prompt/cron are dropped and the old config stays. Unsubscribe first, then subscribe again with the new values.
That cloud /loop still belongs to that agent run. It is not a team-wide Automation. For always-on, event-driven, or "runs whether I am logged in" work, use Automations.
What not to copy from community CLI posts
Some write-ups invent Cursor CLI flags such as --max-turns, a hardcoded 20-second tick, or a required state.md. We could not verify those on cursor.com/docs or in cursor --help (this environment: Cursor 3.16.29; cursor-agent was too stale to dump extra flags). Treat them as community CLI loop patterns. If you want a max-iteration or budget stop, write it in the prompt or in a repo file — and put the persistent job on Automations.
Step 3: Make Cloud Agents able to close the loop
Cloud Agents use the same Agent fundamentals on isolated VMs: clone, deps, secrets, startup commands, network. Cursor's line: not setting up the environment is like not giving engineers a computer. Environment setup is the loop closer.
Copy-paste checklist (do this before you schedule anything)
- Admin connects GitHub, GitLab, Bitbucket, or Azure DevOps.
- Paid Cursor plan (docs: runs will not start otherwise).
- Configure the environment (agent-led setup, snapshot, or Dockerfile via
.cursor/environment.json) so tests and APIs actually run. - Put secrets in the Cloud Agents dashboard — not only in your laptop
.env. - Commit
.cursor/hooks.jsonin the repo for formatters, audit, and policy. User-level~/.cursor/hooks.jsonis not available on the VM.
Kick off Cloud Agents from the desktop Cloud dropdown, cursor.com/agents, iOS, Slack @cursor, GitHub/Bitbucket comments, Linear, or the API. Event-driven subscriptions and isolated subagent VMs (August 2026) are covered in Cursor's event-driven cloud agents.
CLI handoff (verified in Cursor CLI docs):
# In an interactive `agent` session, prepend & to send work to a Cloud Agent
& refactor the auth module and add comprehensive tests
Step 4: Persist with Automations (/automate)
Cursor Automations run Cloud Agents in the background on a schedule or on events. Create them at cursor.com/automations, in the Agents Window, from a Marketplace template, or with the /automate skill from a local Agent session.
/automate is the built-in skill that takes a plain-language workflow and configures triggers, instructions, and tools. You still pick: trigger, prompt, optional tools (Slack, PR comment, MCP), and whether the run needs a repo, many repos, or none.
Copy-paste — /automate kickoff
/automate
When a pull request is opened or new commits are pushed, review the diff
for bugs that tests would miss. Comment on the PR with findings.
Open a follow-up PR only if you can add a failing regression test and
make it pass. If the diff is docs-only, do nothing.
Copy-paste — daily chore (then create the Automation in the UI)
Every weekday at 09:00, summarize merged PRs from the last 24 hours
and post to the eng Slack channel. Highlight breakages, skipped tests,
and security-relevant dependency bumps. Do not open a PR unless I
explicitly ask in a later version of this automation.
Official trigger families (from Cursor Automations docs): scheduled (presets or cron), source control (GitHub, GitLab, Bitbucket Cloud — PR opened/pushed/merged, push to branch, comments; GitHub adds labels, CI completed, workflow runs), Slack, webhooks, Linear, Sentry, PagerDuty. Slack/cron default to no repository unless you attach one — if the agent should change code, specify the repo.
Cursor's product post on Automations is the same factory idea: always-on review, chores, and incident triage powered by Cloud Agents that can build, test, and demo. Memories can persist across runs for one automation (MEMORIES.md by default) — treat untrusted input as a poisoning risk.
Cursor-managed cousins on the Automations page: Bugbot, Security Agents, PR Routing & Approval. Those are productized loops, not replacements for a custom /automate workflow.
What this means for what you build or pay
Build: Put verification in the environment, not in the prompt. A local /loop that "checks CI" while your laptop is closed is a no-op. An Automation whose VM cannot run the test suite will rubber-stamp. Repo hooks, secrets, and a real test command are the product. If you only needed a one-shot Agent run, do not pay for an always-on Automation.
Pay: Cloud Agents (and therefore Automations) bill at API pricing for the selected model. First use asks for a spend limit. Automations use each model's maximum context window — there is no context-window toggle — so a chatty prompt on a large repo is not a "background discount." Team Owned automations bill the team pool under a shared service account; Private and Team Visible bill the creator. Local Agent and local /loop consume whatever your Cursor plan already meters for in-session Agent. Cloud is the extra line item.
Choose: Inner loop for the task in front of you. /loop for check-ins while you keep the session (or Cloud Agent) alive. Automations for anything that must fire on a PR, a Slack thread, or a clock after you shut the lid. Head-to-head with other harnesses: Claude Code vs Cursor vs GitHub Copilot.
Honest limitations
- Local
/loopis not cron. It is a session-attached wake. Do not design on-call around it. - Cloud
/loop≠ Automation. A subscription timer on one Cloud Agent is not a team-owned, event-triggered factory. Use/automatefor that. - Silent no-op on timer updates. Changing a live cloud loop without unsubscribe looks like it worked and does nothing.
- Fork PRs. Automations docs: most pull-request triggers do not run on PRs from forks ("Fork pull requests not supported"). Merge-commit triggers are the exception.
- Paid plan + SCM. Cloud Agents will not start without both.
- Community CLI flags. Do not paste
--max-turnsinto a runbook as if Cursor shipped it.
Related reading
This series
- How to run loops in Claude Code
- How to run loops in GitHub Copilot
- How to run loops in Codex CLI
- Claude Code vs Cursor vs GitHub Copilot (2026)
Loop engineering on explainx.ai
- Loop engineering hub
- What is loop engineering?
- How to turn agent skills into loops
- Cursor CLI slash commands
- Cursor event-driven cloud agents (August 2026)
- Loops directory · Loop engineering course
Official Cursor
- Cloud Agents
- Automations
- Automations product post
- Built-in skills (
/loop,/automate) - Agent overview
- Cursor CLI
Cursor product behavior, skill grammar, and billing notes in this guide are accurate as of August 20, 2026. Re-check cursor.com/docs and cursor --help before you freeze a team runbook — especially /goal rollout and Cloud Agent plan gates.