Chapter 24: Claude on Autopilot#

For months, the first thing I read every morning was a briefing nobody wrote that morning. My calendar for the day, yesterday’s unfinished to-dos, anything that came in overnight, deadlines coming up this week, all compiled into one file, sitting in my briefing folder, stamped 7:30 AM. I was usually asleep at 7:30. Claude wrote it anyway.

That is the trick this chapter teaches: running Claude Code without you in the chat. Everything in this book so far has been a conversation you start. This is the far edge, where the conversation starts itself, on a schedule, does one well-defined job, saves the output where you will find it, and exits. No chat window. No you.

Two ideas make it work. First, Claude Code can run from a single command instead of a conversation. Second, something has to fire that command on a clock, and you now have three options for that, from one-click to fully do-it-yourself. We will take them in order.

The one flag that changes everything#

Claude Code has a mode where it does not open a chat. You hand it the prompt up front, it does the work, prints the result, and exits. The flag is -p.

In your terminal, from your project folder:

claude -p "List every file in this folder modified in the last 7 days and summarize what changed."

No session, no back and forth. One question in, one answer out. This is called running Claude “headless” or “programmatically,” and it is the same Claude Code you have used all book, with the same brain and the same tools.

The part that makes it powerful for our purposes: when you run this from a project folder, everything you have built in this book comes along. Your CLAUDE.md loads. Your skills load. Your connectors load. Which means your skills work here too:

In your terminal, from your project folder:

claude -p "/daily-briefing"

That one line runs your entire daily briefing skill, exactly as if you had typed /daily-briefing into a chat, except no chat ever opens. Sit with that for a second. Every skill you have written is now a command your computer can run without you.

(There is also a stripped-down fast mode, --bare, that deliberately loads none of your setup. It exists for scripts that need a blank slate. We want the opposite: the whole point here is that your setup comes along.)

Permissions when nobody is watching#

In a chat, Claude asks before it acts and you click yes. In headless mode there is nobody to click yes. So you pre-approve exactly the tools the job needs with --allowedTools:

In your terminal, from your project folder:

claude -p "/daily-briefing" --allowedTools "Read,Write,Bash,Grep,Glob,WebSearch"

That list is a leash, and the short leash is the point. If the task tries something outside the list, the run stops rather than proceeding without permission. Give an unattended job only what its skill actually uses, nothing more.

Run the full command by hand once in your terminal and watch it work end to end. That is your test flight. Only schedule something you have watched succeed manually, because after this point nobody is watching.

Three ways to put it on a clock#

A command that runs itself still needs an alarm clock. As of mid-2026 there are three, and picking the right one is mostly about answering two questions: does the job need your local files, and does it need to run when your laptop is closed?

The first two are called routines, and they are the productized version of everything this chapter hand-builds. The third is the manual original. Easiest first.

The easy way: a local routine#

If you use the Claude Code Desktop app, the entire launchd machinery below collapses into a form. Click Routines in the sidebar, then New routine, and choose Local. Four fields: a name, a one-line description, the instructions (this is just a prompt, and yes, your skills work in it), and a schedule. That is the whole setup.

Or skip the form entirely, because creating one is itself just a request:

As a prompt in any Desktop app session:

Set up a local routine that runs my /daily-briefing skill every weekday
at 7:30 AM, working in this folder.

Local routines run on your machine, with full access to your folders and files, which is exactly what a briefing that reads your daily logs needs. Three behaviors worth knowing:

• Permissions are handled once. After creating a routine, click Run now and watch the first run. When permission prompts appear, choose “always allow.” Future runs approve the same tools automatically. A run that hits something unapproved stalls politely in the sidebar until you answer, it does not proceed without you.
• Sleep is forgiven. If your machine slept through the scheduled time, the app runs one catch-up when it wakes, so the 7:30 briefing is at worst waiting for you when you open the lid. Write prompts accordingly: a “morning” briefing might actually run at 2 PM, so say “today’s” rather than “this morning’s” in your instructions.
• It only fires while the app is open. No Desktop app running, no routine.

One lovely zero-setup example of what fits here: a weekday news brief. “Every weekday morning, search the web for the three most significant developments in [your industry] from the last 24 hours, skip funding news and opinion pieces, and write me a three-bullet briefing with why each matters.” No connectors, no accounts, no files. The briefing simply appears in the run log with your coffee.

The laptop-off way: a cloud routine#

A cloud routine is the same idea running on Anthropic’s computers instead of yours. Your laptop can be closed, off, or in a bag at the airport; the routine runs anyway. Create one at claude.ai/code/routines, in the Desktop app (choose Cloud instead of Local), or from inside Claude Code itself with the /schedule command, which walks you through it conversationally and can also list, update, and trigger your routines later.

