Claude Cowork Scheduled Tasks Without Your Laptop? (2026)

If you only read one section, read this one.

What the July 7 change provides: Cowork on the web at claude.ai and on iOS and Android in beta, with remote sessions as the new execution model — the agent loop running in isolated cloud sandboxes on Anthropic infrastructure, state synced to your account, and scheduled tasks firing server-side regardless of your device. Rollout order: Max subscribers first.

What I actually found on a Pro plan, desktop app, real client project: my scheduled task displays a 'Runs on this computer' badge next to its Active toggle — and the badge governs everything. The test matrix, in full: scheduled run with the laptop asleep — Skipped, visible only in task history. Manual 'Run now' with the machine awake — success, about 1% of a session. Scheduled run with the laptop deliberately left awake overnight — success, on time, correct output. That is the pre-July architecture, functioning exactly as the pre-July guides described it.

The thirty-second diagnostic this article exists to give you: open any scheduled task and read the badges next to the toggle. 'Runs on this computer' means local — the machine must be awake and the app running at execution time, or the run silently skips. A session living on the web/mobile surface without that local badge means server-side — the device can sleep. Check the badge, not the headlines.

What didn't change either way: Cowork tasks still deserve file-safety caution (back up folders before granting access), skipped runs are still silent, and task history is still where the truth lives.

The practical takeaway in one line: server-side scheduling is real, but it arrives with the remote-session rollout, not with the news cycle — so verify which architecture you're on before you trust a schedule with anything that matters.

It's worth being precise about the old behavior, because understanding it explains both the workaround culture and why the new architecture is such a big deal.

Cowork shipped as a desktop-app product — research preview on macOS for Max users in January 2026, general availability on macOS and Windows in April. Execution was local: the agent worked on folders you explicitly granted, on your machine, inside the running app. That model had genuine virtues — your files never left your computer, and you could watch every step — but it made automation hostage to your hardware. A scheduled task was a promise your laptop had to be awake to keep. Sleep mode, a closed lid, an OS update reboot, or simply not having the app open meant the run was skipped, and the standard advice was to check task history regularly to find out which executions silently didn't happen.

The workarounds people built were rational for that world: dedicated desktop machines left running around the clock to host the automation, GitHub-based syncing to move outputs off the always-on box, folder setups split across machines. I ran a version of this myself — my ERP-export summarizer only ran on days I remembered to leave the office machine on, which is a polite way of saying it ran about 60% of the time.

Here's the part that matters for anyone landing on this article from a search: that entire body of advice — accurate, well-tested, widely published between February and June 2026 — describes the local architecture, and whether it still applies to you depends on which architecture your tasks run on. The July 7 change introduced the server-side alternative; it did not flip every existing setup over to it. Mine included: as my test matrix below shows, a Pro-plan desktop task in late July still runs local, badge and all. If you arrived here trying to diagnose 'Cowork scheduled task not running,' the first question isn't whether anything is broken — it's which of the two architectures you're actually on, and this article gives you the thirty-second way to tell.

The announcement everyone reported was platform expansion: Cowork arriving on the web at claude.ai and on mobile for iOS and Android, in beta, with Max plan subscribers first in the rollout. That's real and useful — Cowork stopped being a place you go (the desktop app) and became a thing your account has, reachable from whatever screen is nearby.

But the platform story is downstream of the architecture story. Cowork now runs in two modes, and remote execution is the default. In remote mode, the agent loop and the code it executes run inside isolated cloud sandboxes on Anthropic infrastructure — not on your device. Those sandboxes have no outside network access unless you grant it. Your files and the session's state are saved to your Claude account and synced, which produces the three behaviors that change daily use:

First, continuity: a session started on your desktop keeps running when you close the laptop, because the laptop was only ever a window into it. Second, cross-device access: the same session is visible and steerable from the web and the mobile app — you can assign tasks and check progress from your phone through a persistent agent thread, which turns the commute into a supervision window. Third, and biggest: scheduled tasks execute server-side, on Anthropic's clock, with no device online at all.

One more structural change worth noting: Chat and Cowork now share a single home for Projects and Artifacts across both surfaces, so outputs from an overnight scheduled task land somewhere your normal Claude workflow already looks — no more remembering which machine's folder the report went to.

The framing I'd offer: January-to-June Cowork was a local agent with a scheduler bolted on. July Cowork is a cloud service with an optional local mode. Almost everything else in this article follows from that inversion.

Mechanically, scheduling looks the same as before: you define a task, set a cadence — recurring or on-demand — and Cowork runs it. What changed is where 'runs it' happens and therefore what can go wrong.

Server-side execution means the run fires on Anthropic's infrastructure at the scheduled time regardless of your device state. The failure modes that dominated the old task-history audits — machine asleep, app closed, laptop lid down — are gone as a category. What remains are the failure modes of any cloud automation: the task itself erroring, permissions the sandbox doesn't have, and outputs that complete successfully but aren't what you wanted. That last one deserves emphasis, because unattended-and-successful is a more dangerous combination than attended-and-failed. A scheduled task that confidently produces a wrong client report at 7:00 AM every morning is worse than one that visibly doesn't run.

