Schedule Claude Code tasks: Cloud, Desktop or /loop
Choose Cloud, Desktop or /loop for a Claude Code task, test file access and a scheduled run, then check sleep, session recovery and cancellation behavior.
Contents

Start with two questions: where are the inputs, and must the task run while your computer is off? Local files require access to your machine. Running a repository check without your laptop requires a separate cloud environment. For brief polling during your current work, /loop can be enough.
Saving a schedule does not prove that the task can read its inputs, execute or leave a verifiable result.
Choose the execution environment
| Requirement | Cloud routine | Desktop Local task | Session /loop |
|---|---|---|---|
| Runs in | Cloud environment | Your computer | A running Claude Code session |
| Computer can be off | Yes | No | No |
| Local inputs | Must be available in the cloud environment | Supported | Supported |
| After restart | Schedule persists | Schedule persists | Eligible unfinished, unexpired tasks return on resume |
A normal Cloud run uses a clone of the selected repository, not your current local folder. Desktop accesses local files, but the application must stay open and the computer awake. See the Desktop documentation for these requirements and working-directory selection.
Test one manual run first
Use a small test project with a nonsecret README.md; keep a copy before running anything. For Cloud, commit that file to the selected test repository. Use the same prompt:
Open only README.md in the selected project.
Return its first nonempty line and the number of level-two headings
starting with "## ". If the file is missing, report that.
Do not modify files, run shell commands or send messages.
Start the response with SCHEDULE_CHECK.
Check the line and heading count yourself, and verify that no files changed. This tests input access and task clarity. Prompt restrictions express intent; actual capabilities depend on environment settings and tool permissions.
If the manual run cannot read the file, scheduling will not fix it. Check the project, access and path before testing a trigger.
Use an explicit /loop for short checks
In your active CLI session, provide an interval and a concrete prompt:
/loop 5m Read only README.md. Reply with SCHEDULE_CHECK and the first nonempty line. Do not change files, run commands or send messages.
Record the confirmed interval and task ID. Wait for one automatic response, then ask Claude to list scheduled tasks and cancel that exact ID. List them again to confirm removal.
Do not treat the interval as an exact timer: scheduling allows jitter, and a busy session executes later. Recurring tasks expire after seven days. A new conversation does not inherit them; --resume or --continue restores only eligible unexpired tasks. See the /loop guide.
Always provide the test prompt. Bare /loop may start built-in maintenance of the current work instead of your README experiment.
Use Desktop for local files
In Routines, create a Local task, choose your test folder and paste the same prompt. Start with Run now, inspect the result and any permission requests, then enable the schedule and verify a separate automatic run in history.
After sleep, Desktop can run one missed task on wake: it considers the latest missed time within seven days, not every missed iteration. Define which data a late working task should process. A daily check could use changes for a specified date rather than treating execution time as the start of a new reporting day.
Set the task to Paused after the experiment. Distinguish manual runs, scheduled runs, skips and permission waits in history. Run now tests execution; it does not by itself verify the schedule.
Use Cloud when your laptop can be off
If your account has Cloud routines, create one in Routines, select the test repository and environment, add only necessary connectors, and set the prompt and schedule. Test Run now, then inspect a separate scheduled session.
Cloud routines execute autonomously without normal in-run permission prompts. Repositories, network access, environment variables and connectors define access. A first README test does not need work email or publishing access. See the Routines guide.
Turn off recurrence after testing. Keep the ID, expected and actual times, result link and any skip reason. Once these are clear, replace the test prompt with your real task and recheck inputs, permissions and results. Cloud versus Desktop decides where work runs; the task itself still needs validation.