Cowork Moved to the Cloud. Your Agent Now Works While You

By Lazar Milicevic · Published October 8, 2026 · 8 min read

You've started a long agent job, a month of invoices or a few hundred emails to sort, and then your laptop went to sleep and the job died. Anthropic just changed that for Cowork by moving the whole execution environment off your machine. Before you trust it with real files, you need to know what actually moved, what didn't, and where the "closed lid" promise has a catch.

What actually shipped (and the dates that confuse everyone)

Short version: Cowork's model inference and its sandbox VM now both run on Anthropic's servers. Your files stay on your computer, and the desktop app fetches individual files on request. Per secondary coverage of Anthropic's notice, new tasks on Pro and Max plans run in the cloud from October 6, 2026.

Here's the before and after, using Felix Rieseberg's explanation (he works on Cowork at Anthropic). The old version ran model inference in the cloud, but tool calls executed in a virtual machine Anthropic shipped to your computer. That VM existed for capability, safety, and security reasons, and it only mapped in the data you explicitly added to a session. The cost: disk space, battery drain, performance hits, and the one that hurts for real work, close your laptop and the work stops.

In the new version, inference and the VM both run in the cloud. When the VM needs something from your device, like a file, the desktop app handles that as a tool call. Source: Rieseberg's post on X.

The timeline is messier than the headline suggests, so here is what I can confirm and what I can't:

If you're on Team or Enterprise, check Anthropic's Cowork getting-started page for your plan rather than trusting a blog post, including this one.

Why the laptop stopped being the bottleneck

Short version: A cloud session's lifespan is no longer tied to your machine's lifespan. Long-running jobs like reconciling invoices, sorting email into follow-up buckets, or extracting data from PDFs can finish without you babysitting a lid, a battery, or a wifi connection.

Under the old model, any job ran exactly as long as your laptop stayed awake and online. That's fine for a short task. It's a bad deal for a long one. Anthropic's docs now state that cloud tasks run on its servers, work continues if you close your laptop, and you can reopen the same session from any surface (Get started with Claude Cowork).

That's the difference between a toy and a worker. A toy needs you present. A worker takes a brief and comes back with a result.

But read the next section before you plan around "while you sleep."

The caveat: "works while you sleep" depends on where the files live

Short version: A cloud task that only needs connectors (Gmail, Calendar, Drive) can run with the lid closed. A task that needs files in a local folder needs your computer awake with the desktop app open, because that's where the files are.

This is the part most coverage skips. The file handoff is handled by the Claude Desktop app. If the desktop app is offline, a cloud session cannot reach your computer (Use Claude Cowork safely). Claude fetches a copy of just the file it needs, and only while the app is open (Use Claude Cowork on web, desktop, and mobile).

One tester found the practical consequence for scheduled tasks: a task with no folder selected ran in the cloud, and selecting a local folder switched it to run on the computer, only while awake (Aible, via Substack). That's a single blogger's test, so treat it as a strong hint, not a spec. Verify it with your own setup before you build a workflow on it.

So when you design a job, sort it into one of two shapes:

# Shape A: truly lid-closed
inputs: connectors only (email, calendar, shared cloud drive)
runs_when: anytime
good_for: inbox triage, calendar prep, report drafts from cloud docs

# Shape B: needs local files
inputs: a folder on your machine
runs_when: computer awake + desktop app open
good_for: PDF batches, invoice folders, local spreadsheets

If you want Shape B to behave like Shape A, move the source files into a cloud store the connector can reach. That's a one-time reorganization, and it's the real unlock behind "works while you sleep."

The design pattern worth stealing: one door to your data

Short version: Anthropic split the system into a risky part (the sandbox, in the cloud, isolated per session) and a sensitive part (your files, on your device), connected by a single controlled doorway: the desktop app. Every file crossing is a discrete tool call. You can copy that pattern for your own automations.

What Anthropic's documentation and a third-party security guide say about the cloud side:

• The agent loop and code execution run in a per-session sandbox on Anthropic infrastructure, destroyed when the session ends.
• No state is shared between sessions or organizations.
• The sandbox can't reach private, internal, link-local, or cloud-metadata addresses.
• Connector authorization tokens never enter the sandbox; connector calls are made server-side, and all sandbox traffic goes through a mandatory proxy it can't reconfigure.

Those last points come from Harmonic Security's practitioner guide and a security write-up from Greenlit Books. They're third-party descriptions, so cross-check against Anthropic's architecture overview for anything compliance-critical.

