Anthropic Cowork Mode: Desktop AI Agent Architecture Explained

Most explanations of Cowork describe a chatbot that can touch your files. That framing hides the interesting part. The Anthropic Cowork mode desktop AI agent architecture is really a set of separate trust zones stitched together by a permission layer: a model that reasons, an agent loop that decides, a sandbox that runs code, a proxy that guards the network, and a device bridge that reaches back to your machine only when you allow it. Understanding which of those zones a given action crosses is what lets you predict what Cowork will do, and what can go wrong.

This matters now because the product has changed shape since its January 2026 research preview. It went generally available in April 2026, and by October 2026 new Pro and Max tasks default to cloud execution rather than your laptop. Older write-ups, including an earlier version of this one, describe a purely local VM design that no longer matches the default.

You will leave with a working mental model of the layers, the plugin and skill anatomy, the computer-use permission tiers, the real threat model, and a rule for choosing between Cowork and Claude Code.

What this covers: the timeline and context, the reference architecture (cloud versus local), plugins and skills, computer use enforcement, security and failure modes, and a practical rollout checklist.

Context and Background

Cowork launched in January 2026 as a research preview inside the Claude Desktop app, aimed at people who do knowledge work rather than software development. The pitch was simple: take the agent harness that powered Claude Code, remove the terminal, and point it at a folder you choose. Early coverage described it as Claude Code for the rest of your work, and that is still a fair one-line summary.

The timeline since then is worth knowing, because each step moved a piece of the architecture. In late January, Anthropic added plugins, packaging skills, connectors and sub-agents into installable bundles; Axios reported eleven open-sourced starter plugins covering areas such as sales, finance, legal and support. In March, computer use and remote task assignment through Dispatch arrived as research previews for Pro and Max. On 10 April 2026, TechRadar reported general availability across paid plans, with enterprise controls such as role-based access, spend limits and analytics, on both Mac and Windows.

The architectural shift came later. A third-party changelog tracking the product dates remote, cloud-hosted sessions to July 2026 (starting with Max), cross-surface memory to August, Cowork becoming part of every conversation on Pro and Max in mid-September, and 6 October 2026 as the date new Pro and Max tasks began running in the cloud by default. Treat those dates as reported by a secondary source; Anthropic’s own support documentation confirms the October 2026 cutoff for local sessions on Pro and Max.

Incumbent alternatives frame the design space. Claude Code is the developer-facing sibling, covered in depth in our piece on Claude computer use and desktop agent architecture. Browser-only agents trade breadth for reliability. Classic robotic process automation (RPA) tools script GUIs deterministically but cannot reason about novel screens. Cowork sits in the middle: a general model, a constrained toolset, and a permission system designed around the assumption that the model will sometimes be tricked.

The primary reference for everything below is Anthropic’s Cowork architecture overview in the support centre. Where I cite specifics beyond it, I name the source, and where sources conflict I say so.

Cowork Mode Reference Architecture

Cowork’s architecture has an agent loop that plans and calls tools, a model that reasons, a permission layer that gates every action, and execution zones: a per-session cloud sandbox or a local Linux VM, a device bridge to connected folders, server-side connectors, and ungated-by-sandbox computer use. The permission layer, not the model, is the security boundary.

Figure 1: Cowork’s layers. Everything the agent does passes through the permission layer; only shell and code execution are sandboxed.

The diagram shows one agent loop fed by the Claude Desktop app, calling a model for reasoning, and routing every tool call through a permission layer. Behind that layer sit five distinct destinations: the sandbox or VM, connected folders, connectors, local MCP servers and plugins, and computer use. Notice that only one of those destinations, shell and code execution, sits behind an egress proxy. That asymmetry drives most of the security discussion later.

Two deployment modes: cloud by default, local for legacy

