Scheduled Jobs

Automations is a fixed entry in the sidebar, next to All sessions and History — always visible, even before you’ve created a single job. It opens a full-screen list of your scheduled jobs: at the time you pick, vord starts a Claude, Codex, Kimi, or OpenCode session in a project and sends it a fixed prompt, without you having to be there to type it.

On your iPhone

View your Mac’s automations from the iPhone companion when at least one of your own paired Macs supports them. See Automations in the iPhone Companion for the phone view and the actions that stay on your Mac.

Creating a job

Click New automation (in the header, or in the empty state) to open the editor.

Name — optional, just for your own list (e.g. “Morning review”). An unnamed job shows as Untitled automation.
Prompt (required) — the message the agent receives the moment the job fires.
Project (required) — the job always starts its session inside a project; if you haven’t opened one yet, the picker is disabled with a note to open a project first.
Agent — the project’s default agent, or force Claude, Codex, Kimi, or OpenCode.
Model, Thinking and Permission mode — optional per-job choices. Leave a choice blank to use the app default. The model and thinking choices come from the selected provider; OpenCode has no thinking-level choice and reports its models dynamically. An invalid value fails the run and is recorded as a failure. For Claude jobs, Default inherits the permission mode from your Claude profile (for example, permissions.defaultMode in Claude settings), so it may not prompt; choose an explicit permission mode if you want prompts.

The row also shows an origin badge: You for jobs created in the editor and Agent for jobs created by an agent through the jobs tools.

When to run

The Repeat picker offers five schedules, in plain language (no cron syntax):

Repeat	What you set
Once	A specific date and time
Every day	A time of day
Every week	A weekday + a time of day
Every few days	An interval in days (e.g. every 3 days) + a time of day
Every few weeks	An interval in weeks (e.g. every 2 weeks) + a weekday + a time of day

The list shows each job’s schedule in the same plain language — “Every day at 09:00”, “Every Monday at 10:00”, “Every 3 days at 14:30”, “Once on 20.07.2026, 09:00” — plus its next scheduled run, or paused if you’ve turned it off.

Every automation with an upcoming run also appears in the board’s agenda for the next 14 days — on the Mac and on your iPhone, with the time of its next run.

Catch-up and pausing

Two independent switches live under Behavior:

Catch up on missed runs (on by default) — if your Mac was off or vord was closed at the scheduled time, the job runs once at the next app start instead of being skipped. If a job missed several occurrences while closed, that still collapses into a single catch-up run, not one per missed slot. Turn this off per job if a stale run would do more harm than good (e.g. a job that only makes sense at its exact time).
Active — turn a job off to keep it (and its history) without deleting it; an inactive job’s schedule never fires, and its row shows paused instead of a next run.

A once job disables itself automatically right after it fires — there’s nothing to turn off by hand for a one-shot job.

Run history

Each job’s row keeps its last runs (most recent first), including finished runs. A run shows its timestamp, state and a short summary. While a run is starting it can show starting…; once it has a session, an Open link jumps straight to it.

Job-started sessions are visible project sessions again. In vord they appear in the sidebar, cockpit grid, session search, iPhone and remote access. A calendar-with-clock symbol marks the session, and its tooltip is Automation: <Job name>. The session is named after the job. Starting a job session never changes your selection: it appears in the grid with its badge, and your current session stays selected.

After a job session ends, vord hides it automatically once it is no longer working and is not currently selected: immediately when its result was recorded, after an hour when it ended with a failure or without a recorded result — or sooner when that job runs again, and after 24 hours at the latest. Hidden sessions remain available through Show completed and the project’s history. The project lead can stop a job’s session at any time, whoever created the job.

Run states and reasons

Every run has one of these states: start failed, waiting for prompt, prompt delayed, running, completed, failed, or ended without a recorded result. When a run has a problem, the Automations view shows Failed: <reason>, Waiting for its prompt: <reason>, or No result recorded: <reason> — the last one in the same waiting-yellow as a delayed prompt, never in failure-red. The jobs_list tool returns the latest run’s state, failure_code, and English reason; a run without a recorded result reports no_result there.

Stable reason codes are: composer_never_ready, submit_unconfirmed, session_ended_before_prompt, ended_while_waiting_for_input, no_result_recorded, session_failed, start_failed, project_missing, no_project_lead, lead_start_failed, routing_failed, model_access_denied, pool_exhausted, pin_conflict, and workspace_not_trusted. vord uses held_by_usage_brake when the usage brake delays a prompt. vord uses usage_measurement_missing when the account’s usage measurement is missing or stale. A project-lead job that fires while the lead’s session limit is reached is queued as a next_slot plan instead of failing the run.

A job session that is waiting for your approval or an answer notifies you the same way any other session does. Permission, a question, plan approval, and a session failure reach the inbox, banner, and phone. Finished, idle, and a clean exit stay quiet.

A run that ends while it was still waiting — the app restarted, or the session ended without a result — fails with ended_while_waiting_for_input. It is not recorded as finished. vord tells the person who created the job, or you when that session is gone.