When I design agents, the first question is always: what's the narrowest door this thing needs to reach your data? Not "give it the shared drive." One door, one purpose, a log of everything that passes through.

You can build a simple version of that yourself. A gatekeeper script between the agent and your folders, allowing named paths and logging every read:

# gate.py - the only way the agent reads local files
import json, time, pathlib

ALLOWED = [pathlib.Path("/data/agent-inbox").resolve()]
LOG = pathlib.Path("/data/agent-gate.log")

def read_file(requested: str) -> bytes:
    p = pathlib.Path(requested).resolve()
    ok = any(p.is_relative_to(root) for root in ALLOWED)
    with LOG.open("a") as f:
        f.write(json.dumps({"ts": time.time(), "path": str(p), "allowed": ok}) + "\n")
    if not ok:
        raise PermissionError(f"Blocked: {p}")
    return p.read_bytes()

Resolving the path before checking it matters: it stops ../ tricks and symlinks from walking out of the allowed folder. Then sort your files into two buckets: stuff the agent can see freely, and stuff that crosses only on explicit request. Default access for bucket one, an explicit ask for everything else.

The trade-off nobody should skip: isolation is not privacy

Short version: Cloud means the files an agent opens are processed on Anthropic's servers and don't stay on your device. Per-session isolation protects your computer and keeps sessions from leaking into each other. It does not shrink what the agent can read through the access you granted.

Anthropic is direct about this. Local files the agent opens through the desktop app are processed on Anthropic's servers (architecture overview). The sandbox does not change what Claude can read or do through the access you've granted: connected folders, connectors, web browsing, email (Get started). And a connected folder gives read and write access, so Cowork can edit, create, and organize files there. The default "Ask before acting" mode pauses before actions that touch the outside world (Claude Academy).

Two things that help:

• Deleting a session also deletes the copies Claude fetched (support docs).
• The local-VM era wasn't a perfect shield either. Security firm Accomplish AI reported that untrusted content could escape the local Linux VM and reach files on the host Mac; Anthropic classified the report as "informative" and released no specific patch (Techzine). Accomplish believes the path doesn't appear to apply to cloud sessions, but that's the researchers' view, not an Anthropic statement. Don't read it as "cloud is immune."

I couldn't confirm retention periods or the hosting region of the sandboxes from Anthropic's own pages, so I won't state either. If you handle client contracts, payroll, health data, or anything with compliance weight, read Anthropic's current privacy and retention documentation and ask about where session data lives. This isn't a reason to avoid cloud Cowork. It's a reason to decide on purpose instead of by default.

If you need to stay fully local, the official route is Claude Code in the desktop app, though Cowork projects and schedules don't carry over to it (analysis from Redreamality).

A 20-minute audit before you move a job to the cloud

Short version: Pick one job you currently babysit and answer three questions, then sort the files. If you can't answer the third question, don't hand the job off yet.

Take the task that makes you say "I can't close my laptop, it's still running." Write down:

1. How long it runs. A few minutes or most of an hour? Only the long ones benefit.
2. Which files it truly needs. Not "the shared drive." The actual list.
3. The worst case if it reads a file it shouldn't. Be specific. A leaked price list is annoying; a leaked payroll sheet is an incident.

Then:

# Dedicated working folder for the agent; nothing else connected
mkdir -p ~/agent-work/inbox ~/agent-work/outputs

# Copy in only what the job needs
cp ~/Documents/invoices/2026-09/*.pdf ~/agent-work/inbox/

Connect that one folder, not your home directory. Keep the permission mode on "Ask before acting" until you've watched a few runs behave. Since folders are read-write, back up anything you can't regenerate before the first run.

My take: Anthropic moved execution to the cloud and names the disk, battery, and performance cost of the local VM as the reason. For small teams, always-on cloud agents with a tightly controlled file doorway beat running everything on a laptop. The winners won't be whoever has the smartest model. They'll be whoever makes the work keep running without you hovering over it, and who can show you exactly what the agent touched.

Why bizflowai.io helps with this

At bizflowai.io, I build practical AI automations for solopreneurs and small teams, and the first design step for any agent setup is the same: define the narrowest door to your data. That means moving working files into a single agent-reachable location, putting a logged gatekeeper in front of anything sensitive, and sorting jobs into "connector-only, runs anytime" versus "needs local files, runs when the machine is on."

Want more like this?

I share practical tips on AI automation.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milićević, senior engineer building practical AI automation.

Visit bizflowai.io for our services, case studies, and AI consulting.