Scheduling recurring reports and briefings

What to understand

• Scheduling moves a task from 'I run it' to 'it runs itself', and that single change removes the human-in-the-loop safety net every earlier lesson depended on. Before you automate anything, internalise the trade: you gain reliability and your attention back; you lose the propose -> review -> approve -> verify gate (Lesson 8) that catches silent failures live. Everything else in this lesson is about earning that trade back through guardrails.
• Both tools now ship first-class scheduling, but with different architectures. OpenAI Codex has 'automations' in its desktop app, recurring tasks that run in the background and report into a Triage inbox, plus 'codex exec' on the CLI for cron jobs and CI. Anthropic's Claude Code offers three distinct tiers: '/loop' (in-session polling that dies when the session ends), 'Desktop scheduled tasks' (local, persistent), and 'Routines' (cloud-hosted, run with your laptop closed). Match the tier to where the work must run and whether your machine will be on.
• Codex has three automation types. Standalone automations start a fresh run on a schedule and report into Triage, ideal when each run is independent or spans multiple projects. Project automations attach to a Git repo and run either locally (on your main checkout) or on a dedicated worktree (isolating changes from unfinished work). Thread automations are heartbeat-style recurring wake-ups attached to a thread, keeping its context alive for polling a long-running command or maintaining a review loop.
• Cadence is flexible but presets are safer than cron. Codex offers daily/weekly presets, minute-based intervals (thread automations only), and a custom cron field. Claude Code's '/loop' and Desktop tasks accept down to 1-minute intervals; Routines (cloud) enforce a 1-hour minimum. Reach for raw cron only when a preset truly cannot express your cadence, a subtly wrong cron expression is one of the most common ways a 'weekly' job quietly runs hourly and burns your budget.
• Cron is a 5-field expression, 'minute hour day-of-month month day-of-week', and the gotchas matter. '0 9 * * *' is 9am, '0 9 * * 1-5' is weekdays at 9am, '*/15 * * * *' is every 15 minutes. Claude Code interprets times in your LOCAL timezone (not UTC), supports steps/ranges/lists but not extended syntax (L, W, ?, MON/JAN aliases), and adds deterministic jitter so an hourly :00 job may fire up to :30, pick a non-round minute like '3 9 * * *' if exact timing matters. When both day-of-month and day-of-week are set, a date matches if EITHER does (standard vixie-cron behaviour, the classic Unix cron most schedulers copy), a classic foot-gun.
• Sandbox, network, and approvals are your real guardrails, set them as tight as the task allows. Codex automations honour a sandbox mode: read-only (tool calls fail if they'd modify files, hit the network, or touch apps), workspace-write (edits inside the workspace only), or full access (elevated risk, runs without asking). Unattended Codex runs use approval_policy = "never" where org policy permits; Claude Code Routines run fully autonomously with NO permission prompts at all. A reporting briefing needs read-only and nothing more, grant the minimum, every time.
• Idempotency is the property that makes unattended scheduling safe: running the task twice produces the same end state as running it once. A read-only briefing is naturally idempotent (it observes, it doesn't change anything). A task that mutates state, opening a PR, posting to Slack, writing a file, is NOT idempotent unless you design it to be: it must check 'did I already do this for this period?' before acting, or you'll get duplicate PRs, double-posted messages, and replayed side effects every time a run retries, overlaps, or fires twice. Default unattended tasks to read-only; make any state-changing one explicitly idempotent before you schedule it.
• Triggers are not only time. Both tools can react to events, not just clocks: Claude Code Routines support a Schedule trigger, an API trigger (POST to a per-routine endpoint with a bearer token, wire it to your alerting or deploy pipeline), and a GitHub trigger (run on pull_request or release events with filters). Codex similarly exposes schedule, webhook, and manual triggers, and 'codex exec' slots into GitHub Actions on any CI event. Event triggers are often better than tight polling, react when something happens instead of waking every minute to ask 'anything yet?'.
• Results need a destination and a triage habit. Codex collects runs in Triage, an inbox you can filter (all vs unread) and where empty/no-finding runs archive themselves so signal isn't buried under noise. Claude Code Routine runs appear as sessions you open and review; a green status means the session exited cleanly, NOT that your task succeeded, you still open it to confirm what actually happened. Whatever the tool, an automation you never read is worse than no automation: it's a false sense of coverage.
• Automate the repeatable and observe-only; keep humans in the loop for the consequential and irreversible. Good automation candidates: status digests, drift detection, log scans, dependency-update PRs left as drafts for review, nightly checks on long jobs. Bad candidates to run unattended with write access: anything that deploys, deletes, merges, sends external communication, or touches production data without a human approving the specific action first. The test: if this run did exactly the wrong thing at 3am, how bad is it, and would I find out before it mattered? If the answer is 'bad' and 'no', don't fully automate it, schedule the detection, gate the action.

Deeper dive

Scheduling & automation surfaces compared (Claude Code vs Codex, June 2026)

How each tool lets you run agent work on a schedule or trigger, and where each run executes. Choose by where the work must run, whether your machine will be on, and how much power the task truly needs. Both tools ship fast and several of these features are in active preview, verify command names, minimum intervals, and defaults at the official docs linked below before relying on specifics.

Sources (as of June 2026): Codex. Automations (types, cadence, sandbox, Triage) · Claude Code. Run prompts on a schedule (/loop, cron tools, jitter) · Claude Code. Routines (cloud, triggers, autonomy, guardrails) · Codex. GitHub Action (codex exec in CI)

Step by step

1

Decide if this task should be automated at all

Before touching any schedule UI, run the task through the three gates from the deep dive: (1) Is it repeatable and writable as a self-contained prompt with a one-sentence success criterion? (2) Is it observe-only, or does it act, and if it acts, is the action reversible and low-stakes? (3) If it failed silently at 3am, how bad is it and how soon would you know? Only fully automate observe-only, well-specified, low-blast-radius work. For consequential work, plan the split: automate the detection, keep a human on the decision.

HintIf you can't state the success criterion in one sentence, the task isn't ready to run unattended, sharpen it interactively first. Automation amplifies a vague prompt into reliable noise. The 3am test in one line: cost of a wrong run times likelihood it goes unnoticed equals your real exposure, high and hidden means don't fully automate.

2

Pick the right surface for where it must run

Choose the execution tier by where the work has to happen and whether your machine will be on. For a briefing that must run reliably without your laptop: Claude Code Routines (cloud) or a Codex standalone automation. For work needing local files with your machine on: Claude Code Desktop scheduled tasks, or a Codex project automation (prefer a worktree to isolate changes). For live polling inside an open session only: Claude Code /loop or a Codex thread automation. Note the floors and destinations as you choose: Routines run with the laptop closed but enforce a 1-hour minimum; Codex standalone automations report into Triage; Desktop tasks and project (worktree) runs need your machine on but reach local files.

HintCloud surfaces (Routines, standalone automations) are the true 'runs itself' tier, and exactly where tight guardrails matter most, because there's no local machine and no session to interrupt it.

3

Create the automation from a thread or the schedule command

12

You don't need a special screen. In Codex, ask from a regular thread to create an automation, describing the task, schedule, and scope in plain language. In Claude Code, run /schedule (e.g. '/schedule weekly Monday 9am payments-service briefing') to create a routine conversationally, or describe a one-off ('/schedule tomorrow at 9am, summarize yesterday's merged PRs'). Paste in the production read-only briefing brief from this lesson as the prompt, its self-contained, guardrailed wording is exactly what an unattended run needs. You'll know it's created when the automation appears in the App's Automations list (Codex) or /schedule lists the routine with its next run time (Claude Code).

HintBe explicit about scope and timing, vague requests become vague automations. The prompt must stand entirely on its own; there's no chance to clarify mid-run.

On this screen

1. 1Embedded creation UI. The automation form Codex opens when you ask from a thread, task, schedule, and scope captured in one place.
2. 2'Ask Codex to create or update automations'. You describe the automation in plain language from a regular thread and Codex builds it. Claude Code's equivalent is /schedule.

4

Set the cadence, prefer a preset, use cron carefully

Pick a daily/weekly preset where one exists. Only enter cron when a preset can't express your cadence: a 5-field expression 'minute hour day-of-month month day-of-week' (e.g. '0 9 * * 1' = Mondays 9am). Remember Claude Code reads times in your LOCAL timezone, adds jitter (an hourly :00 job may fire by :30, use a non-round minute like '3 9 * * 1' for tighter timing), and, when both day-of-month and day-of-week are set, matches if EITHER one does. Note the floor: cloud Routines enforce a 1-hour minimum; /loop and Desktop accept 1 minute. Before you save, confirm the scheduler echoes the next-fire time you expect, that echo is your check that the expression means what you think it does.

HintA subtly wrong cron is how a 'weekly' job quietly runs hourly and burns your budget. Read the expression back in plain English before saving, and verify after the first fire.

5

Lock the guardrails: sandbox, network, and blast radius

Set the five concentric rings before the first run. Scope: point the task at exactly the one repo/inputs it needs. Sandbox: read-only for a briefing, in Codex, read-only mode makes any write/network/app tool call fail outright. Network: keep the cloud environment's default 'Trusted' allowlist; widen only to specific hosts the task must reach, and prefer connectors over raw network. Approvals: unattended means no per-action approval by design, so never combine that with full access plus full network outside an isolated container. Blast radius: leave Routines on claude/-prefixed branches only (don't enable unrestricted pushes), and keep Codex project runs on a worktree. Done when the settings show read-only, one repo, default network, and default branch limits, and 'what's the worst this run could do?' has a small, boring answer.