The trade for laptop-off freedom is a different toolbox. A cloud routine cannot see your local folders, your local files, or the command-line tools on your machine. What it can use is your connectors: the Gmail, Google Calendar, Slack, Notion, Drive and other services connected to your claude.ai account. Everything it does through them happens as you, from your accounts, so drafts appear in your Gmail and messages post as your Slack.

Two configuration notes that save real confusion:

• A repository is optional. The setup form offers to attach a GitHub repository, and tutorials often treat it as required. It is not. Attach one only when the job involves code, or when you want a scratchpad that persists between runs, because every cloud run starts from a blank slate. A useful pattern for the second case: keep a small file like clients.txt in an otherwise empty repository, tell the routine to read it, and update the file instead of the prompt when your list changes.
• Trim the connectors. Every connector on your account is attached by default, and cloud routines run fully autonomously, with no permission prompts at all. The connector list is the only leash. Remove everything the routine does not need.

What are people actually running this way? The patterns showing up in the wild map almost perfectly onto knowledge work:

Inbox triage before you wake. A routine on a 5 AM schedule reads unread emails through the Gmail connector, checks earlier threads with each sender for context, writes reply drafts (drafts, never sends), and posts a one-screen summary to Slack. You wake up to a triaged inbox where the replies are already 80 percent written.

Meeting prep, delivered. A daily routine pulls tomorrow’s calendar, skips personal events, researches the companies and external attendees for the rest, and sends one short prep note per meeting to Slack. If there are no meetings, it sends nothing, which is a prompt discipline worth copying: tell a routine explicitly when to stay silent.

The instant lead response. This one uses the third trigger type: alongside schedules, every cloud routine can have an API trigger, a private web address that fires the routine when anything sends a request to it. Wire a website contact form to it, and the moment a lead arrives the routine researches the company, scores the lead, logs it to a CRM with a short write-up, and drafts the reply email for your review. Work that took an hour of someone’s morning happens in the two minutes after the form is submitted. (There is a third trigger type as well, GitHub events, which fires on code activity; developers love it and you can ignore it.)

Notice what all three examples share: the routine drafts and a human sends. That is the pattern I would burn into your muscle memory before automating anything outward-facing. A routine acts as you, without asking first, so design it to prepare the action and stop. If you want a real approval step, use two routines: the first drafts and posts to Slack, you reply with a yes, and the second, fired through its API trigger, executes. The approval gate lives between two routines, not inside one.

The honest fine print for the cloud flavor: routines are in research preview, so details may shift. Scheduled cloud runs have a one-hour minimum interval and a daily cap on your plan, and they draw from the same usage as your normal sessions. And your command-line tools do not exist up there, so anything built on a local CLI needs its connector equivalent instead.

The DIY way: your own launch agent#

Before routines existed, there was one way to do all this, and it is still worth knowing: it has no interval floor, it needs no app running, it works on any Mac including one you never open the Desktop app on, and it teaches you exactly what the polished versions are doing under the hood.

macOS has a built-in system called launchd that starts programs at specified times. You give it a small configuration file called a launch agent, dropped into ~/Library/LaunchAgents, and your Mac takes over from there. Here is a complete, real one that runs the daily briefing skill at 7:30 every morning and logs every run:

A launch agent file, saved as ~/Library/LaunchAgents/com.yourname.daily-briefing.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.yourname.daily-briefing</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/zsh</string>
    <string>-lc</string>
    <string>cd "$HOME/Desktop/Work OS" && claude -p "/daily-briefing" --allowedTools "Read,Write,Bash,Grep,Glob,WebSearch"</string>
  </array>
  <key>StartCalendarInterval</key>
  <dict>
    <key>Hour</key><integer>7</integer>
    <key>Minute</key><integer>30</integer>
  </dict>
  <key>StandardOutPath</key>
  <string>/tmp/daily-briefing.log</string>
  <key>StandardErrorPath</key>
  <string>/tmp/daily-briefing.err</string>
</dict>
</plist>

Reading it top to bottom: a name, the command (go to my project folder, run my skill headless with these tools allowed), the schedule, and two log files so you can see what happened while you were not looking. Switch it on once with launchctl load and that path, and your Mac owns the schedule from then on. For “every four hours,” swap the calendar block for StartInterval with a number of seconds; for “Tuesdays at 8,” add a Weekday key. Pause it anytime with launchctl unload.

And the honest confession about how you actually create these files: you do not write them. You are holding a book about not writing things like this.

As a Claude prompt:

Set up a macOS launch agent that runs my /daily-briefing skill headless
every morning at 7:30, with only the tools that skill needs pre-approved,
logging each run to a file. Create the file, load it, and explain what you
did in plain English.

I showed you the file so it is not magic, and so you can read your own automation and know what it says.

The three agents I ran#

