How do I schedule recurring tasks for an AI coding agent?
To schedule recurring coding-agent tasks, ask Omnigent in plain language, such as “run this every weekday at 9am Chicago time,” or use the scheduled-tasks UI. Specify the task, repository, and expected output, then review the schedule and execution settings. Test a run before leaving it unattended, and check the actual result.
Last checked against Omnigent v0.19.0 · 2026-10-23
What does a recurring coding-agent task need?
A recurring coding-agent task needs explicit inputs, a checkout revision or update strategy, an output location, and a stopping condition. Write it for a new session, not as a continuation of a conversation it cannot see. Keep credentials and permissions narrow. Decide what happens if an earlier run is still working; recurrence alone does not resolve concurrent writers.
For example: “Run the parser unit tests in this checkout, summarize failures with test names, and stop. Do not edit files or push changes.” Record where the report should appear and who checks failures. The instruction describes intent; a read-only execution boundary needs separate enforcement. Test access to the repository and dependencies before leaving it unattended.
How should I choose a scheduler for coding-agent tasks?
Choose a coding-agent scheduler by execution environment and the record you need: cron for a maintained machine, CI for repository jobs with retained logs, a hosted scheduler for cloud execution, or a session scheduler for inspectable conversations. With cron or a system timer, you supply the working directory, logs, overlap controls, and failure reporting. A sleeping laptop cannot run its scheduled process just because the calendar time has arrived.
CI fits repository-triggered work when you already have runner setup, secrets management, and retained job logs. GitHub Actions supports scheduled workflows, but warns that scheduled events can be delayed or dropped under load. Treat it as a job scheduler, not an exact-time service.
Hosted options also exist. Claude Code documents cloud scheduled tasks, currently a research preview. Codex documents scheduled tasks with local or web execution. Local tasks still need the computer and app running; hosted execution needs its own repository or connected inputs. Compare these environment requirements before choosing a scheduler.
Omnigent’s session scheduler is useful when you want each run to become an inspectable conversation, with its agent settings and follow-ups, rather than only a process log. Compare host selection, timezone behavior, approval handling, and missed-run behavior. A cloud target is not automatically a copy of your laptop’s checkout.
How do I schedule recurring coding-agent tasks in Omnigent?
Ask Omnigent to create the recurring coding-agent task, or open Automations in the sidebar at /tasks and choose New automation. Review the agent, prompt, schedule, and execution target before approving an agent-created task. Use the Active/Paused toggle to pause or resume future runs. The web UI uses your browser’s timezone for creation and preserves an existing task’s timezone when editing. For a different IANA timezone, use the API or agent tools; the API’s default timezone is UTC.
For example, ask: “Every weekday at 9am Chicago time, run the parser unit tests in this checkout, report failures, and do not edit or push files.” The agent prepares the schedule for your approval; check the timezone and next run before confirming. The automation documentation covers recurrence-format details if you need them.
Pin the connected host and repository workspace for checkout-specific work. In the API, workspace without host_id is rejected. Omitting both is valid: the scheduler chooses the owner’s most-recently-active live host and its home directory. A configured managed_sandbox target provisions a fresh sandbox per firing; omit host_id and workspace and arrange the inputs there.
What should I check before leaving coding-agent tasks unattended?
Recurring coding-agent tasks need execution permissions, a verified budget policy, and checks of the actual output as well as run status. Calls to sys_scheduled_task_create and sys_scheduled_task_update always require interactive approval. Scheduling does not waive execution permissions; a prompting permission mode can leave an unattended run waiting. Set max_cost_usd through the API or agent tools; the web dialog has no budget field.
In v0.19.0, budget attachment is best-effort: a missing policy store or attachment error can leave a run without that cap. Verify the policy on the fired session. An attached cap gates new work using recorded costs; in-flight work can overshoot.
POST /v1/scheduled-tasks/{id}/run requests an immediate run without changing recurrence. Inspect its checkout and output. A succeeded status means the turn finished, not that tests passed. An unavailable host records a failed occurrence. Missed fires while the server is down are not replayed. Pause the task while fixing inputs or permissions.