Anthropic’s architecture page describes two modes. In the cloud mode, which is now the default, the agent loop and code execution run on Anthropic’s servers, and sessions and files are saved to the member’s Claude account. In the local mode, the agent loop and code execution run on the member’s device. Cloud Cowork is available on Pro and Max, on Team in beta, and on Enterprise when an owner enables it. Local sessions on Pro and Max are limited to tasks and scheduled tasks that were started on the device before 6 October 2026.

This is the biggest correction to older descriptions. The popular picture of Cowork as a VM on your laptop is the local mode. In cloud mode your files do not stay on the device: work on local files opened through the desktop app is processed on Anthropic’s servers. Anthropic states that this data is covered by the same commercial commitments as other Team and Enterprise data and is not used to train Claude. That is a policy claim you should verify against your contract, not a technical guarantee you can inspect.

The cloud sandbox

Each cloud session gets its own isolated, temporary sandbox, created when the session starts and destroyed when it ends. Sandboxes share no state with one another or across organisations, and the infrastructure is described as separate from Anthropic’s corporate, research and model-training environments.

Three network properties define the sandbox. First, it cannot reach private, internal, link-local or cloud-metadata addresses, which closes the classic server-side request forgery route to a metadata endpoint. Second, all egress passes through a mandatory proxy that the sandbox cannot reconfigure; only allowlisted destinations resolve. Third, no network access is the default for Enterprise organisations, while other plans follow the same policy that governs local Cowork and chat.

Credentials are handled with the same discipline. The sandbox holds only session-scoped tokens that expire within hours. Connector authorisation tokens never enter the sandbox, and connector calls are made server-side. That design means a compromised sandbox cannot walk away with your Gmail refresh token, because the token was never there.

The local VM

In local mode, the agent loop runs on the device and handles conversation logic, reads and writes in connected folders, web fetches, and local plugin MCP servers. An application-layer permission system enforces connected-folder rules and the organisation’s egress settings. Shell commands and generated code, however, run in a dedicated Linux VM. Anthropic’s page names the hypervisors as Apple Virtualization.framework on macOS and Hyper-V on Windows; a security vendor’s guide also mentions QEMU with KVM, which I could not confirm in Anthropic’s own page, so treat that as unverified. The VM enforces its own egress filtering, syscall restrictions and per-session user isolation.

The split is subtle and worth restating. In local mode the model’s file edits are performed by the host-side agent loop against your real folders, while arbitrary code is quarantined in the VM. So a malicious script is contained, but a malicious file edit is not: the Edit tool really does change the file on your disk. That is why file permissions, not just the VM, carry weight.

The device bridge

Cloud sessions still need your files sometimes. When a cloud session needs a local file or the browser, the request travels through the Claude Desktop app over an Anthropic-brokered connection. Local file access is limited to folders the member has connected, and each local tool call is checked against the member’s permissions before it runs. If the desktop app is offline, a cloud session cannot reach the device at all.

This bridge is why the older claim “Cowork keeps conversation state in local storage” is no longer a safe summary. Session history now lives in your account for cloud sessions, while local sessions keep history on the device, outside Anthropic’s retention policies and outside central admin deletion.

Where the model fits

The model is stateless between calls. It receives the conversation, the loaded skills, the available tool schemas and tool results, and emits either text or a tool call. Planning, task decomposition and sub-agent coordination come from the same agent harness that Claude Code uses, so a complex task can fan out into parallel workstreams. Cowork asks you to review and approve a plan before execution begins, and you can intervene mid-run.

The practical consequence is that the intelligence of the system is separate from its authority. You can swap in a stronger model without widening what the agent is allowed to do, and you can narrow the authority without touching the model. Good agent design keeps those two dials independent, and Cowork mostly does.

Plugins, Skills, and the MCP Layer

Three terms get conflated: skills, plugins and MCP servers. They sit at different levels of the stack, and keeping them apart is the quickest way to reason about what an installation changes.

Figure 2: A plugin is a package. A skill inside it is loaded in two stages, an always-resident index and an on-demand body.

