Claude Code Scheduled Tasks: How I Set Up a Daily Review in the Desktop App

Claude Code scheduled tasks are recurring jobs you create from the Routines page in the desktop app. Each task starts a brand-new Claude Code session at the time and frequency you set, in a folder you pick, with its own permission mode and model. When it fires you get a desktop notification and the session appears under a Scheduled section in the sidebar, where you can read what Claude did, review the changes, or answer a permission prompt. A local scheduled task runs on your machine with full access to your files and tools, which also means it only runs while the app is open and the computer is awake. The same Routines page can create a remote routine that runs in the cloud when your machine is off, but that is a different thing with different tradeoffs, and this post is about the local kind.

I set two up the day the feature landed: a weekday morning review of the previous day's commits on the club site, and a Monday dependency check. The setup took less time than writing this paragraph. The first week of runs is where I learned what the docs meant, and that is the useful part of this post.

Claude Code has three schedulers and they are not interchangeable. The CCC Three-Clock Rule is how I keep them straight: pick the scheduler by what has to be true at the moment the task fires. If a session has to be open, use /loop. If your machine has to be on but nothing else, use a desktop scheduled task. If nothing at all has to be true, use a cloud routine. Anthropic's comparison table says the same thing in more columns.

The reason I chose desktop tasks for the daily review is the local-files row. The review needs the actual working copy, my MCP config, and the allow rules I already set up, and a cloud routine gets a fresh clone with none of that. The reason I did not use /loop is that it is session-scoped and recurring loops expire after seven days, which is fine for babysitting a deploy and wrong for something I want running next month.

In the Code tab, click Routines in the sidebar (or under the sidebar's More menu), then New routine, then Local. You need Claude Desktop 1.1.5368 or later; older builds do not show local tasks at all. There are four fields, and the Instructions box is the one that matters.

You need a trusted folder before the task will save; Desktop prompts you to trust it if you have not. You can skip the form entirely and just type the request into a session. "Set up a daily code review that runs every morning at 9am" creates a recurring task, and "remind me at 3pm tomorrow to check the deploy" creates a one-time task that disables itself after it fires. I used the form the first time so I could see every field, and I have used plain language since.

Three things went sideways, and every one of them is covered in the docs if you read them the way I did not.

The lid. Desktop checks the schedule every minute while the app is open, adds a small deterministic delay to stagger API traffic, and starts a fresh session when a task is due. If the computer is asleep at that moment, the run is skipped. I closed the laptop on a Tuesday evening and the Wednesday review did not happen until I opened it that night, because Desktop then runs exactly one catch-up for the most recently missed time within the last seven days and throws the rest away. There is a Keep computer awake switch under Settings, Desktop app, General, but the docs are clear that closing the lid still sleeps the machine. My fix was in the prompt, not the settings: "Only review commits since the last run. If it is after 5pm, skip the review and post a summary of what was missed." Now a late run is a short run, not a wrong one.

The stall. The second run needed to execute a command I had not approved, and because the task was in a permission mode that asks, it sat in the sidebar waiting for me. That is the correct behaviour, but it is not what you want at 8am. The fix is the one the docs recommend: click Run now right after you create the task, watch for every prompt, and pick always allow on each. Future runs auto-approve the same tools, and you can review or revoke those approvals from the task's Always allowed panel.

The half-finished work. By default a scheduled task runs against whatever state your working directory is in, including uncommitted changes. My Thursday review cheerfully critiqued a feature I was midway through, because I had left it uncommitted overnight. The worktree toggle on the task fixes this: each run gets its own isolated Git worktree, the same way [Claude Code worktrees](/blog/claude-code-worktrees) isolate parallel sessions. Turn it on for anything that reads or edits code.

Each scheduled task has its own permission mode, set when you create or edit it, and the allow rules in your ~/.claude/settings.json apply to scheduled sessions too. So the boring answer is: put the commands the task needs into your allow rules once, run it manually with Run now, approve what is left with always allow, and it will not stall again. A task that runs in Manual mode and hits a tool it is not allowed to use waits for you, and the session stays open in the sidebar until you answer.

Every task gets a folder at ~/.claude/scheduled-tasks/<task-name>/ (or under CLAUDE_CONFIG_DIR if you set one) containing a SKILL.md. The file has YAML frontmatter for name and description, and the body is the prompt. Edit the body and the change applies on the next run, which is how I tuned the review prompt without touching the form. The schedule, folder, model, and enabled state are not in that file; change those through Edit on the task's page or by asking Claude.

You can also do all of this by asking. "Show me my scheduled tasks" and "pause my dependency-audit task" both work from any Desktop session.

Start read-only. A scheduled task can edit files, run commands, commit, and open pull requests, and the temptation is to schedule the whole pipeline on day one. Do not. Schedule the two jobs that produce a report you would read anyway, run them for a week, then decide what to let them touch.

If your project already runs in CI, the same two jobs can run there on a schedule trigger instead, which is what [Claude Code GitHub Actions](/blog/claude-code-github-actions) is for. I run mine on the desktop because the review needs my local MCP servers and my allow rules, and because I like opening the app in the morning to a session that has already done the reading.

The right cadence and the right prompt come from watching a week of history, not from guessing. Set the two tasks up, leave the worktree toggle on, and read the skipped entries as carefully as the successful ones.