Scheduled Tasks
CodeBuddy Code supports creating and managing scheduled tasks within a session. You can set up tasks that execute instructions on a recurring schedule or trigger a one-time action at a specific future time. Common use cases include: periodically checking build status, polling for task completion, setting reminders at specific times, and more.
Note: Scheduled tasks created through conversation are session-scoped by default and are automatically cleared when CodeBuddy Code exits. When creating or editing a task in the Web UI, you can enable persistence so the task remains active after a restart.
Creating Recurring Tasks with /loop
/loop is the most convenient way to create recurring tasks. Simply specify a time interval and the instruction to execute, and the system will automatically convert it into a cron expression and create the task.
Syntax
/loop [interval] <instruction>| Parameter | Description |
|---|---|
interval | Optional. Supports s (seconds), m (minutes), h (hours), d (days). Defaults to 10 minutes if omitted |
instruction | Required. The content to execute each time the task triggers — can be natural language or a slash command |
Common Examples
Check CI/CD pipeline status:
/loop 3m Check if the pipeline has finished and report the resultRun unit tests on a schedule:
/loop 30m Run the unit tests and let me know if any test cases failSummarize code review backlog every hour:
/loop 1h Check if there are any new PRs that need my reviewUse with custom commands:
/loop 10m /check-buildDescribe frequency in natural language (append every at the end):
Monitor API response time every 8mCheck deployment status every 25mDefault Behavior When Interval Is Not Specified
If you provide only the instruction without a time interval, the task triggers every 10 minutes by default:
/loop Check if the backend service is responding normallyAutonomous Interval Adjustment Per Cycle
After each trigger of a /loop task completes, the AI autonomously determines whether the next cycle should: trigger earlier, trigger later, maintain the original interval, or terminate the loop entirely. For example, with a task like "check if the pipeline has finished," if the pipeline is still running, the AI may decide to shorten the next interval to get results faster; if the pipeline has already finished, the AI may decide to end the loop.
This adjustment is automatic and requires no manual intervention. The loop still lasts at most 3 days, and you can manually end it at any time as described in Cancel a Task.
Creating One-Time Reminders
If you only need a reminder at a specific future time, you can describe it in natural language:
Remind me at 4:30 PM to sync today's progressCheck the build task output in one hourGenerate a daily work report for yesterday at 9 AM tomorrowThese tasks trigger once at the specified time and are automatically deleted after execution.
Managing Existing Tasks
View All Current Tasks
What scheduled tasks do I have right now?The list includes the task ID, execution frequency, task type (recurring / one-time), and the associated instruction.
On the task page of the Web UI, you can also edit task configuration directly, pause or resume tasks, and expand a task to view its recent execution status, start time, duration, failure reason, and the execution process, session, and run ID. When a scheduled task fires, a corresponding trigger record appears in the conversation timeline.
Cancel a Task
Cancel the deployment check scheduled taskOr cancel by task ID:
Delete the scheduled task with ID xxxUnder the hood, these correspond to the CronList and CronDelete tools, which can be operated through conversation without needing to remember specific commands.
Task Execution Mechanism
Execution Timing
When a task is due, it enters a queue and starts executing once the session is idle. Each task keeps at most one queued or running instance at a time; if the next scheduled run arrives while the previous instance has not finished, that trigger is skipped rather than queued again. Durable tasks use cross-process atomic claims to isolate execution; once the daemon is ready, regular instances stop durable scheduling and release the leader lock so the daemon can take over, and executions that have already been claimed are not started again by the new owner.
Which Session Runs the Task
- Durable tasks (
durable): Each task has its own dedicated task session and is no longer injected into the conversation you are using. The session ID is deterministically derived from the task ID, so the CLI, TUI, Web UI, and daemon all point to the same session for a given task: the number of sessions equals the number of durable tasks and does not grow with executions or process restarts. A task session is an ordinary session that you can open to view, continue chatting in, or delete. - Current-session-only tasks (
/loop, orCronCreatewithoutdurable): Still injected into the session that created them; semantics are unchanged.
Time Jitter
The system adds a small random offset to task trigger times to prevent congestion from many tasks firing simultaneously:
- Recurring tasks: Delayed by up to 10% of the cycle duration (capped at 15 minutes)
- One-time tasks: For tasks set to the hour or half-hour, may trigger up to 90 seconds early
For example, a task set to run every hour may actually trigger randomly within 0–6 minutes after the hour.
Auto-Expiration
Recurring tasks automatically expire and are deleted after 3 days, with one final trigger before expiration. If you need tasks to persist longer, you can recreate them after expiration or use an external scheduling solution (such as GitHub Actions).
Cron Expression Reference
For precise schedules like "every Monday at 10 AM" or "the 1st of every month," simply describe your requirement to the AI, and it will automatically convert it to a cron expression and create the task:
Generate a weekly work plan every Monday at 10 AMOn the 1st of every month, compile last month's code commit statistics grouped by contributorEvery Friday at 5:30 PM, remind me to sync progress and update task statusEvery day at noon, check if there are any PRs awaiting my reviewOn weekdays at 9:15 AM, list yesterday's unmerged PRsThe AI response will include the actual cron expression and execution frequency used, so you can confirm whether it matches your expectations.
Format:
Minute Hour Day Month WeekdayCommon expressions:
| Expression | Meaning |
|---|---|
*/5 * * * * | Every 5 minutes |
*/15 * * * * | Every 15 minutes |
0 * * * * | Every hour on the hour |
0 9 * * * | Every day at 9 AM |
0 9 * * 1-5 | Weekdays at 9 AM |
0 0 1 * * | Midnight on the 1st of every month |
30 18 * * 5 | Every Friday at 6:30 PM |
Field descriptions:
| Field | Range | Special Characters |
|---|---|---|
| Minute | 0–59 | * (any), */N (every N minutes), N,M (list), N-M (range) |
| Hour | 0–23 | Same as above |
| Day | 1–31 | Same as above |
| Month | 1–12 | Same as above |
| Weekday | 0–6 | 0 or 7 = Sunday, 1 = Monday, and so on |
Notes
| Item | Description |
|---|---|
| Session-bound | By default, tasks exist within the session; durable tasks are written to the project directory and restored after CodeBuddy Code restarts. When a ready daemon exists for the same project, the daemon hosts them preferentially |
| Recurring task limit | A maximum of 50 scheduled tasks can exist simultaneously per session |
| Minimum interval | 1 minute (sub-minute intervals are automatically rounded up) |
| Task expiration | Recurring tasks are automatically cleared after 3 days |
| No backfill | Missed tasks during session interruptions are not retroactively executed |
Disabling Scheduled Tasks
To completely disable the scheduled tasks feature, set the following environment variable:
bash
CODEBUDDY_DISABLE_CRON=1 codebuddyOnce enabled, the /loop skill is no longer available, and the CronCreate, CronList, and CronDelete tools are also disabled.