The figure shows a plugin as a container of five kinds of parts on the left, and the progressive-disclosure decision for skills on the right. Only a skill’s short name and description stay resident in context. The full body loads when the model judges the request relevant. Everything else stays dormant on disk.

Skills: progressive disclosure for instructions

A skill is a folder whose entry point is a SKILL.md file: YAML front matter with a name and description, followed by a markdown body of procedures, examples and references to helper scripts. The design goal is to keep context cheap. A user may have dozens of skills installed, yet the model sees only a one-line index entry for each until one is triggered. Our deeper treatment of the mechanism is in Claude Skills architecture for dynamic LLM agents.

The trade-off is that triggering depends on the quality of the description. A vague description under-triggers; a greedy one fires on unrelated requests and burns context. Writing the description as “use when the user wants X, Y or Z” tends to beat a feature summary, because the model is matching intent, not documentation.

Plugins: the distribution unit

Anthropic’s support page describes plugins as bundles of skills, connectors and sub-agents in one package, and notes that installing one can significantly widen Claude’s scope. Slash commands and hooks are also part of the plugin model; the security guide I cite below states that plugins bundle skills, connectors, subagents, slash commands and hooks. A role-oriented plugin, such as the sales or finance examples reported at launch, packages the domain instructions, the connector configuration and the shortcuts a team would otherwise copy around by hand.

The point of a plugin is governance as much as convenience. Instead of fifty people each writing their own prompt for “prepare a call brief”, a team installs one reviewed plugin. That is also its risk: a plugin is code and instructions with standing access, distributed through a marketplace or a Git repository.

MCP servers and connectors

The Model Context Protocol (MCP) is the open standard through which tools are exposed to the model. Our explanation of the MCP architecture covers the wire protocol; for Cowork the relevant question is where the server runs.

Two placements exist. Connectors to SaaS services are reached from Anthropic’s cloud with server-side OAuth, so tokens stay out of the sandbox. Local MCP servers, including those bundled in plugins, run on your device with your computer’s permissions, and Anthropic’s page states plainly that local MCP servers do not run in cloud sessions. A plugin that depends on a local server therefore behaves differently depending on whether the task ran in the cloud or on the device. If a workflow quietly changes behaviour after the October 2026 default switch, check this first.

A custom connector has one additional constraint: because it is called from Anthropic’s cloud, it must be internet-reachable, or reachable through an allowlist or tunnel. An internal-only service on a corporate LAN will not be callable from a cloud session without extra plumbing.

A worked example: from request to answer

Consider the request “Summarise unread email from today and add follow-ups to my task list.” The agent loop sees the request, consults the skill index, and finds that nothing special applies. It chooses the email connector, which exposes operations such as search and read-thread. The call goes through the permission layer, which for a read operation proceeds under the connector’s approval settings, then to Anthropic’s cloud, which attaches the stored credential and returns message previews.

The model drafts a summary and proposes writing tasks. Writing is a write-capable tool, and per the security guide, write-capable connector tools are re-approved for each task by default, with “always allow” off. The user approves, the task connector call executes server-side, and the transcript shows each step. At no point did the model, the sandbox or the transcript contain a raw credential.

Scheduled tasks

Scheduled tasks turn Cowork from a conversation into a recurring job. Anthropic’s usage page says that locally started scheduled tasks run only while the computer is awake and Claude Desktop is open. The reported July 2026 cloud change allows scheduled tasks to run with no device online. These two statements describe different modes, and the second is from the third-party changelog, so confirm which applies to your account before building something that must fire at 3 a.m.

The security guide ranks scheduled tasks as a distinct risk: they run unattended, so a poisoned data source could trigger the same injection repeatedly without anyone watching, and it reports no admin toggle for them. Anthropic advises starting with low-risk tasks and avoiding sensitive files and hard-to-undo actions.

Computer Use, Permission Tiers, and the Trust Boundary

Computer use is the capability to see the screen and operate a mouse and keyboard. It is the broadest tool Cowork has and, by Anthropic’s own wording, the least contained: the support documentation says it has no sandbox between Claude and your applications. It is in beta for Pro and Max on macOS and Windows, and Team and Enterprise plans do not currently have access.

