Scheduled Automation

A scheduled automation starts an ordinary root-agent task on a schedule. It is not a simple reminder: every run may read a project, call a model, use tools, and create files or external side effects. Choose its goal and permissions carefully when you create it.

The entry point in the product interface is named “Scheduled.” “Browser automation” on this page refers to a separate capability; see Browser Automation.

Tasks that fit

Generate a recurring project status brief.
Check a root conversation each day and report important changes.
Run tests, organize logs, or update a local report periodically.
Perform one missed check the next time the app starts.

It is not suitable for work that must run on time after the app exits, requires second-level triggering, needs a one-time reminder, or performs high-risk external actions that cannot be repeated safely.

Create a task

Select “Scheduled” in the left sidebar.
Select “Create” or “Create task.”
Enter the task name and task description.
Choose the run target, permissions, frequency, and notification policy.
Review the summary and save.

Write the task description as a self-contained instruction for every run, for example:

Check the current project's test status. Do not install dependencies. Run the existing unit tests and list newly failing tests and possible causes. If nothing has changed, explicitly report no change.

A scheduled automation currently cannot attach files, explicitly select a skill, or configure temperature, max tokens, or reasoning separately. If a skill is needed, you can instruct the agent to use the relevant currently available capability, but availability ultimately depends on the runtime directory and configuration.

Choose a run target

New conversation

Each run creates a new root conversation. You must select:

An optional project.
An enabled model.
A permission mode.

This works for daily reports, scans, and other runs whose results are independent. New conversations remain in the ordinary conversation list. Deleting the scheduled automation does not delete historical conversations.

Existing conversation

Each run appends a turn to the selected active root conversation. Archived conversations, subagent conversations, and conversations that cannot be written to are not valid targets.

This works for ongoing follow-up on one topic. The automation uses the project's and model's current binding in that conversation. If the target is archived or deleted, the task enters “Needs repair.”

Set the frequency

Current structured frequencies include:

Every number of minutes, hours, or days.
Daily or on weekdays.
Selected days of the week.
Custom intervals every N hours, days, weeks, months, or years, with selected minute, time, weekday, date, and month values.

The interface does not accept free-form cron expressions. It also does not support one-time schedules, end dates, or “stop after N runs.”

When you create or save an edit, the task adopts the time zone recognized by the current computer. There is no separate time-zone selector. Editing and saving on a computer in another time zone may change future trigger times. During daylight-saving transitions, nonexistent local times are skipped and repeated local times do not run twice.

Choose permissions

You can select Default, Full, or Custom permissions, but Full and Custom must first be enabled under “Settings → General.”

The effective permissions at save time are frozen:

Future changes to global Custom details do not rewrite existing tasks automatically.
Disabling Full or Custom mode prevents future runs of corresponding tasks from starting and marks those tasks as needing repair.
Re-enabling the mode does not repair a task automatically; edit and save the task.
To actually reduce an existing task's permissions, edit each task or disable the corresponding mode first to prevent execution.

A background task with Default permissions may still stop at “Awaiting approval.” The system creates a needs-attention marker and attempts to send a system notification. After the app restarts, the same decision remains pending; it is not approved by default.

Notification policies

For “New conversation,” choose:

Every run.
Unsuccessful runs only.

For “Existing conversation,” choose:

Important updates.
Unsuccessful runs only.

Approval requests, invalid configuration, and some important results also create needs-attention markers. A system notification is a reminder, not a reliable delivery guarantee. The operating system may deny notifications, and there is currently no in-app reminder fallback. In rare crash windows, a notification may appear twice.

Selecting a notification attempts to open the exact task, run, or conversation message. Notification text does not include complete prompts, tool parameters, or credentials.

Manage tasks

The “Scheduled” page supports:

Filtering by all, enabled, or paused and searching by name.
Viewing the next run, health status, and latest result.
Editing, pausing, resuming, running now, or deleting.
Viewing run history and opening the relevant conversation when needed.
Marking a needs-attention item as handled.

“Run now” adds one run to the queue. It does not start a second run while the same task already has an active run.

Pausing clears future scheduling only. It does not cancel a run that is already active or awaiting approval. A paused task can still be started manually with “Run now.” The current interface has no separate stop button for an active run. Deleting prevents future schedules, cancels runs that have not actually started, and requests cancellation of active runs, but conversations created previously remain.

Understand statuses

Task status and health status are different:

Enabled/Paused: Whether the task accepts future automatic scheduling.
Healthy/Needs repair: Whether its target, project, model, permissions, and frequency remain valid.

A run may display Queued, Starting, Running, Awaiting approval, Completed, Failed, or Canceled. Run history also identifies its trigger source: scheduled, manual, or recovery.

When a task “Needs repair,” open it, reselect the conversation, project, model, permissions, or frequency as prompted, then save. Restoring a resource, re-enabling a permission mode, or marking an attention item handled does not automatically repair an old configuration.

App shutdown and recovery

Scheduled tasks run only while Captain Who and its local runtime components are running. When the app has exited, the computer is off, or required processes are not running, no operating-system service wakes tasks in the background.

At the next launch, multiple trigger times missed while offline are combined into one recovery run rather than replayed individually. The scheduler scans periodically and does not guarantee second-level timing.

Safety recommendations

Begin with Default permissions and use “Run now” to verify the prompt.
Use version control for tasks that may write files and constrain output to explicit paths.
Do not schedule payments, publishing, deletion, or bulk external actions that cannot be reviewed by a person under Full permissions.
For tasks with third-party side effects, specify idempotency conditions and how to handle repeated runs.
Review needs-attention items and run history regularly; do not rely only on system notifications.

Current limitations

No cron expressions, one-time schedules, end dates, attachments, or explicit skill selection.
No separate stop button for an active run and no separate needs-attention inbox.
No user setting for history retention or cleanup policy.
Native notifications have no in-app reminder fallback. When notifications are selected repeatedly in quick succession, only the last open request may be retained.