How to run Claude on autopilot in 14 steps: /loop, Routines, and the full automation stack.

You’re paying $20–$200/month for Claude and using it like a paid version of ChatGPT. 9 out of 10 users have never set up automation that runs without them clicking buttons.

No /loop, no scheduled tasks, no Routines, no triggers. The tool that’s supposed to work while you sleep is still waiting for you to type. This is the 14-step roadmap to the full automation stack - and the hours back in your week.

Follow my Substack to get fresh AI alpha: movez.substack.com

Claude Code has been quietly shipping an entire automation stack over the last three months. /loop launched.

Auto Mode landed March 24. Cloud Routines opened in research preview April 14. By May 2026, the picture is complete: three layers of automation that go from your terminal to Anthropic’s cloud, each one earning its place by removing a different reason for you to babysit.

This is the 14-step roadmap to all three layers - every detail verified against the official docs at code.claude.com/docs as of June 2026. The arc is simple: get the manual loop right, make it persist across restarts, push it to the cloud where your laptop doesn’t matter.

14 steps. 3 tiers. One Claude that works while you sleep.

01. The /loop command. Explicit and natural language, both work.

The fastest way to make Claude Code do anything on a schedule. Inside any session, run /loop <interval> <prompt>.

Under the hood it calls three native tools: CronCreate, CronList, CronDelete. The intervals use a number plus unit: m for minutes, h for hours, d for days. The minimum is 1 minute - 30s rounds up.

> /loop 1m say hello

▲ Claude
  CronCreate(*/1 * * * * : say hello)
✓ Scheduled c21d95a0 (Every minute)
  - Job: say hello
  - Cadence: Every 1 minute (*/1 * * * *)
  - Job ID: c21d95a0
  - Duration: Recurring tasks auto-expire after 7 days
  - Cancel anytime: CronDelete c21d95a0

You don’t actually need to type /loop at all. Claude understands natural language schedules just as well:

every 10 minutes, check the deployment status

every weekday at 7am, summarize the overnight commits

at 6:30pm today, post a status update to Slack

Times use the local machine’s time zone, not UTC. Any slash command available in Claude Code can be placed inside a /loop - including /run, /review, even another /loop if you’re feeling adventurous.

02. Real cron expressions for real schedules.

The CronCreate tool accepts standard 5-field cron expressions: minute hour day-of-month month day-of-week. All fields support wildcards (*), single values (5), steps (*/15), ranges (1-5), and comma-separated lists (1,15,30). Day-of-week uses 0 or 7 for Sunday through 6 for Saturday.

What is NOT supported: extended syntax like L (last day), W (weekday), ?, or name aliases like MON or JAN. When both day-of-month and day-of-week are constrained, a date matches if either field matches - standard vixie-cron semantics.

Cron patterns worth memorizing:

# Cron patterns that earn their keep

# every 5 minutes (only during business hours)
*/5 9-17 * * 1-5

# every weekday at 7am
0 7 * * 1-5

# first day of the month at 9am
0 9 1 * *

# every 15 minutes
*/15 * * * *

# nightly at 2:30am
30 2 * * *

# every Friday at 4pm
0 16 * * 5

# every 6 hours, on the hour
0 */6 * * *

03. Auto-expire and stop conditions

Four hard constraints that decide whether /loop is the right tool for the job. Memorize them or burn time figuring them out later:

7-day auto-expire. Every recurring task auto-deletes 7 days after creation. The task fires one final time, then removes itself. This bounds how long a forgotten loop can run. If you need it to live longer, cancel and recreate before the deadline - or use Routines (step 10).

50 tasks max per session. Plenty for individual workflows. If you’re building something more elaborate, count your tasks; you won’t get a warning until you hit the wall.

No catch-up firing. If a task is due while Claude is busy on a long-running request, it fires once when Claude becomes idle, not once per missed interval. A 5-minute loop that hits during a 20-minute refactor produces one fire after, not four.

Session-scoped. Closing the terminal cancels everything. Restarting Claude Code clears all scheduled tasks. There is no persistence across sessions - that’s what Tier 2 and Tier 3 are for.

To list and cancel tasks mid-session, just ask in natural language - Claude routes to CronList and CronDelete:

> show running cron jobs

▲ CronList()
   ID         JOB                       CADENCE
   c21d95a0   say hello                 Every 1 minute
   8f3aa412   check deploy status       Every 10 minutes
   bb7c0d91   morning summary           0 7 * * 1-5

> kill the deploy status check

▲ CronDelete(8f3aa412)
✓ Cancelled. 2 jobs remaining.

For CI environments or shared servers where background scheduling is undesirable, set CLAUDE_CODE_DISABLE_CRON=1 in your environment. The cron tools and /loop become unavailable, and any already-scheduled tasks stop firing.