That's why my recommended adoption path is deliberately boring. Start with one weekly task whose output you'd review anyway — a Monday summary, a folder cleanup with a dry-run flavor. Then run the badge check before anything else: if your task says 'Runs on this computer' (as mine does on Pro), the device-closed test is already answered — my asleep-time run shows a bare 'Skipped' entry in history, and yours will too. If your task runs server-side, let it fire at least twice with your device closed and confirm both runs in the task history before believing it. Only then graduate to daily cadences, and only then to tasks whose output goes anywhere near a client.

Two scheduling-specific notes from my testing. Outputs land in the synced session space shared with Chat and Cowork's Projects/Artifacts home, so decide up front where each task's artifacts should live or you'll accumulate an overnight junk drawer. And remember network isolation: a scheduled task that needs to fetch anything from the outside world needs that access or the relevant connector granted at setup time — a task that worked interactively (because you approved things live) can fail on schedule when nobody's there to approve.

The old operational question was 'how do I keep a machine awake for this?' The new one is better but real: which mode does each task belong in? Here's the table I now run tasks through, followed by the reasoning.

Same philosophy as every review on this site: no synthetic demos, my actual setup, results reported whether they flatter the product or not. And this test's results mostly don't flatter the launch coverage — which is exactly why they're worth publishing.

The setup: Pro plan, Windows desktop app, Sonnet 5, pointed at a real client project (a 3D real-estate CRM for agents). The scheduled task: a daily 7:30 AM changelog — scan the project folder for files changed in the last 24 hours and append a dated summary line to cowork-outputs/changelog.md, writing 'No changes' on quiet days. Deliberately boring, exactly as the adoption path above prescribes.

The discovery came before the first run: the task's detail page shows a badge next to its Active toggle — 'Runs on this computer.' Every launch story I'd read about server-side scheduling, and here was my own task declaring itself local in plain text. The three runs that followed confirmed the badge means precisely what it says.

Run one — laptop asleep at 7:30 AM: the history shows the run at 7:32 AM with a single word next to it: Skipped. No notification, no error, no retry. If I hadn't gone looking in task history, I'd have assumed it ran.

Run two — manual 'Run now,' machine awake: complete success. Four commands executed, changelog.md created with the correct dated entry, roughly 1% of a session consumed. The task itself was never the problem.

Run three — scheduled, laptop deliberately left awake overnight: success, on schedule. Three commands, a file read, a file edited, 'No changes found... appended for 2026-07-26' — textbook. Same ~1% cost.

That's the complete matrix: asleep = skipped, awake = works, manual = works. My Pro desktop is running the pre-July architecture with a label on it, while the server-side version lives on the remote-session beta that's rolling out Max-first. Two honest limits on this test: it's one plan, one machine, one week of late July 2026 — rollout state may differ by the time you read this, so run the badge check on your own setup rather than trusting mine. And I couldn't yet test the remote path itself — cross-device steering, sandbox permissions, remote file access — for the simple reason that my plan hasn't received it; when it arrives, that's a follow-up post, and the local-vs-remote table below is the framework it will slot into.

One more cost note, because it inverts the usual Cowork warning: at ~1% of a session per run, a daily local scheduled task is nearly free — seven runs a week rounds to a single heavier Cowork task. For lightweight automation like changelogs and folder checks, the meter is not the risk. The silence is.

Three pieces of fine print keep this from being an unqualified rave, and all three are the kind of detail launch coverage skipped.

First, beta scope. Web and mobile Cowork shipped as a beta rolling out to Max subscribers first. If your plan doesn't show it yet, you're not misconfigured — you're queued. Rollout order, plan coverage, and the beta label itself are exactly the categories of fact that change between publish and your reading; treat any specific claim about 'who has it today' as perishable and check the support documentation for the live answer.

Second, sandbox boundaries. Remote sessions run isolated with no outside network access unless granted. Security-wise this is the right default — an agent processing documents you didn't write is an agent exposed to prompt injection, and a sandbox that can't reach the internet limits the blast radius. Practically, it means the mental model from local mode ('Cowork can do whatever I could approve') doesn't transfer. Remote tasks operate inside what you've explicitly granted, and failures caused by missing access can masquerade as the model being bad at the task. When a remote task flops, check permissions before you blame the agent.

Third — and I'll keep repeating this until usage panels grow warning labels — the meter. The old architecture had a natural rate limiter: automation only ran when your machine was on. Server-side scheduling removes that limiter along with the limitation. Tasks now run reliably, invisibly, and at full token cost, every scheduled slot. Heavy Cowork use was already known to draw down Pro allocations quickly, and Auto mode's parallel safety classifiers add overhead per run. If you want to price your real workload before that bill lands, I measured it in Cowork's 2x usage window and how to size your scheduled-task burn. A daily schedule you set and forget in July is a usage line item you'll meet in your limits by August. Check task history and your usage panel weekly, at minimum, until you know your automation's real appetite.

And the standing Cowork caution predates all of this and survives it: users have reported Claude modifying files without prior review. Back up any folder that matters before granting access — doubly so now that the agent works while you sleep.