How to schedule Claude Code to run automatically

Interactive Claude Code is excellent for exploratory work — you steer, it plans, you approve diffs. But plenty of engineering work is repeatable: nightly dependency audits, weekly changelog drafts, morning "scan open issues and summarize," or a daily pass over error logs in a repo.

Scheduling turns those prompts into something that runs whether or not you remembered to open a terminal. The question is not whether you can automate Claude Code — you can — but how much context and oversight you need between runs.

Three legitimate approaches, from most DIY to most integrated:

1. System cron + claude -p on your Mac or Linux machine (or Task Scheduler on Windows with WSL).
2. CI schedules — GitHub Actions (or similar) running Claude on a cron trigger in the cloud.
3. Aiola automations — cron-style schedules inside a desktop app, using your existing Claude Code subscription.

This guide walks through all three with working examples and honest limitations — not a sales pitch for any one path.

The zero-dependency approach is cron (macOS/Linux) or launchd on macOS calling Claude Code in headless mode. Install Claude Code globally, authenticate once interactively with claude login, then schedule a non-interactive prompt.

claude -p accepts a prompt string, runs the agent, prints output, and exits. It is designed exactly for scripts and schedulers.

Example: every weekday at 6:30am, summarize yesterday's git activity in a repo.

# Edit your crontab
crontab -e

# Add this line (adjust paths):
30 6 * * 1-5 cd /Users/you/code/myapp && /usr/local/bin/claude -p "Summarize git commits from the last 24 hours. Write a short markdown report to reports/daily.md. Do not commit." >> /Users/you/logs/claude-cron.log 2>&1

What this does well: no extra software, runs on your machine, uses your Claude Code subscription (when auth persists), and keeps code local.

Limitations you should expect:

• No context between runs. Each cron invocation is a fresh session. Yesterday's plan is gone unless you store it in files or git and re-inject it into the prompt.
• No conversation history UI. Output goes to a log file. Reviewing what changed means reading logs or checking git diffs yourself.
• Headless auth quirks. If Claude Code's session expires or needs re-login, cron runs fail silently until you notice the log. Some users wrap scripts with auth checks; others use API keys in CI instead.
• No worktree isolation. If the agent edits files, it edits the main working tree. Parallel scheduled jobs on the same repo can collide unless you script branch/worktree setup first.
• Machine must be on. Cron only fires when the computer is awake. Laptops asleep at 6:30am miss the job.

Cron + claude -p is a real, working pattern for simple, stateless tasks — daily summaries, lint-and-report passes, or "open a PR comment draft" jobs where each run is self-contained. It stops scaling when you need memory, multi-repo context, or reliable auth without babysitting.

The second approach moves scheduling to continuous integration. GitHub Actions has a native schedule trigger driven by cron syntax in UTC. Your workflow checks out the repo, installs Claude Code (or calls the Anthropic API directly), runs the prompt, and optionally commits or opens a PR.

Minimal example — weekly dependency review every Monday at 09:00 UTC:

# .github/workflows/claude-weekly.yml
name: Weekly Claude review
on:
  schedule:
    - cron: "0 9 * * 1"
  workflow_dispatch:

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
      - run: npm install -g @anthropic-ai/claude-code
      - name: Run Claude headless
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          claude -p "Review package.json for outdated deps. List recommended bumps in deps-review.md."
      - name: Commit report
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git add deps-review.md
          git diff --staged --quiet || git commit -m "chore: weekly deps review"
          git push

Advantages over laptop cron: runs even when your machine is off, reproducible environment, git integration is natural, and teams can see workflow logs in GitHub.

Tradeoffs:

• API-key cost vs subscription. CI typically uses ANTHROPIC_API_KEY billing, not your Claude Max seat. Frequent agent runs can cost more than a flat subscription — model the spend before scheduling hourly jobs.
• Still no long-lived memory. Unless you commit artifacts between runs, each workflow start is cold context.
• Security surface. You are granting a cloud runner write access to your repo. Use least privilege, branch protection, and review bot commits.
• Agent scope. CI runners are ephemeral — fine for repo-bound tasks, awkward for cross-project portfolio work or local-only secrets.

CI schedules shine for repo-scoped maintenance on teams already living in GitHub: release notes, migration codemods, scheduled test fixes. They are less ideal for personal multi-repo orchestration across ten side projects.

The third path is a desktop orchestrator with built-in scheduling. Aiola includes automations — cron-style jobs that run prompts against Claude Code (or Codex, Cursor, Grok CLI, and OpenCode) on your existing subscriptions, not a cloud compute markup.

What Aiola automations add beyond raw cron:

• Agent and model selection per automation — pick Claude Code, Codex, Cursor, Grok CLI, or OpenCode for each job.
• Skills — attach reusable instruction packs instead of pasting the same prompt into crontab.
• Run history — see past executions, outputs, and failures in the app instead of grepping log files.
• Memory between runs — automations can persist context in project memory so Tuesday's job knows what Monday's job concluded.
• Project context — runs target a workspace with threads, tasks, and repo paths already wired.
• Templates — start from built-in patterns for releases, bugs, analytics, and recurring reviews.

Honest disclosure: Aiola automations are local-first. The desktop app must be running (and your machine awake) for scheduled jobs to fire — same class of limitation as laptop cron, but with a GUI, history, and subscription-native auth instead of shell glue.

Aiola does not resell compute. Agents execute on your machine against your repos using the Claude, OpenAI, Cursor, or xAI access you already pay for. That makes automations closer to "cron for your Max subscription" than "rent another cloud agent."

Pricing: Aiola offers a 7-day free trial with no free plan; Pro starts at $24/month (see pricing). Automations are part of the operations layer — the value is orchestration and visibility, not API markup.

Choose Aiola automations when you have several repos, you want mixed providers on different schedules, and you are tired of maintaining bash wrappers around claude -p. Stay on cron or CI when you have one repo, one prompt, and full shell control is a feature not a burden.

Use cron + claude -p when the task is simple, stateless, and repo-local; you are comfortable with log files; and your machine is reliably on at the scheduled time.

Use GitHub Actions cron when the work lives in one git repo, your team already uses CI, and you accept API-key billing for unattended cloud runs.

Use Aiola automations when you want scheduled agent work across a portfolio, with run history, skills, memory, multi-provider choice, and subscription-native execution — and you can keep the desktop app running on a Mac or Windows machine that acts as your orchestration host.

Many operators combine layers: CI for repo hygiene on GitHub, Aiola for cross-project agent work and operational prompts (analytics summaries, log triage, feedback digests), and occasional manual Claude Code sessions for exploratory coding.

Regardless of approach, unattended agents deserve guardrails:

• Scope the prompt. Say what to touch and what to avoid ("do not commit," "read-only except reports/.").
• Use branches or worktrees when the agent may edit code — never let two schedulers write main concurrently.
• Log everything with timestamps and exit codes; alert on non-zero exits (email, Slack, or Aiola run history).
• Rotate secrets in CI; never commit API keys.
• Start with read-only tasks — summaries and reports — before auto-commit workflows.

Scheduling Claude Code is powerful once the boring infrastructure (auth, logs, isolation) is solid. Pick the lightest tool that still meets your context and visibility bar — then upgrade when cron output stops being enough.