Scheduled tasks

Schedule a test check or ask the agent to return to a local conversation later. Use a prompt that names the command, the project, and what to report, so each run has enough context to do useful work.

​

Create a scheduled task

Use Scheduled tasks for one-time or recurring work, such as running a project’s tests each morning and summarizing failures:

1. Open Scheduled tasks and create a task.
2. Enter a prompt, project folder, model, and permission mode.
3. Choose when it runs: once, at an interval, hourly, daily, or weekly.
4. Check Next runs, including the time zone, then save the task. Use Run now to check its behavior before the first scheduled run.

Each standalone scheduled run starts a separate conversation. Put the instructions it needs in the saved prompt, including the command and the result you want:

Run npm test. Report failing test names and relevant errors. Do not modify files.

Choose the project folder so the command runs in the right repository. After a run, open Run history and select its session to inspect the command output. Use the Problems filter to find runs that need investigation. If a task shows Needs attention, open it and answer the question or approval request. Pause affects future launches; Stop cancels an active run.

​

Choose a frequency and run limit

For hourly, daily, and weekly schedules, leave Run limit empty to continue without a limit. Times use your computer’s time zone unless you set another under Advanced → Timezone. Check Next runs before saving, especially when the task should follow another region’s time.

​

Write a self-contained prompt

A standalone run starts a fresh conversation, so its prompt should name the input, action, expected output, and any restriction. For example:

Run npm test in this project. Report the command, whether it passed, and each failing test with its error. If dependencies are missing, report the setup failure. Do not install packages or modify files.

Select the actual project folder. With No project, each standalone run gets a new working folder and will not have your repository. Use Run now to verify the prompt, environment, and approval behavior before relying on the schedule.

​

Manage an existing schedule

Click a task name to edit its definition. Run now starts a manual run without changing the next scheduled time or consuming an automatic run. Pause prevents future launches; Stop cancels the current run. Deleting a schedule prevents future launches but leaves existing sessions and run history, and does not stop an active run. Open Run history, filter by task, and use Problems to find failures or runs that need attention. Read the associated session for the actual command output. A Completed task has exhausted its automatic runs; create another schedule if you want more occurrences.

​

Schedule a follow-up

During a local Code session in the desktop app, you can also ask the agent to return to the task later. These follow-ups are unavailable in the CLI, VS Code extension, and cloud sessions. They resume the original conversation with its history and workspace. For example:

In ten minutes, run npm test again and report whether the checkout tests pass. Do not modify files.

​

When scheduled work runs

Scheduled work uses the saved permission mode, so a run can still pause for approval. The desktop app must be running when the task is due. Quitting the app stops scheduling, and reopening it does not replay missed occurrences. Closing only the main window can leave the app running when schedules are enabled. The run history shows skipped runs, failures, and requests that need your attention.

​

Understand skipped runs

Runs from the same schedule or project do not overlap. If a prior run is still active, a new occurrence can be skipped. Missed, failed, canceled, and skipped automatic occurrences count toward the run limit; paused time does not. A missed one-time run completes without being replayed when the app reopens. If a run needs approval, open its session and answer the request. Changing the schedule to avoid prompts should be a deliberate permission choice, not a way to hide an unresolved environment or command error. Continue with Usage and troubleshooting.