This is the right move for any environment where the user who runs Claude isn’t the user who owns the schedule.

04. Pair /loop with /goal

A /loop on its own asks Claude to do something repeatedly. A /loop paired with /goal asks Claude to do something repeatedly until a specific condition is met - and to keep looping past intermediate “done enough” declarations.

This pairing solves agentic laziness inside a recurring task. Without /goal, a loop might address 20 of the 50 items it’s meant to handle and call the rest “handled.” With /goal, the stop condition is explicit and enforced:

A /loop on its own asks Claude to do something repeatedly. 
A /loop paired with /goal asks Claude to do something repeatedly until a specific condition is met — and to keep looping past intermediate “done enough” declarations.

This pairing solves agentic laziness inside a recurring task.
Without /goal, a loop might address 20 of the 50 items it’s meant to handle and call the rest “handled.” With /goal, the stop condition is explicit and enforced:

The three patterns where this pairing earns its keep:

Flaky test debugging. Reproduce, form theories, test them, until one holds.

Long-running migrations. Process items, save progress, continue until the queue is empty.

Inbox-style triage. Process pending items, continue until nothing new arrives in a full cycle.

Four steps and you have a working manual loop. Now make it survive a restart.

05. Desktop scheduled tasks.

The Claude Desktop app has its own scheduler, separate from the CLI’s /loop. Create scheduled tasks from Schedule → New task → New local task.

You define a name, prompt, frequency, permissions, and working folder. Each fire starts a fresh Claude Code session - no shared context with anything else.

What this layer gives you that /loop doesn’t:

Survives restarts. Reboot your machine, close all terminals - tasks still fire when their time comes.

Fresh context each fire. No accumulated state from previous runs. Each task is essentially independent.

Pre-configured permissions. Allowed tools, working folder, model, all locked in per-task.

What it still requires: your machine has to be awake. If your laptop is asleep when a task is due, the run is skipped. When the machine wakes or you reopen Claude Desktop, it checks the last 7 days for missed runs, starts one catch-up run for the most recently missed time, and shows a notification.

To prevent idle-sleep, enable Keep computer awake in Desktop Settings under General. Closing the laptop lid still triggers sleep.

Desktop scheduled tasks are macOS and Windows only. Linux users have two options: (1) use the CLI’s /loop for session-scoped scheduling, or (2) set up system cron jobs running claude -p <prompt> in headless mode for persistent scheduling. Routines (step 10) work everywhere because they run in the cloud.

06. Token budgets and rate limits.

The single biggest surprise on a Pro plan: every scheduled fire starts a full Claude Code session, and each session counts toward your usage limits. A 5-minute loop running for 24 hours is 288 sessions.

They’re not tiny - each one loads context, calls tools, possibly invokes subagents. Factor this in before you set up anything ambitious.

Three habits that keep automation affordable:

Set explicit token budgets in the prompt. “Use at most 5k tokens. If you can’t complete in that budget, save partial progress and exit cleanly.” This caps each fire individually.

Match the model to the task. Don’t default to Opus for everything. Most automation runs well on Sonnet. Cheap exploration runs on Haiku. The model picker inside the task config defaults to whatever the panel default is - not what your interactive sessions use. Set it explicitly per task.

Pick the right plan for the volume. Pro plan tightens fast under heavy automation. Max gives 5× the headroom; Team and Enterprise more. If you’re shipping real automation, the upgrade pays for itself in not getting rate-limited at 3pm Tuesday.

07. Configure permissions for unattended runs.

By default, Claude Code asks for approval before running any bash command, writing any file, or calling any external API.

That’s fine when you’re watching. It’s a disaster when no one is. Three configuration patterns turn the default into something that can actually run unattended:

Pre-approve specific tools via settings.json - an allow list of safe commands and a deny list of forbidden ones.

Use .claudeignore at the project root to block access to credentials, environment files, and sensitive directories before any unattended task touches them.

Enable audit logging to record every autonomous action. Read it the next morning instead of trusting the run blind.

{
  "permissions": {
    "autoApprove": [
      "Read(*)",
      "Grep(*)",
      "Bash(npm test)",
      "Bash(pytest)",
      "Bash(git status)",
      "Bash(git diff*)",
      "Bash(git log*)",
      "WebFetch(domain:docs.python.org)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push*)",
      "Bash(*--force*)",
      "Bash(curl*)",
      "Edit(.env*)",
      "Edit(secrets/*)"
    ]
  },
  "auditLog": true
}

The right test for what to auto-approve: if this turns out wrong, what does it cost to undo? Cheap to undo (a comment on a draft PR) - auto-approve. Expensive to undo (a force-push to main) - never.

The middle ground (creating a branch, opening a PR) is fine to auto-approve if you also have audit logs you actually read.

