Scheduling and unattended work

Most of the time you start an agent session yourself. Sometimes you want work to start without you — a nightly dependency audit, a Monday-morning sprint plan, a refactor that should run while you sleep. In ORG-2 that is a routine: a saved trigger plus a run template. The scheduler that evaluates routines lives in the Rust backend, so a routine fires without any window being open.

Creating a routine

Routines are managed in settings under the Routines category. The list shows each routine's Name, Trigger, Target, and Status, and rows expand to reveal configuration and history. Add Routine opens the wizard.

Three more fields — Output, If already running, and Missed runs (after downtime) — are covered below.

One-shot and recurring runs

A One-time routine has a single Run at timestamp. Once it fires, the backend disables the routine automatically — it cannot fire twice.

A Cron routine uses a standard 5-field cron expression (minute hour day month weekday). Presets cover most cases: Every day, Every weekday (Mon-Fri), Every week (with a Day of Week), and Every month (with a Day of Month), each paired with a Time. For anything else, open Custom cron expression and type it directly — the in-app hint is e.g. 0 9 * * 1 = every Monday 9:00 AM.

Note: routine cron expressions are evaluated in UTC. There is no per-routine timezone setting, so offset your times accordingly.

The expanded row shows Next run, recomputed after every evaluation pass.

What a fire produces

For anything that writes code unattended, set Workspace to Worktree rather than Local workspace. A worktree run gets its own checkout and Branch, so an overnight routine cannot leave your working copy half-edited, and you review the result as a normal branch diff in the morning.

When the machine sleeps or the app is closed

The scheduler is a background task that wakes every 30 seconds and evaluates every enabled routine. Two consequences follow:

• The process must be alive. ORG-2 does not install an OS-level cron job, launch agent, or launch-at-login entry. Closing the window is fine — on macOS and in release builds the window hides and the process keeps running, so routines keep firing. Quitting stops them until you open the app again.
• Sleep stops the clock. A sleeping machine is not running the poll loop.

Each routine keeps a watermark of its last evaluation. On the next pass the scheduler looks at every trigger time between that watermark and now, so runs missed during downtime are detected — what happens to them is your choice:

Every scheduler-originated fire carries an idempotency key derived from the routine ID and the scheduled time, so a crash between recording a fire and updating the watermark cannot double-fire after restart.

To keep a machine awake for work already in flight, enable Prevent system sleep during sessions in General settings. It is off by default, is implemented on macOS and Windows only, and releases when all sessions finish. It does not wake a sleeping machine to start a scheduled run.

Overlapping runs

If a routine fires while a previous run of the same routine is still active, If already running decides what happens: Coalesce into active run, Skip this fire, Queue after active run, or Always run in parallel.

Note: ORG-2 does not throttle scheduled work based on CPU load, free RAM, or whether you are at the keyboard. Concurrency is controlled per routine by the policy above, not by a global resource governor. The Performance Monitor in settings reports CPU, RAM, disk, and network usage, but it is an observability panel — it does not gate execution.

Guardrails for unattended runs

An agent running at 3am cannot ask you a question, so decide in advance how much rope it gets.

• Permissions. For Claude Code CLI agents, Default Permission Mode offers Default, Plan, Accept Edits, and Bypass Permissions. Reserve Bypass Permissions for routines whose workspace is an isolated worktree.
• Sandbox. Enable Sandbox isolates bash commands from your filesystem and network; with it on, Auto-approve Bash lets commands run unprompted. Excluded Commands, Allowed Domains, and the filesystem allow/deny lists narrow the blast radius further.
• Notifications. Enable System Notification and Enable Dock Badge are both off by default — turn them on before you rely on being told about an overnight run. The Task Completion, Agent Approval, and Errors & Warnings categories are on by default; Session Status and Git Operations are not. Test Notification confirms OS permission was actually granted.
• Presence. The sidebar presence control — Online, Invisible, Away — injects an editable instruction into the agent's prompt. The shipped Away text tells the agent not to block on you, to finish what it can, and to leave a summary and open questions for your return. This is guidance to the model, not enforcement.

Reviewing what ran while you were away

Expand a routine's row for Run history — the 20 most recent fires, each with a timestamp, status, and the session or work item ID it produced. Statuses are pending, started, succeeded, failed, skipped (suppressed by the concurrency policy), coalesced (merged into an active run), and queued. History is per routine; there is no combined cross-routine feed.

Runs that could not start at all show up in the Inbox as high-priority messages from Scheduler or Orchestrator — for example when a work item has no code account configured, or when an orchestration phase is waiting on a human decision.

On the work item side, the Output tab is where an unattended run leaves its evidence: the Pull Request it opened, the branch it worked on, Changed Files with per-file diff stats, the review feedback if review was enabled, and a Cost Summary in dollars and tokens. Work items created by a routine also carry a From routine: {name} chip, and re-runs append a history entry naming the routine and the time it fired.

Note: there is no daily digest or combined "while you were away" report, and no calendar of past or upcoming runs — ORG-2's calendar component plots work items by date, not routine fires. Reviewing overnight work means checking the Inbox, then the run history of the routines you care about.

Next steps

• Projects and work items — where scheduled work lands and how its lifecycle works
• Sessions — what a routine actually starts when it fires
• Agents — choosing the agent responsible for a routine
• Security — permission modes and sandboxing in depth