Figure 3: Computer use is the last resort. The agent tries precise tools first and only then asks for per-app approval.

The sequence diagram shows the order of operations. The agent first tries a connector, bash or Claude in Chrome, because those are more precise and faster. Only if none fits does it request access to a specific app. The desktop app prompts the user, checks the app’s tier when the action is attempted, and then performs a screenshot followed by a click or keystroke.

Tool selection: precision first

Anthropic’s Claude Code documentation states the ordering explicitly: if an MCP server exists for the service, use it; if the task is a shell command, use Bash; if the task is browser work and Claude in Chrome is set up, use that; otherwise use computer use. Screen control is reserved for native apps, simulators and tools with no API. The same engine powers the desktop app, which shares the computer use implementation with the CLI.

This ordering has an economic and a safety logic. A connector call returns structured data in milliseconds and cannot misclick. A screenshot-click loop costs a model round trip per action and fails when a dialog moves. Prefer building or installing a connector for anything you do more than a few times a week.

The three tiers

Claude’s level of control varies by app category. Per Anthropic’s Claude Code documentation: browsers and trading platforms are view-only, terminals and IDEs are click-only, and everything else gets full control. The reasoning is straightforward. A browser has a better path through Claude in Chrome, so raw screen control there is unnecessary. A terminal or IDE is equivalent to shell access, so typing into it would bypass the Bash permission model. Trading platforms carry irreversible financial risk.

Tier	Typical apps	What Claude can do	Why
View-only	Browsers, trading platforms	Screenshot and read	Use Claude in Chrome for browsers; avoid financial actions
Click-only	Terminals, IDEs	Click and scroll, no typing	Typing would equal shell access
Full	Notes, Finder, System Settings, most others	Mouse and keyboard	Default for ordinary apps

One correction to the earlier version of this post: I previously presented the tier check as a three-value API field returned on every call and described exact error behaviour. Anthropic’s public documentation confirms the three categories but I could not verify the low-level error semantics, so I do not state them here. Also note the support article on computer use safety does not use the words “view-only” or “click-only”; the tier breakdown is documented on the Claude Code and Desktop documentation instead.

Apps with broad reach also show a sentinel warning at approval time: terminals and IDEs are flagged as equivalent to shell access, Finder as able to read or write any file, and System Settings as able to change system settings. These apps are not blocked; the warning lets you decide.

Approval, background mode, and the lock

Approval is per application and, in the CLI, per session. In the Desktop app on macOS 15 or later, Claude by default works in background windows without taking over your pointer or keyboard, and you can switch to full control in settings. Investment, trading and cryptocurrency apps are blocked by default, and the Desktop app supports a configurable denied-apps list that the CLI does not yet offer.

Only one session at a time can use your computer. A session takes a lock at its first computer-use action and releases it on exit. Pressing Esc aborts the current action, and the keypress is consumed so on-screen content cannot use it to dismiss dialogs. In the CLI, other visible apps are hidden while Claude works and your terminal is excluded from screenshots, so Claude never sees its own output.

Screenshots are downscaled before being sent to the model. Anthropic’s example is a 3456 by 2234 Retina capture reduced to roughly 1372 by 887. If text is unreadable after downscaling, enlarge it in the app rather than changing display resolution.

Cross-app side effects

The most underappreciated property is that approvals are not airtight. Anthropic notes that actions in one app can affect others: a link clicked in an email client may open in Chrome even when Chrome was never approved. Approving an app approves the apps it can launch, in effect. The right mental model is that you approved a capability graph, not a list of three apps.

Security Model, Failure Modes, and Capacity

Figure 4: Defence in depth for Cowork sandbox security. An allowlisted domain remains a capability, not a guarantee.