08. Auto Mode - AI-classified permissions

Auto Mode is the alternative to --dangerously-skip-permissions. Instead of blanket approval, an AI classifier evaluates each tool call against the active permission policy and decides whether to auto-approve, prompt, or block.

Anthropic measured that users approve 93% of permission prompts; Auto Mode automates the 93% and keeps the human in the loop for the 7%.

How it works in practice:

Three tiers. Permissive, Balanced, Restrictive. Pick the one that matches your risk tolerance for the project.

Two layers of defense. A server-side prompt-injection probe scans tool outputs before they enter Claude’s context. Then a classifier evaluates each proposed action.

Audit trail. Every autonomous decision is logged. You can review what was approved and why after the fact.

Plan availability as of May 2026: Max, Team, Enterprise, and API plans (through the Anthropic API). Not currently available on Pro, Bedrock, Vertex, or Foundry.

Check code.claude.com/docs/en/auto-mode before planning around it. Once enabled, Auto Mode joins the Shift+Tab mode cycle alongside Accept Edits and Plan.

Auto Mode is still in research preview. The classifier’s decision logic is being refined and behavior may change between releases.

Pair it with .claudeignore and audit logs - Anthropic strongly recommends both. Don’t use it on shared team environments without additional safeguards.

09. Pick the right scheduler for the job.

Three schedulers, easy to confuse. The decision rule is one question: where does this need to run, and who needs to be awake for it?

The compounding pattern: start with /loop in a session to find what works, then promote to Desktop tasks for daily use, then promote to Routines when you want it running independent of your hardware.

Each tier earns its place by removing a different reason for you to be there.

10. Cloud Routines.

Released April 14, 2026 in research preview. Routines are saved Claude Code configurations - a prompt, repositories, connectors, permissions - that run on Anthropic-managed cloud infrastructure on a trigger.

Your laptop can be off. The run still happens.

Available on all paid plans (Pro, Max, Team, Enterprise). Create them at claude.ai/code/routines or with /schedule inside the CLI. The CLI creates schedule-triggered routines only; to add API or GitHub triggers, edit on the web.

What a routine actually contains:

A self-contained prompt. The routine runs autonomously with no follow-up questions, so anything ambiguous becomes a coin flip on every run. Spell out what to do, what success looks like, where to send the result.

One or more repositories. Cloned at the start of each run.

Connectors. Slack, Linear, Drive, GitHub, anything you have wired up.

An environment. Controls network access and secrets. Default is Trusted - allows package registries but not arbitrary outbound calls.

One or more triggers. Schedule, API, GitHub event, or any combination.

By default, routines can only push to branches prefixed claude/. A poorly written routine cannot accidentally push to main. Disable this only if you have a downstream review process you actually trust. The default exists for a reason.

11. Schedule-triggered Routines

The most common trigger and the one to start with. Set a cadence - hourly, daily, weekdays, weekly, or a one-shot future time - and walk away.

> /schedule weekdays at 7am
  Goal: pull yesterday’s GitHub issues, classify by severity,
  draft fixes for any "P0" or "P1," open draft PRs for review.
  Post a digest summary to #engineering on Slack.

▲ Claude
  Creating routine: morning-briefing
  - trigger: schedule (0 7 * * 1-5)
  - repositories: org/api, org/web
  - connectors: github, slack
  - environment: Trusted
✓ Active · first run Monday 07:00 local time.
  View at claude.ai/code/routines

Three patterns that pay for themselves fast:

Morning briefing. Pull yesterday’s metrics and incidents, summarize new GitHub issues, post a digest to Slack. By 8am you know what happened overnight, without you opening anything.

PR review pass. Every weekday at 9am, scan open PRs assigned to you, leave a first-pass review comment with security and style flags. Human review starts pre-cleaned.

Documentation drift detection. Weekly, scan code changes and flag any docs that haven’t been updated alongside them. Open a draft PR with the corrections.

Times are in your local zone and converted automatically. Runs may start a few minutes after the scheduled time due to stagger - consistent per routine.

12. API-triggered Routines

An API trigger gives a routine a unique HTTP endpoint and a bearer token. POST to it from anywhere - alerting systems, deploy pipelines, monitoring tools, your own apps - and the routine runs. Optional JSON body becomes one-shot context appended to the routine’s prompt.

# Fire a routine from anywhere with HTTP access
curl -X POST https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

# Response includes claude_code_session_id + URL to watch live

Two operational details that matter:

The token is shown only once at creation. Store it immediately in a secret store - you can’t retrieve it later.

Watch the beta header. The /fire endpoint ships under experimental-cc-routine-2026-04-01. Request and response shapes may change during preview. Anthropic guarantees the two most recent header versions keep working - migrate during the deprecation window.