To make this concrete, here is the autopilot fleet from my own Work OS, built the DIY way. Three scheduled agents, three different rhythms.

The morning briefing. Every day, 7:30 AM. The skill pulls the day’s calendar through a command-line tool, collects yesterday’s unchecked to-dos from my daily log, scans overnight messages, flags deadlines in the next seven days, and writes the whole thing to a briefing folder as one markdown file. My workday started by reading a document that was already waiting.

The meeting sweep. Every four hours. I record meetings with Granola. This agent checks for any meeting that has not been summarized yet, runs my meeting skill on each one, and files the summaries into my meetings folder. I never told it a meeting had happened. It found out, processed it, and filed it, four times a day, all day.

The competitive scan. Every Tuesday, 8:00 AM. Once a week, a skill sweeps the web for news about my competitive set using web search and research connectors, and saves a dated intelligence report into my competitive intel folder. Tuesday mornings started with fresh reconnaissance I never asked for that week.

If I were rebuilding this fleet today, the briefing would be a local routine in the Desktop app, the Tuesday scan would be a cloud routine (web research needs nothing from my machine), and the meeting sweep would stay local, because its whole job is filing summaries into my folders. Same three jobs, less machinery.

Notice the pattern in what got automated, whichever way you build it: all three jobs share a shape. Zero decisions needed from me, output is a file or a message, and a missed run hurts nothing. That is the test for whether something belongs on autopilot. Anything that needs your taste or your call stays a skill you run by hand.

Your sub-agents ride along too. A headless run loads everything in the folder, including the custom sub-agents from Chapter 11. That means a scheduled run is not limited to one worker: the Tuesday scan can dispatch three Haiku-powered scanner sub-agents in parallel, one per competitor, and compile their reports into the weekly file. Define a specialist once and it works everywhere: in your chats, and in runs that happen while you sleep.

This completes a ladder you have been climbing all book: a task you do once is a prompt. A task you repeat is a skill. A skill you run on a fixed rhythm is a routine. Prompt, skill, autopilot.

When something breaks#

Three moves, in escalating order of power.

Show it. Screenshot the problem, paste it to Claude, and say what you expected to happen instead. That one sentence fixes most things.

Read the run. Every scheduled run keeps a record. Local routines and cloud routines both leave a full session you can open and read like a transcript: every step, every tool call, every decision. One warning for cloud routines: a green checkmark means the run finished without crashing, not that the task succeeded. Open the transcript and confirm what actually happened. For a DIY launch agent, the log file plays the same role, and you can always run the exact command by hand and watch where it stops.

Let it query the service. The same idea extends to everything your automation touches. With the Vercel connection from Chapter 23, Claude reads deploy logs itself; with the Firebase CLI, it can look inside the database. When a connected service misbehaves, do not relay the error to Claude secondhand. Give Claude the connection and let it investigate firsthand.

The fine print#

• Local means local. Local routines and launch agents run on your machine and need it awake (both forgive sleep with a catch-up run; a machine that is off runs nothing). Cloud routines run regardless, but cannot touch your files.
• Everything acts as you. A routine that drafts email drafts from your Gmail; one that posts to Slack posts as you. Draft-do-not-send is the default posture for anything outward-facing, and remember the two-routine approval gate when you need a real yes-button.
• Usage is usage. Scheduled runs, local or cloud, draw from the same allowance as your chats, and cloud routines add a daily run cap. Keep scheduled prompts lean, the same token discipline you use everywhere else.
• Windows finally has a good answer. The Desktop app runs on Windows, so local routines work there exactly as described. The launch agent section is the Mac-only part; Windows has its own scheduler (Task Scheduler), which I have not run this setup on and will not pretend otherwise.
• Key and account safety. Nothing here needs your API keys pasted anywhere new, but the Chapter 23 rule stands: if a secret ever lands somewhere it should not, regenerate it. And prune connectors on any cloud routine to exactly what the job needs.

Where this leaves you#

There is a version of using Claude Code where you are always the trigger. You show up, you ask, it answers. Everything in this chapter is about retiring from the trigger job for the routines that never needed you. The briefing writes itself. The meetings file themselves. The intel arrives on Tuesdays. The inbox is triaged before you are awake.

Start with one, and start local: take the skill you already run on the most predictable rhythm, test it once with claude -p by hand, then ask the Desktop app to put it on the clock. Graduate it to a cloud routine the day you catch yourself leaving the laptop open just so it fires. The official documentation lives at code.claude.com/docs/en/headless, /desktop-scheduled-tasks, and /routines when you want to go deeper, and Chapter 11 (automation) and Chapter 21 (skills) are the foundations this chapter stands on.

The first morning you open your laptop and find work finished that you never asked for that day, you will understand why this is the last trick in the book.