HintLeast privilege is the whole game for unattended runs: grant exactly the power the job needs and not one ring more, so 'what's the worst this run could do?' has a small, boring answer.

6

Confirm idempotency before you let it recur

Verify the task is safe to run more than once. A read-only briefing is idempotent for free, running it twice changes nothing. If your task does anything that mutates state (opens a PR, posts a message, writes a file), do NOT schedule it until you've added a check-before-act guard keyed on a stable idempotency key (the ISO week, an issue ID, a content hash): 'have I already done this for this period?' before acting. Assume the scheduler will retry, fire late, or occasionally double-fire, make that a no-op rather than a duplicate.

HintThe symptom of a non-idempotent unattended task is unmistakable: duplicate PRs, double-posted messages, the same alert handled three times. Design it out before the second run, not after.

7

Run once, then triage and verify the result

Trigger one run immediately ('Run now' on a Routine, or wait for the first Codex fire) and READ it. In Codex, open Triage, filter to unread, read the findings, and archive empty runs so signal stays clear. In Claude Code, open the run session, remember a green status only means it exited cleanly, not that the task succeeded, so read the transcript and confirm what actually happened. Check the output against your brief's format and, critically, read the 'COULD NOT VERIFY' section, that's where an unattended run tells you what it couldn't do.

HintAn automation you never read is worse than none, it's false coverage. Build the triage habit now: a scheduled briefing is only useful if it lands somewhere you reliably look.

