> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mka1.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Scheduled tasks

> Run recurring project checks and resume a local coding conversation later.

export const ScreenshotCrop = ({src, alt, width, height, x = 0, y = 0, cropWidth = width, cropHeight = height, maxWidth = "100%"}) => <div className="not-prose" style={{
  position: "relative",
  overflow: "hidden",
  width: "100%",
  maxWidth,
  margin: "0 auto",
  aspectRatio: `${cropWidth} / ${cropHeight}`
}}>
    <img src={src} alt={alt} width={width} height={height} style={{
  position: "absolute",
  display: "block",
  margin: 0,
  maxWidth: "none",
  width: `${width / cropWidth * 100}%`,
  height: "auto",
  left: `${-x / cropWidth * 100}%`,
  top: `${-y / cropHeight * 100}%`
}} />
  </div>;

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

| Schedule | Configuration | Example |
| - | - | - |
| Once | Date and time. | Recheck a test result this afternoon. |
| Interval | Start time, interval in minutes, and a required run limit. | Run a check every five minutes, three times. |
| Hourly | Minute within each hour. | Inspect a local build log at minute 15. |
| Daily | Time of day. | Run the test suite each morning. |
| Weekly | Day and time. | Summarize repository changes on Friday. |

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.

<Frame caption="A daily test review with an explicit prompt, project, permission mode, and run time.">
  <ScreenshotCrop src="/images/mka1-code/guides/schedules.jpg" alt="Daily test-review schedule form set to 9 AM" width={2720} height={1660} x={1025} y={70} cropWidth={1110} cropHeight={1240} maxWidth="100%" />
</Frame>

## 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](/docs/mka1-code/troubleshooting).