Going parallel
Running work on a schedule
Recurring agent runs that fire on their own — a nightly review, a morning digest, a weekly sweep.
/schedule add --cron "0 2 * * *" -- "review today's merges"
/schedule list
/schedule history <id>What it is
A durable local schedule that runs an agent task without you present. It survives restarts, keeps a history of every run, and can be paused and resumed.
The subcommands
| Command | What it does |
|---|---|
/schedule add (--at RFC3339 | --when TEXT | --cron EXPR) -- <task> | Create one and return its ID |
/schedule list | Everything scheduled |
/schedule show <id> | One schedule and its next run |
/schedule run <id> | Run it now, without waiting |
/schedule pause <id> | Stop firing, keep the definition |
/schedule resume <id> | Start again |
/schedule remove <id> | Delete it |
/schedule history [id] | Recent run receipts: status, time, run ID, and any launch error |
csc schedule does the same from the shell.
Use exactly one timing option. --at takes a full RFC 3339 timestamp such as
2026-07-30T09:00:00-07:00; --when accepts a one-time phrase such as
"tomorrow 9am"; --cron takes a five-field cron expression. Add --tz America/Los_Angeles when a recurring schedule should not use the machine's
current timezone. Put flags before --, and the task after it.
Creation also accepts --agent <name>, --permission-mode plan|default|auto, and --workdir <path>. Scheduled work defaults to the
read-only plan mode; bypass is forbidden. --target local is the only
target: these schedules belong to the CLI, while dashboard schedules are
cloud-owned.
The shell form adds machine-readable output:
| Shell command | Additional flags |
|---|---|
csc schedule add | --json |
csc schedule list | --all, --json |
csc schedule show, pause, resume, run | --json |
csc schedule history | --limit N, --json |
Put shell flags before a positional schedule ID, as in csc schedule history --json <id>. /schedule inside chat renders readable text instead.
Good candidates
- A nightly review of the day's merges against your conventions.
- A weekly dependency check that opens a ticket when something's outdated.
- A morning digest of what changed in a repository you don't work in daily.
- A recurring sweep for a pattern you're migrating away from.
What it isn't
It runs on your machine, when your machine is on. It isn't a hosted cron. A laptop that's closed at 2am doesn't run the 2am job — it runs it at the next opportunity and the history says so.
Cost
Scheduled runs bill like any other run. A nightly job across a large repository
is a real recurring cost. Your account balance reflects that usage;
/schedule history records execution status, not a per-run credit breakdown.
If it doesn't work
It didn't fire. The machine was off or asleep. /schedule history shows
the run history; /schedule run <id> triggers one now. Missed recurring
occurrences coalesce rather than launching a backlog all at once. Transient
launch failures retry three times; a recurring schedule pauses itself after
five consecutive failures.
It fires but does nothing useful. The task description needs the same finish line as any other request. "Review today's merges and open a ticket for anything that contradicts our conventions" beats "check the code".
I want it to stop but keep the definition. /schedule pause, not
remove. Both take the ID printed by add or list.