Production prompt examples

ROLE: You are a reporting agent running UNATTENDED on a schedule. There is NO human watching this run. You must behave as if every action is final and unreviewed, because it is.

TASK (runs every scheduled execution): Produce a concise Monday-morning engineering briefing covering changes in the `payments-service` repository since the previous Monday.

SCOPE, IN: Read only the `payments-service` repo: merged PRs, closed issues, and notable commits in the last 7 days. Summarise: (1) what shipped, (2) open risks or failing checks, (3) anything that needs a human decision this week.

SCOPE, OUT (HARD LIMITS, this run must never):
- Modify, create, or delete ANY file. This is a read-only observation task.
- Run any state-changing command (no git push, no merge, no deploy, no installs).
- Post to, message, or write to ANY external service or channel.
- Read or load any repo, file, or system outside `payments-service`.
- Reach any network host beyond what reading this repo requires.

IDEMPOTENCY: This task is observe-only and must remain so, running it twice for the same week must produce the same briefing and change nothing. If you ever find yourself about to take an action that would NOT be safe to repeat, STOP and report that you stopped instead.

UNATTENDED SAFETY RULES:
- If the task is ambiguous or the data needed is missing, DO NOT guess or act, produce a briefing that says exactly what you could not determine and why. A clear 'I could not verify X' is the correct output; a confident fabrication is the failure.
- If anything would require write access, network beyond the repo, or an external post to complete, DO NOT attempt a workaround. Report the blocker as a finding for a human.
- Keep the output tight: a human skims this in 60 seconds. Bullet points, no preamble.