What this trigger pattern actually unlocks: Claude becomes a callable workflow from any system in your stack.

CI fails → fire a routine to investigate and open a fix PR. PagerDuty alert → fire a routine to triage and post initial context.

Stripe webhook → fire a routine to update an internal dashboard.

13. GitHub-triggered Routines.

The GitHub trigger hooks a routine into the Claude GitHub App webhook. Supported events are broad: pull request, push, issue, check run, workflow run, discussion, release, merge queue.

Each matching event starts an independent session - no session reuse across events.

Where this trigger earns its place:

PR open events → routine runs a code review pass, flags security and style issues, leaves a first-pass comment. Authors get pre-review feedback before human reviewers arrive.

Issue create events → routine triages new issues, applies labels, links related code, drafts a first response. Backlog stays clean without anyone managing it manually.

Workflow run events → routine investigates CI failures, identifies likely root causes, opens a draft fix PR. Failed builds stop being a manual chore.

Release events → routine drafts release notes, posts to the changelog, notifies stakeholders. No more “who’s writing the changelog this sprint.”

Pull request filters let you scope precisely: author, title, body, base branch, head branch, labels, draft state, merged state, from-fork.

A routine that only fires on PRs labeled needs-security-review against main is one filter set away.

14. Compose with Skills and Dynamic Workflows.

The last step closes the loop with everything Claude Code shipped before. Each layer of automation gets more powerful when you pair it with the rest of the stack.

Skills inside Routines. A Skill is a reusable instruction file. Drop your “PR review” or “morning briefing” Skill into ~/.claude/skills/, then point the routine prompt at it: “Use the morning-briefing skill.” The skill is your reusable recipe; the routine is the trigger that runs it.

Dynamic Workflows inside Routines. For complex automation that benefits from parallel subagents - deep verification, tournaments, fan-out research - have the routine prompt invoke a workflow. Routines provide the scheduling; workflows provide the structure.

Routines triggered by other Routines. One routine’s output (a PR open, a Slack message, a label change) can be the trigger for another routine. The composition isn’t a feature you toggle - it’s a pattern you set up by pointing one routine’s output at another’s trigger.

Permissions per routine, not global. Each routine carries its own permission configuration. The morning-briefing routine reads everywhere but can’t push. The auto-fix routine pushes only to claude/ branches. The security-scan routine has the deny list maximized. Treat each routine’s permission file as part of its security boundary.

The whole stack at peak looks like this: Skills as your recipes, Dynamic Workflows as the orchestration, Routines as the trigger layer, Auto Mode as the permission classifier, Audit logs as your morning review. Every step in this article configures one slice of that stack.

You don’t need all of it on day one. Start with /loop. Promote to Desktop. Promote to Routines. Pair with Skills. Add Workflows when complexity demands it.

The habits that waste money on Claude automation

Never trying /loop in the first place. The easiest tier of automation costs nothing and you’ve been ignoring it for three months.

Forgetting the 7-day auto-expire. Set up a critical loop, walk away, wonder a week later why nothing happened.

Using /loop for tasks that should outlast your terminal. The whole point of Tier 2 and 3 is exactly this case — promote it.

Letting Automations default the model. Opus on every fire when Sonnet would do the same job for less. Check the model picker per task.

No /goal on loops that should run until done. The loop stops at “handled enough” instead of the actual stop condition.

Blanket approval via --dangerously-skip-permissions. One bad prompt away from a git push --force origin main. Use Auto Mode or an allow list.

Vague routine prompts. A routine runs autonomously with no follow-up. Ambiguous prompts produce coin-flip behavior on every fire.

No audit logs. “Trust the automation” without reviewing what it did is how silent failures become loud incidents.

Disabling the claude/ branch prefix. The default exists for a reason. Don’t turn it off until your downstream review process is actually solid.

Running automations on Pro. Heavy automation hits rate limits fast. If you’re shipping real workflows, the Max upgrade pays for itself in not getting blocked.

Conclusion:

Claude does not stop working when you stop typing.

The automation stack has been shipping in pieces for three months. /loop in March. Auto Mode two weeks later. Routines in April. The whole thing is live, documented, and available on plans you’re already paying for.

The only thing standing between “Claude as expensive chatbot” and “Claude as workforce” is fourteen steps of configuration.

Most users will keep typing prompts manually and stop there. That’s fine for casual use and bad at everything else. The 1% running real automation have Claude triaging issues at 7am, refreshing dashboards every hour, drafting Slack replies every 10 minutes - all while they sleep. They’ve set up the manual loop, promoted it to Desktop, promoted that to Routines.

Pick one step you weren’t doing - probably your first /loop in the terminal - and add it tomorrow. Then the next. The output of Claude follows the configuration of Claude. Configure it for autopilot, and that’s what you get.