The biggest gap in how most people use coding agents is that they only run them while watching. You type a task, the agent works, you review. Useful — but the leverage arrives when the agent runs while you sleep: nightly dependency checks, a morning digest of what changed in your ecosystem, routine cleanup with a report waiting at breakfast.
Getting there is not hard, but it is different from interactive use in one fundamental way: nobody is present to catch mistakes. Everything in this guide follows from that single constraint. Here is the full setup, in five steps, using tools you already have. The examples use Claude Code and OpenAI’s Codex CLI, but the pattern applies to any agent with a non-interactive mode.
Step 1: Pick a task that fails safely
Not every job belongs on a schedule. A good first candidate has three properties:
- Read-mostly. The agent gathers, summarizes, checks, or drafts. It does not deploy, publish, or delete. Anything irreversible stays out of unattended runs until you have months of clean logs — and money-touching actions stay out permanently.
- Cheap to re-run. If Tuesday’s run produces garbage, you shrug and look at Wednesday’s.
- Valuable in aggregate. The point is a stream of small wins that would not justify your attention individually.
Classic first projects: summarize new releases and security advisories for your dependencies; draft triage notes for issues opened overnight; check your documentation’s links and flag the dead ones. Pick exactly one. Resist the urge to automate five things at once, because when something breaks — and early on it will — you want one suspect, not five.
Step 2: Write the runbook file
Do not put the task in the scheduler command itself. Put it in a version-controlled file the agent reads — a runbook. The scheduler entry then stays trivial and the actual instructions get code review, history, and a diff trail.
A good runbook has four sections, and the order matters:
- Goal — one paragraph on what the run produces and for whom.
- Steps — numbered, concrete, with exact paths and commands. Vague instructions that work interactively fail unattended, because interactively you were the missing specificity.
- Boundaries — what the agent must not do. Name the forbidden actions explicitly: no pushing, no publishing, no deleting, no installing. An instruction that seems too obvious to write down is exactly the one worth writing down.
- Output contract — where the result goes and what it must contain: file path, format, required sections, a date stamp. The next step depends on this contract being checkable by a script.
Keep the runbook in the repository the agent works on. When a run goes wrong, the fix is almost always a runbook edit, and you want that fix reviewed and committed like any other change.
Step 3: Wire the scheduler
Every platform has a scheduler that survives reboots and logs failures: cron on Linux and macOS, Task Scheduler on Windows. Both agents have a non-interactive mode designed for exactly this — claude -p "<instruction>" for Claude Code, codex exec "<instruction>" for Codex. The instruction you pass stays one line: read the runbook and execute it.
# crontab: weekdays at 06:00, log everything, never prompt
0 6 * * 1-5 cd /path/to/repo && claude -p "Read RUNBOOK.md and execute it exactly. Write the report to reports/digest-$(date +\%F).md" >> logs/agent.log 2>&1Three details that separate a setup that works from one that mysteriously doesn’t:
- Set the working directory explicitly. Schedulers start in a different directory and a thinner environment than your login shell. Most “works in my terminal, fails at 6 a.m.” mysteries are the working directory or a missing PATH entry.
- Capture output to a log file. When a run fails silently, that log is the only witness you have.
- Date-stamp every output file. Overwriting one file destroys your history; when the agent misbehaves, comparing this week’s outputs against last week’s is how you find out when the drift started.
Run the whole command by hand once, from a fresh shell, before trusting the schedule. It is the cheapest test you will ever run.
Step 4: Add a machine gate
This is the step most people skip, and it is the one that makes unattended operation safe. An agent’s failure mode is rarely a crash — it is confident, plausible output that is subtly wrong or quietly incomplete. Since you are not there to notice, a script has to be.
The gate is a small program that checks the output contract from your runbook: the file exists, it is dated today, it exceeds a minimum length, required sections are present, nothing matches forbidden patterns. If any check fails, the gate’s job is to make the failure loud — mark the output as failed, or move it out of the “done” folder — so a broken result cannot be mistaken for a good one.
Two rules make gates trustworthy. First, test the gate by breaking it: feed it an empty file, a stale date, a missing section, and watch it fail. A gate you have never seen fail is decoration, not protection — we learned this on our own pipeline when a one-character regex typo turned a gate into a rubber stamp that passed everything. Second, fail closed: when the gate itself errors, treat the run as failed. A gate that shrugs on error is a gate that lies precisely when things are most broken.
Step 5: Review weekly, then widen slowly
For the first two weeks, skim every output — you are calibrating. After that, drop to a weekly review of the log and spot-checks of the outputs. You are looking for drift: reports getting thinner, sections going missing, steps quietly skipped. Drift is normal; models change and inputs change. Each drift becomes a runbook edit or a new gate check, and the system gets sturdier with every failure it survives.
Only widen scope after a streak of boring, clean weeks — and widen one property at a time: a second task, or a first cautiously write-capable action, never both at once. The boring weeks are the credential that unlocks the next level of autonomy.
Start with one read-only task tonight. The setup takes under an hour, and the habit it builds — instructions in files, outputs under contract, machines checking machines — is the foundation everything larger stands on.