The diagram traces untrusted content reaching the model, then passing through an injection classifier, a permission mode, the egress proxy and the delete-approval rule before an action executes. The dashed branch records a lesson from a real incident, described below: allowlisting a domain grants whatever that domain’s API will accept.

Permission modes

A security practitioner’s guide from Harmonic Security describes three permission modes: Manual, Auto, where a classifier acts as the last check, and Skip. It reports that the Auto-approve option is on by default on Team and Enterprise, and recommends disabling bypass mode where unattended approvals are unacceptable. Separately, Anthropic’s usage page states that permanent file deletion requires an explicit “Allow” and that “act without asking” is recommended only when you are actively supervising.

Be careful with how much weight the vendor guide carries. It is a third-party analysis and itself notes conflicts between Anthropic sources, and some of its details (default states, rollout dates in September 2026) are things I could not corroborate from Anthropic’s public pages. I treat its figures as reported, not verified.

Prompt injection is the top risk

An agent that reads files, web pages and email will eventually read text written by an adversary. The guide ranks prompt injection as the top risk and quotes Anthropic’s reported attack success rates: before safeguards, 3.8 percent for one recent model and 17.6 percent for Opus 4.5, and with injection probes plus an action-verification classifier, 0 percent for several newer models. Anthropic reportedly cautioned that these figures are not comparable with its 2025 numbers. I cannot independently reproduce those figures, and I would not read “0 percent” as “impossible”: a measured rate on a fixed test set is not a proof about all attacks.

Anthropic’s own safety page is more modest. It says the system scans for signs of prompt injection and trains Claude to flag them, but that the capability is early, attacks are evolving, and safeguards are not perfect.

The allowlist-as-capability incident

The guide describes an incident in Anthropic’s own environment: a malicious workspace file carried an attacker’s API key, and Claude uploaded files to api.anthropic.com, an allowlisted domain, into the attacker’s account. The reported fix was an in-VM proxy that rejects tokens that were not provisioned for the session. The generalisable lesson is that a network allowlist is not a data-loss control when the allowed domain accepts arbitrary authenticated uploads. Any allowlisted service with a write API is an exfiltration channel if the attacker supplies the credential.

Gaps in network controls

Egress settings do not cover web fetch, web search, or MCP servers, including Claude in Chrome, according to Anthropic’s usage page. So the proxy protects the sandbox’s shell, not the whole agent. A locked-down network policy can coexist with a browser tool that reads anything the user is signed into.

The guide adds that the built-in browser keeps sites you have signed into accessible in later sessions, so a single login can become standing access. Whether that matches your deployment depends on your settings; verify rather than assume.

Supply chain: plugins and MCP

Anthropic states that it does not security-audit or manage any MCP server, as quoted in the guide. The guide lists two patched vulnerabilities in the surrounding tooling, CVE-2025-59536 and CVE-2026-21852, and notes that hooks in plugins are not covered by Anthropic’s skill and plugin scanning, which is Enterprise-only, beta and off by default. A compromised commit in a private plugin repository can push an update to every user. The mitigations are standard supply-chain hygiene: branch protection, commit signing, and pinning manifests by hash.

Two practical points. When allowlisting MCP servers, enforce on the command or URL, because a server name is chosen by the user and is not a control. And local connectors in the Desktop app may run in-process and bypass managed MCP configuration, so the per-tool block policy may be your only lever there.

Observability and compliance gaps

Anthropic’s architecture page says Cowork activity is captured in the Compliance API and that Team and Enterprise admins can monitor with OpenTelemetry. Its usage page, however, says Cowork activity is not captured in the Compliance API. These two statements conflict. The most likely explanation is that coverage changed with the cloud rollout, but I cannot confirm that, so check the current state in your own tenant before relying on it for audit.

Both sources agree on one blind spot: endpoint detection tools cannot see inside the VM or cloud sessions. If your security programme depends on EDR for evidence, plan a compensating control such as exporting OpenTelemetry events. The guide also reports that Cowork is excluded from the Business Associate Agreement; if you handle regulated health data, confirm eligibility with Anthropic directly.