A delivered run whose session finishes its turn without calling jobs_record_run ends with no_result_recorded. This is not a failure: it is not recorded as finished, it does not count as failed, and the run session can still record its result while it is open. A late recording is written to the learning memory like a normal run and is then reported as finished or failed.

Project-folder trust

Claude or Codex can ask you to trust a project folder when a job starts. vord never confirms this dialog. The run is marked workspace_not_trusted, and you get a notification that opens the session so you can confirm it yourself. vord keeps trying and delivers the prompt automatically after the folder is trusted. This also applies to project-lead jobs.

For Claude, Grok and Kimi, vord pre-trusts job folders the same way it does for child sessions, but only inside registered project folders or their registered worktrees. Muse job runs in those registered folders start with --trust-workspace for that run. Other folders are not pre-trusted. The dialog and workspace_not_trusted then only concern Codex, plus Claude outside registered folders or where the entry was skipped. For registered folders there is no trust note; should the entry exceptionally not take effect, the dialog and workspace_not_trusted still apply. When you create or edit a job, the editor and jobs_create/jobs_update response show a note for Codex without trust, and for Claude outside registered folders.

Delivering the prompt

Starting the session is only half the job — the prompt still has to land and actually get submitted. vord waits until the agent’s input field is ready. A grey placeholder in the field is not treated as input, including on the welcome screen.

If the prompt has not arrived after a little over a minute, the run becomes waiting for its prompt. The creator is notified, and vord keeps trying every 30 seconds. If the session ends before the prompt arrives, the run fails.

The job notification

When an agent creates a job with jobs_create, vord remembers the session that created it. Reports go to whoever can still act, in order: the creating session if it is still running, then the project lead’s session (unless it is the same session), then you. That chain receives a short message when the run fails, ends without a recorded result, is delayed while waiting for its prompt, or completes. For jobs created in the editor the chain starts with you: failures, missing results, and delayed prompts use a notification banner, while completion is a quiet entry in the notification inbox. The same failure or the same missing result in consecutive runs of one job notifies only once instead of once per run. Click the inbox entry (from the bell, on Mac or iPhone) to jump straight to the started session. A notify_user call from the automation is different: it is an explicit, loud agent message and can include urgency and attachments.

Letting an agent schedule jobs for you

vord’s own MCP server (present in every session — see MCP Servers) exposes four tools an agent can call on your behalf, in any session:

jobs_create — create a job from name, prompt, and a frequency (once/daily/weekly/every_n_days/every_n_weeks) plus the fields that frequency needs (time, and date/weekday/every_n as applicable). Omit project_id to target the current session’s own project.
jobs_list — list your jobs with their schedule, next run, and on/off state — the same information the sidebar shows.
jobs_update — change a job’s fields, or pass enabled: false/true to pause or resume it, by id (from jobs_list).
jobs_delete — remove a job for good; use jobs_update with enabled: false instead if you just want to pause it.

When vord is busy, the jobs_list tool waits up to 25 seconds and tries once more; its error says whether vord is not running or is running but did not answer in time.

In practice, that means you can ask an agent in any session — “schedule a job for me that runs every Monday at 10:00” — and it creates the automation without you opening the editor. The tools speak the same plain schedule language as the UI (weekday names, HH:MM times), not cron syntax.

Agent changes to your jobs

An agent can change or delete a job it created. Your jobs are different: an agent’s jobs_update or jobs_delete request creates a pending approval request instead of changing the job immediately. The request appears in the Pending requests section of Automations with the proposed change. Choose Approve to apply it or Reject to discard it. The agent can see the decision through jobs_list. You can always edit or delete your own jobs directly in the UI.

Approving job changes from your iPhone

With a current Mac, the same pending change also reaches a paired iPhone or iPad. It sits in Open decisions as Job change, with Approve change / Reject. A push tap opens the oldest open job-change request. One decision counts: if you already chose on the Mac, the phone reports that the request was already decided. Against an older Mac the inbox keeps the previous jobApproval text and has no buttons. Guests never see the list. Protected-folder and snapshot settings stay on the Mac; this path only decides the pending change.

Learning memory

Each project job keeps a small learning memory at .vord/automations/<job-id>/:

runs.jsonl stores the last 50 runs, with the fire time, outcome, short summary and session ID.
playbook.md contains lessons distilled and maintained by the automation itself.

At the start of every run, vord supplies the playbook and the five most recent run records to the agent. At the end, the agent calls the vord MCP tool jobs_record_run once with the outcome, a short summary, and the updated playbook. vord writes runs.jsonl and playbook.md; the agent does not create or edit those files and needs no extra file permissions for them. Missing files are normal on a first run. This memory stays in the project rather than in the global run history. If the session records its result late — after its run already ended without one — vord writes that recording to the learning memory exactly like a run recorded in time.

During a job run, vord lets the agent call only its own jobs_record_run tool without asking (claude, grok, opencode, muse and kimi; codex already trusts vord’s tools); everything else follows the job’s permission mode. For kimi, vord adds the rule below to its managed block in kimi’s config.toml.

If kimi’s config.toml already has its own [permission] section, add this rule yourself; vord will not add it in that case:

[[permission.rules]]
decision = "allow"
pattern = "mcp__vord__jobs_record_run"