Scheduler

Scheduler runs a prompt on a schedule, without a conversation. Each job is a headless agent run in a workspace you choose with a model you choose — a nightly test summary, a Monday dependency check, a periodic sync of notes into Brain.

Open it from the app rail or the menubar. Scheduler opens as the foreground main app. Creating or editing a job opens an editor overlay within that app.

The one rule

Jobs only run while Minnow is running. Hidden in the system tray counts as running — that is the normal case, since closing the window hides to tray by default. Fully quitting stops the scheduler.

Minnow does not install an OS-level scheduled task, and it does not backfill runs it missed while closed. If a job must survive reboots, enable Launch Minnow at startup under Settings → General → Desktop app.

Creating a job

Field	Notes
Label	How it appears in the list and in notifications; up to 120 characters
Prompt	What the agent should do each run. Treat it as a full brief, up to 32,000 characters.
Schedule	Interval or cron
Mode	The operating mode the run uses
Work agent	Optional role — researcher, reviewer, and so on
Provider / model	Which model runs it
Workspace	The project folder. Defaults to a scheduler workspace in your Minnow home.
Channels	Where results are announced
Enabled	Pause without deleting

Schedules

Interval takes forms like 60s, 5m, 2h. The minimum is 60 seconds — anything shorter is rejected.

Cron takes a standard five-field expression evaluated in your local timezone. Invalid expressions are rejected when you save, not silently at 3 a.m.

Expression	Meaning
0 9 * * 1-5	09:00 on weekdays
30 2 * * *	02:30 daily
0 */4 * * *	Every four hours

The next run is computed from now; missed runs are not queued up and replayed.

Watching GitHub issues

Choose GitHub issue watcher as the job type. Enter owner/repository, choose its local checkout, select a model, and set the polling schedule. The checkout's origin fetch and push URLs must both point to that repository on GitHub.com. Install and sign in to the GitHub CLI (gh auth login) with permission to comment, push branches, and create pull requests.

The watcher processes open issues with the minnow label, including issues already labeled when the job starts. It handles one issue at a time per repository:

1. A planning agent researches and triages the issue in a separate worktree. Optional Additional guidance supplies repository-specific constraints.
2. An Orchestrator board implements the plan with Builder and Tester agents.
3. When every task has merged into the board's integration branch and its final test passes, Minnow pushes that branch and opens a PR against the repository's default branch. The PR includes the board's implementation and validation report.
4. GitHub issue comments announce planning, implementation, failures needing attention, and the completed fix with its PR link. PRs remain open for your review and merge.

The job's Issues button shows claimed issues, board identifiers, errors, and PR links. Open board opens its implementation and test activity. Retry requeues a blocked issue for the next poll; Run now checks immediately. If a board failed, review and rerun its failed work in Code's Boards surface before retrying the watcher. Interrupted planning requires Retry. Running boards resume on the next poll after a restart. Polls with no change stay quiet.

Claims survive restarts and job deletion, so a completed issue is not processed again while its label remains. Retrying publication discovers an existing PR before creating another one. Removing the label or closing an active issue stops its board on the next poll. Disabling a watcher pauses polling and PR publication; it does not stop a board already running. Stop that board from Code when needed.

Repository and workspace are fixed after creating a watcher. A watcher with active work cannot be deleted; disable it to pause. Deleting a watcher retains its claim records, including blocked issues. Planning worktrees and board artifacts remain available for inspection. All watcher records are stored under scheduler-runs/github-watch/ in your Minnow home.

Writing a prompt that works unattended

Nobody is there to answer a question or approve a tool. That changes how you write:

• Be explicit about the output. "Run the test suite and write a three-line summary naming any failing files" beats "check the tests".
• Check your permissions first. Scheduler automatically allows tools set to Ask, without an approval prompt. Tools set to Off remain disabled, and mode and tool restrictions still apply. See Tools and permissions.
• Provide the needed inputs. Questions cannot be answered during a scheduled run; ask_question returns a non-interactive error. Browser tools that require the desktop browser are unavailable to the headless job.
• Say where results go. "Append findings to a Brain page called Nightly build" gives you something to read tomorrow. Otherwise the output lives only in run history.
• Set the workspace deliberately. Wrong workspace means the right prompt operating on the wrong files.

Run history

Each job keeps its runs: start and finish times, status (running, completed, failed, timeout, cancelled), exit code, output, and errors. Runs persisted as chats can be reopened and read as conversations.

Run history retains the most recent 16,000 characters of output and errors. Earlier verbose output is discarded while the job runs, so a noisy child process cannot grow Minnow's memory without bound.

Notifications reach the menubar bell; Settings → General → Notifications controls whether background-job notifications appear and whether they make a sound.

Jobs live in scheduler.json and runs under scheduler-runs/ in your Minnow home.

Scheduler or /loop?

	Scheduler	/loop
Runs in	A headless job	One chat, keeping its context
Needs	Minnow open	Minnow open and that chat idle
Good for	Reports, checks, syncs	Iterating on something until it is right
Keeps history	Yes, per run	It is the conversation

See Skills and slash commands.

Troubleshooting

Symptom	Check
Never ran	Was Minnow open? Is the job enabled? Interval at least 60 s?
Runs but does nothing	Read the output and errors in run history. Is a needed tool Off, restricted by the mode, or unavailable in a headless run? Did the prompt require an answer from you?
Failed	Read the run history message. Does the model still exist? Does the workspace path still exist? Individual tool errors may be handled by the agent; they do not always fail the entire run.
Touched the wrong files	The workspace on the job

Related

• Tools and permissions
• Models app
• Troubleshooting