Failure modes you will actually hit

The common failures are mundane. If a local VM cannot start, file and web tools keep working while shell and code execution report that the workspace is unavailable, per Anthropic’s failure-behaviour notes. If the desktop app is offline, a cloud session cannot read local folders. Scheduled local tasks do nothing while the laptop is asleep. A plugin relying on a local MCP server breaks silently in cloud mode. GUI automation breaks when a dialog appears that the model does not expect, and screenshot downscaling can make small UI text unreadable.

Capacity, latency and cost

I will not quote latency numbers for individual clicks, because I found no published benchmark. What can be reasoned from first principles: every computer-use step is a model round trip plus a screenshot, so a ten-step form fill costs roughly ten model calls, and multi-minute tasks consume proportionally more of a plan’s usage allowance. Anthropic’s usage page does not state consumption rules, so check your plan’s current limits. The cheaper path is always to use a connector, a script in the sandbox, or Claude in Chrome rather than raw pixels.

Cowork Versus Claude Code and Other Surfaces

The two surfaces share an engine but differ in defaults and audience. Claude Code lives in a terminal and a repository, and its sandboxed Bash tool isolates filesystem and network access. Cowork lives in the desktop app, defaults to cloud execution, and organises work around connected folders, connectors and plugins.

Dimension	Cowork	Claude Code
Primary user	Knowledge workers, analysts, operations	Software developers
Primary surface	Claude Desktop, web, mobile	Terminal, IDE, desktop
Default execution	Cloud sandbox (since 6 Oct 2026 for new Pro and Max tasks)	Your machine, with sandboxed Bash option
File scope	Connected folders only	Working directory and repo
Distribution unit	Plugins	Plugins and skills, MCP configs
Computer use	Beta, Pro and Max	Beta, Pro and Max, macOS in CLI

A rule that works: if the outcome is a diff in a repository, use Claude Code; if the outcome is a document, a spreadsheet, a triaged inbox or an updated tracker, use Cowork. If the task needs your local Python environment, GPU, or a virtual environment, use Claude Code, because Cowork’s code execution happens in the sandbox or VM, not in your own toolchain. In practice teams use both: Claude Code builds the script, Cowork schedules and wraps it with connectors.

Claude in Chrome is complementary rather than competing. For web applications it is faster and more reliable than screen-driven clicking, since it can use the page structure. Anthropic’s ordering puts it ahead of raw computer use, and so should you.

Trade-offs, Gotchas, and What Goes Wrong

Cowork’s strengths come with real costs, and several are architectural rather than incidental.

Authority follows convenience. Every capability you add, a folder, a connector, a plugin, a browser login, widens what an injected instruction can reach. Since January 2026 the product has made broader access easier: reportedly, since 4 September 2026 users can attach the home folder, Documents or whole drives. Wide access makes tasks easier and incidents worse. Scope to a dedicated working folder, as Anthropic’s own guidance recommends.

Cloud processing changes your data posture. Under cloud mode, local files you open are processed on Anthropic’s servers. For many organisations that is acceptable under existing commercial terms; for some regulated data it is not. Decide per data class, not per tool.

Local and cloud behave differently. Local MCP servers are absent in cloud, scheduled-task behaviour differs, and history lives in different places. The same plugin can succeed locally and fail in the cloud. Test in the mode you will actually run.

Unattended work compounds errors. A scheduled task has no human watching. A single bad assumption repeats on every run. Start read-only, review the run history on the Scheduled page, and add write actions only after a stable week of runs.

The tiers are a policy, not a proof. View-only for browsers does not stop a click in an email client from opening a malicious page in that browser. The tiers reduce accidental damage, not adversarial paths.

GUI automation is fragile. Layout changes, pop-ups and loading states break screen-driven flows. The honest remedy is to replace screen steps with connectors or scripts as soon as a workflow proves valuable.

