I have a confession. Every Monday morning I tell myself I’ll check for outdated NuGet packages. By Wednesday, I’ve forgotten. By Friday, Dependabot has already opened three PRs that I’ll review “next week.”

What if Claude Code just did that for me? Every morning at 9am, check my packages, run the tests, and tell me what needs attention. No GitHub Actions workflow to configure. No YAML to debug. Just a prompt and a schedule.

That’s exactly what scheduled tasks in Claude Code do.


Three ways to schedule work

Claude Code offers three scheduling options, each with different trade-offs. Here’s the quick overview:

CloudDesktop/loop
Runs onAnthropic cloudYour machineYour machine
Machine must be onNoYesYes
Session must be openNoNoYes
Survives restartsYesYesNo
Access to local filesNo (fresh clone)YesYes
Minimum interval1 hour1 minute1 minute

The short version: use cloud tasks when reliability matters more than local access. Use Desktop tasks when you need your local files and tools. Use /loop for quick polling during a session.


/loop — the quick and dirty option

/loop is the fastest way to schedule something. Type it in any session and Claude starts running your prompt on an interval.

/loop 5m check if the dotnet test run passed and show me failures

That’s it. Claude parses the interval, sets up a background job, and checks every 5 minutes. No configuration files, no dashboards, no setup wizards.

The default interval is 10 minutes if you don’t specify one. You can use s for seconds, m for minutes, h for hours, or d for days. Seconds round up to the nearest minute since the scheduler runs on cron under the hood.

When I use /loop

I reach for /loop during active development. A few examples:

/loop 5m check if the staging deploy finished
/loop 15m check my open PR for new review comments
/loop 30m run dotnet test on the integration test project and summarize failures

You can even loop over other commands:

/loop 20m /review-pr 1234

Each time the job fires, Claude runs the command as if you typed it yourself.

The limitations

/loop is session-scoped. Close your terminal, and all scheduled tasks are gone. Tasks also expire after 7 days automatically. There’s no catch-up for missed fires — if Claude is busy when a task comes due, it waits until Claude is idle, then fires once.

Think of /loop as a temporary assistant during your work session. For anything that needs to survive a restart, read on.


Desktop scheduled tasks — your local automation layer

Desktop scheduled tasks run on your machine but don’t need an open session. You create them in the Claude Code Desktop app, and they fire automatically as long as the app is running and your computer is awake.

The key advantage: they have full access to your local files, tools, and MCP servers. That means they can read your .sln, run dotnet test, check your local Git state, and interact with any tool you’ve configured.

Setting one up

In the Desktop app, click Schedule in the sidebar, then New taskNew local task. You’ll configure:

  • Name: something descriptive like nightly-test-run
  • Prompt: the instructions Claude follows each time
  • Frequency: hourly, daily, weekdays, weekly, or manual

Here’s a prompt I’d use for a nightly test run on an ASP.NET Core project:

Run dotnet test on the solution in the current directory. If any tests fail, 
summarize which projects and tests failed and what the error messages say. 
If all tests pass, just say "All green" with the test count.

Each run creates a new session in the sidebar. You can open it later, see exactly what Claude did, and respond if needed.

Dealing with sleep and missed runs

Desktop tasks only fire while your computer is awake. If your MacBook sleeps through the scheduled time, the run is skipped. When the app starts back up, it checks whether any runs were missed in the last seven days and does exactly one catch-up run for the most recently missed time.

This means a daily 9am task that missed the weekend runs once on Monday morning — not three times. Write your prompts with this in mind. A task scheduled for 9am might actually run at 11am if your laptop was closed.

If you need your computer to stay awake for scheduled tasks, enable Keep computer awake in the Desktop app settings. Closing the lid still puts it to sleep, though.

Permissions without the clicking

Each task has its own permission mode. The smart move: after creating a task, click Run now, watch for permission prompts, and select “always allow” for each one. Future runs auto-approve those same tools without asking.


Cloud scheduled tasks — the one that works while you sleep

This is the big one. Cloud scheduled tasks run on Anthropic’s infrastructure. Your laptop can be closed, your computer off, your phone in airplane mode. Claude still runs your prompt on schedule.

How it works

You create a cloud task on claude.ai/code/scheduled, through the Desktop app (under New remote task), or from the CLI with /schedule. You provide:

  1. A prompt — what Claude should do each run
  2. One or more GitHub repos — Claude clones them fresh each time
  3. An environment — network access, secrets, setup scripts
  4. A schedule — hourly, daily, weekdays, or weekly
  5. Connectors — MCP integrations like Slack, Linear, or Google Drive

Each run starts from your repo’s default branch, does its work, and pushes changes to a claude/-prefixed branch. You review the session on claude.ai, see what changed, and create a PR if it looks good.

.NET use cases that actually make sense

Here’s where it gets practical for .NET developers:

Nightly test suite validation. Your ASP.NET Core project has 400 integration tests that take 12 minutes to run. Schedule a cloud task to clone the repo, run dotnet test, and post a summary. If something broke overnight, you know before your first coffee.

Weekly dependency audit. NuGet packages get vulnerabilities. Schedule a weekly task:

Clone the repo, run dotnet list package --vulnerable --include-transitive. 
If any vulnerabilities are found, create a branch with the updates and push it. 
List what was updated and why.

Claude creates a claude/dependency-updates branch with the fixes. You review the PR.

Daily PR review. If your team has open PRs that sit too long:

Check all open pull requests. For each PR older than 2 days without review, 
summarize what it changes and flag any potential issues. Focus on test coverage 
and breaking changes.

Connect a Slack connector and Claude can post the summary directly to your team channel.

Post-merge documentation sync. After PRs merge, API docs drift from reality:

Compare the public API surface of the Controllers/ directory against the docs in docs/api/. 
Flag any endpoints, parameters, or response types that are documented but don't exist, 
or exist but aren't documented.

What cloud tasks can’t do

Cloud tasks don’t have your local files. They clone your repo fresh each time. That means no access to local databases, no local Docker containers, no files outside your repo. If your tests need a running SQL Server or Redis instance, cloud tasks aren’t the right fit — use Desktop tasks instead.

Cloud tasks also can’t push to arbitrary branches by default. They’re restricted to claude/-prefixed branches unless you explicitly enable unrestricted branch pushes for a repo.


Choosing the right option

After using all three, here’s my rule of thumb:

Use /loop when you’re in a session and want to poll something. Deployment status, PR comments, build progress. Quick, disposable, zero setup.

Use Desktop tasks when the work needs your local environment. Running dotnet test against your actual solution with local dependencies, checking files that aren’t in Git, using local MCP servers.

Use cloud tasks when reliability matters. Nightly audits, daily reviews, weekly reports. Things that should happen whether you’re at your desk or not.

The three options complement each other. I use /loop during the day, a Desktop task for my morning test run, and cloud tasks for the weekly dependency audit. Between them, the repetitive work I used to forget about just happens.


Try it yourself

Start with /loop — it takes five seconds:

/loop 10m run dotnet test and tell me if anything broke

Watch it fire a couple of times. Get comfortable with the idea that Claude is doing work in the background while you focus on something else.

Then set up a Desktop task for something you always forget to do. The daily test run. The dependency check. The PR review you keep putting off until Friday.

Once you trust the pattern, create a cloud task for the work that needs to happen even when your laptop is closed. That’s when it clicks: Claude Code isn’t just an assistant you talk to. It’s an assistant that works for you around the clock.

The NuGet vulnerability you would have caught next month? Claude found it this morning.