OUTPUT FORMAT:
1. SHIPPED (last 7 days): 3-6 bullets, each PR/commit with a one-line what + why.
2. RISKS / FAILING CHECKS: bullets, or 'none observed'.
3. NEEDS A HUMAN THIS WEEK: explicit decisions or reviews to schedule, or 'none'.
4. COULD NOT VERIFY: anything blocked, missing, or uncertain, name it plainly.

If there is genuinely nothing to report this week, say so in one line so the run can be archived as empty.

Common mistakes to avoid

• Automating a task without first asking 'should this run unattended at all?', scheduling a consequential, irreversible action with the human removed instead of automating only the detection and gating the decision.
• Granting a reporting automation write, workspace, or full-access permissions it never needs instead of locking it to read-only, the briefing that could, in principle, modify files is a guardrail you forgot to set.
• Scheduling a state-changing task (opens a PR, posts a message, writes a file) without making it idempotent, then getting duplicate PRs and double-posted messages every time a run retries, overlaps, or double-fires.
• Reaching for raw cron when a daily/weekly preset would do, and shipping a subtly wrong expression so a 'weekly' job quietly runs hourly and burns budget (and forgetting Claude Code's local timezone, jitter, and either-day matching).
• Pairing 'no approvals' (the default for unattended runs) with full access and full network access outside an isolated container, removing every ring of protection at once.
• Treating a green run status as success, a clean exit only means the session ran, not that your task did the right thing; you still have to open the run and read it.
• Setting up the automation and never building the triage habit, so empty and failed runs pile up unread and a real finding (or a 'could not verify' blocker) sits buried for a week.
• Running a Codex project automation locally on your main checkout, or enabling unrestricted branch pushes on a Routine, when a worktree or claude/-prefixed branches would have kept the blast radius small.

Source conflicts to review

• Claude Code Routines are explicitly in 'research preview', behaviour, the 1-hour minimum interval, the daily run cap, and the /fire API surface (under the experimental-cc-routine beta header) may change. Treat the mechanics here as accurate as of June 2026 and re-check code.claude.com/docs/en/routines.
• Minimum schedule intervals differ by surface and shift across releases: /loop and Desktop scheduled tasks accept 1-minute; cloud Routines enforce 1-hour; Codex thread automations allow minute intervals while standalone/project automations lean on presets. Confirm the floor for the exact surface you use.
• CLI version gates move: scheduled tasks require Claude Code v2.1.72+, and the /schedule routines command has required as recent as v2.1.81, run `claude --version` / `claude update` rather than trusting a fixed number.
• Codex exec flags and sandbox naming (e.g. --full-auto vs --sandbox danger-full-access, --ephemeral, resume --last, --json/--output-schema) and the approval_policy="never" default have varied across point releases; verify against the current Codex CLI help and the official automations / GitHub Action docs before scripting them.