Documentation is moving. Several Anthropic pages disagree with each other or with third-party summaries on defaults and coverage, and the product changed materially between January and October 2026. Anything you build should assume the controls page will change and re-verify it quarterly.

Practical Recommendations

Start by deciding what you are protecting, then choose a posture. For an individual on Pro or Max, the sensible default is a dedicated working folder, manual or reviewed approvals, and no standing access to financial or health accounts. For a team, the sensible default is Enterprise controls: role-based access, spend limits, OpenTelemetry export, and a short list of approved plugins.

Treat plugins like dependencies. Read the skills and hook scripts before installing, prefer plugins from a private repository you control, pin versions, and review changes before they roll out. Prefer connectors over screen control, and for any GUI task you repeat, ask whether a connector or sandbox script can replace it.

Keep scheduled tasks boring. They should read, summarise and draft; a human should approve anything that sends, pays, deletes or publishes. And keep a log: whatever your tenant’s audit coverage, capture session transcripts and tool calls somewhere you control.

A short checklist you can apply this week:

Create one dedicated folder per project and connect only that folder.
Turn off persistent “always allow” for write-capable connector tools.
Leave permanent deletion on explicit approval; do not use “act without asking” unattended.
Enable OpenTelemetry export before any pilot, and set content capture deliberately.
Block or deny financial, health, password-manager and admin-console apps in the denied-apps list.
Install plugins only from reviewed sources, and read hook scripts by hand.
Run scheduled tasks read-only for a week before adding write actions.
Test each workflow in both local and cloud mode if you use local MCP servers.
Re-check Anthropic’s architecture and usage pages every quarter for default changes.

Frequently Asked Questions

Is Anthropic Cowork still a research preview?

No. Cowork launched as a research preview in January 2026 and, according to TechRadar, became generally available to paying customers on 10 April 2026, on both Mac and Windows. Some pieces remain in beta: computer use is in beta for Pro and Max, cloud Cowork on Team is in beta, and Dispatch-style remote assignment was introduced as a research preview in March. Check the plan-level availability page for the feature you need.

Does Cowork run on my computer or in the cloud?

Both exist, but cloud is the default for new Pro and Max tasks since 6 October 2026, per Anthropic’s architecture page. Local sessions run the agent loop on your device and shell code in a Linux VM; cloud sessions run both on Anthropic’s infrastructure in a per-session sandbox. Cloud sessions reach your files only through the desktop app and only in folders you connected, and they cannot reach the device if the app is offline.

Is Cowork safe for sensitive files?

It depends on the data and your controls. The sandbox, mandatory egress proxy, server-side connector tokens and delete-approval rule are real mitigations, but prompt injection remains an open risk, computer use has no sandbox, and egress settings do not cover web fetch or MCP servers. Do not point it at regulated or highly confidential data without a risk review and confirmation that your contract and compliance scope cover Cowork. Use a dedicated folder.

What is the difference between a skill, a plugin and an MCP server?

A skill is a folder with a SKILL.md file, loaded progressively so only its short description stays in context. A plugin is an installable package that bundles skills, connectors, sub-agents, slash commands and hooks. An MCP server is a process that exposes tools through the Model Context Protocol; it may be a cloud connector or a local server on your device. A plugin can contain skills and point to MCP servers, but not the reverse.

How is Cowork different from Claude Code?

They share the same underlying agent harness. Claude Code targets developers and works in a terminal or IDE against a repository, with a sandboxed Bash option. Cowork targets knowledge workers and works through the desktop app with connected folders, connectors and plugins, defaulting to cloud execution. Use Claude Code when the output is a code change and Cowork when it is a document, inbox or tracker. Teams often combine them.

Can I run Cowork tasks on a schedule while my laptop is off?

For cloud-run tasks, reportedly yes, since the July 2026 change that lets scheduled tasks run with no device online, though that date comes from a third-party changelog. For locally started scheduled tasks, Anthropic’s usage page says they run only while the computer is awake and Claude Desktop is open. Confirm which mode your task uses, and keep unattended tasks read-only.