Four Rooms, One AI: How Claude's Execution Environments Actually Work
Artifacts, Claude Code, Cowork, and Code-on-the-web don't just look different — they run in fundamentally different places with different security properties. Here's the architecture, explained simply.
Most security discussions about AI focus on the model — what it will or won't say, whether it hallucinates, whether it can be jailbroken. That's the wrong layer to start with. The more important question is where the AI executes, what it can touch from there, and what leaves your environment. Claude has four distinct execution environments. Each one has a completely different architecture underneath it. And most people — including most security professionals — don't know which one they're actually using when they open the app.
Start here: Claude works in different rooms
Think of Claude as a capable colleague who can work in different rooms. The room determines what they can touch, what they can do, and who can watch them. The colleague is the same person in every room. The room is what changes the risk profile.
There are four rooms:
Claude Code (local) — your desk. Claude sits there, working in one folder. Real files, real changes.
Claude Code (web) — a contractor's office in Anthropic's building. Your repo gets cloned there. You never visit.
Cowork — a sealed office on your floor, inside a virtual building. Isolated from everything except the folder you gave it a key to.
Same Claude. Four entirely different security boundaries. The rest of this article is those four rooms in detail.
Artifacts: a whiteboard in a locked cloud room
When you ask Claude to build something visual — a chart, a React app, an interactive calculator — the result appears inline in your chat window. That live result is an Artifact. The key thing to understand is that it never runs on your machine.
Here's the flow. You type the request. Claude, running on Anthropic's servers, writes HTML or React or SVG to produce the result. That code is then executed inside a sandboxed iframe — a locked browser window on Anthropic's cloud, completely isolated from your files, your cookies, your local environment. A strict Content Security Policy (CSP) acts as the rulebook: it specifies exactly what that code is allowed to do and blocks everything else. The rendered output streams into your chat. You can interact with it. Your computer is never involved in executing any of it.
↓
[ Anthropic cloud — Claude model ] Writes the code.
↓
[ Anthropic cloud — sandboxed iframe (CSP enforced) ] Executes it, isolated.
↓
[ You see the output ] Your machine: untouched.
What stays where
- Generated code and the artifact itself
- Rendered visual output
- Execution environment and state
- Any persistent storage you create in-artifact
- Your local files and folders
- Your browser cookies and history
- Passwords or credentials
- Anything outside the locked frame
The security gaps
The artifact is safe. What you paste into the chat is not.
If you paste a CSV, a customer list, or salary data into the conversation to help Claude build the artifact, that data is part of your conversation and is handled under your plan's data policy. The iframe sandbox is solid — but the chat prompt containing your data is the actual data governance question.
No separate audit trail for what was built
There's no separate log of which artifacts were generated or what code ran inside them. The conversation transcript is all you have. On Enterprise, Anthropic's Compliance API covers conversation content — but Artifact execution is not separately auditable.
The artifact is safe. The data governance question is what you paste into the chat to build it.
Claude Code local: an intern at your desk, fenced to one folder
Claude Code is installed on your machine. It reads your actual project files, writes code, runs shell commands, and debugs problems. Unlike Artifacts, this lands directly on your computer — and changes are immediate and real.
The analogy I keep coming back to: a capable intern sitting at your desk with access to your keyboard and terminal. You've told them they can only work inside one specific folder. There's a security guard (the OS sandbox) watching every command they type, and the moment they try to open a different drawer, the guard blocks it.
Receives your prompts and file contents. Plans the work. Returns tool calls.
[ Your machine — permission pipeline ]
Checks every requested action against allowlists before the sandbox sees it.
[ Your machine — OS-level sandbox (bubblewrap on Linux / seatbelt on macOS) ]
Executes commands. Filesystem: current working directory only.
Network: approved domains only (package registries, Anthropic API).
All child processes inherit the same restrictions — including every script Claude spawns.
Two hard fences at the OS level enforce the containment. Filesystem: read and write access is limited to your current working directory. Your ~/.ssh keys, your ~/.aws credentials, everything outside the project — invisible. Network: outbound traffic routes through a proxy. Only approved domains reach the internet. Both fences are enforced by the operating system itself, which means they apply to every subprocess and script Claude spawns, not just Claude's direct actions.
What stays where
- All edited and created source files
- Test results and shell output
- Session transcript (
~/.claude/projects/, 30 days) - Everything outside the project folder
- Your prompts and task descriptions
- Contents of files Claude reads
- Command outputs Claude uses to reason
- Retained 30 days (Teams/Enterprise); not used for training
The security gaps
Session transcript is plaintext on your disk
Every session creates a full plaintext record at ~/.claude/projects/ — including any file contents Claude read. If Claude read a file containing credentials, those credentials are in the transcript. It stays for 30 days by default. Adjust with cleanupPeriodDays in your settings, or clear manually.
The sandbox has an escape hatch
If a command fails because of sandbox restrictions, Claude may retry with dangerouslyDisableSandbox — an intentional design choice to avoid breaking legitimate workflows. The sandbox is strong, but it is not absolute. Watch your session logs for it.
EDR agents have limited visibility inside the sandbox
CrowdStrike and similar tools monitor at the host level. Some activity inside the bubblewrap sandbox may not appear with full context in your EDR console. OTel hooks are the reliable monitoring path for what Claude Code is actually doing.
Computer Use runs outside the sandbox entirely
When Claude Code controls your screen — mouse, clicks, keystrokes — that capability operates on your real desktop with no sandbox around it. It's gated by per-application permission prompts, but there's no filesystem or network fence around it.
Claude Code on the web: a contractor's office in Anthropic's building
Claude Code on the web runs entirely in Anthropic's cloud. No installation. No terminal. You access it at claude.ai/code from any browser. Claude clones your GitHub repository into an Anthropic-managed VM, does the work, and pushes a branch back to GitHub when it's done. Your computer is never involved in execution.
This is also what runs when you use the Code button inside Claude Desktop — it routes to the same cloud VM infrastructure, not your local machine.
↓
[ Anthropic cloud — Claude model + auth proxy ]
Your GitHub token stays here. Never enters the VM. Exchanges for a short-lived scoped credential.
↓
[ Anthropic cloud — isolated execution VM (fresh per session) ]
Ubuntu VM. Fresh clone of your repo. Claude Code running inside.
Network access: Trusted / Custom / None (you configure).
Branch-restricted git push — cannot push to main.
VM destroyed after session. All session data wiped.
↓
[ GitHub ] Receives the pushed branch. Your PR is Claude's "done" signal.
Each session gets its own isolated VM: 4 vCPUs, 16 GB RAM, 30 GB disk. It starts from a fresh clone of your repository — nothing from your local machine is present. Pre-installed runtimes cover Python, Node.js, Go, Rust, Java, Ruby, PHP, Docker, PostgreSQL, and Redis. Your GitHub token never enters the VM — it stays in Anthropic's auth proxy, which exchanges it for a short-lived scoped credential. Git push is branch-restricted: Claude cannot push to main.
What stays where
- The VM and all execution — fully cloud-side
- Your GitHub token (stays in Anthropic's auth proxy)
- Installed packages and build artefacts (wiped after session)
- No local transcript at
~/.claude/projects/
- Your repo clone — inside the VM during the session
- Prompts and file contents (30-day retention)
- Session transcript URL (visible on claude.ai)
- Your pushed branch — on GitHub until you delete it
The security gaps
Your entire repository is cloned into Anthropic's infrastructure
Every file in the repo — including committed secrets, internal docs, proprietary code — is copied into an Anthropic-managed VM for the session. This is documented and expected, but it's the most important thing to understand before using this with a sensitive codebase. Treat it like granting a contractor read access to your full repository.
No dedicated secrets store
If Claude needs API keys to run tests or call services, you add them as environment variables in environment settings — and anyone who can edit that environment can see them. Anthropic documents this explicitly. A proper secrets store is listed as planned.
ZDR and cloud sessions are mutually exclusive
Enterprise customers with Zero Data Retention enabled cannot use /web-setup or any cloud session features. ZDR requires immediate deletion; sessions that persist after browser close are incompatible with that guarantee.
Local config doesn't follow you to the cloud
Your local ~/.claude/CLAUDE.md, locally-added MCP servers, and user-scoped settings don't appear in cloud sessions. Only configuration committed to the repository — CLAUDE.md, .claude/settings.json, .mcp.json — is available. Any hardening you apply locally needs to be separately committed to take effect in cloud sessions.
Cloud-only features: Scheduled Routines (cron or API triggers), Auto-fix PRs (CI failures + review comments), Ultraplan (plan review before execute), parallel --remote sessions, and session monitoring from the Claude mobile app all require the cloud execution environment and don't exist in local Claude Code.
Cowork: a sealed office on your floor
Cowork is the task-delegation mode in Claude Desktop, built for non-developers. You describe a multi-step job, assign it, and walk away. Claude processes invoices, writes reports, calls your Jira or Slack, and puts finished files in your folder while you do something else.
What makes Cowork architecturally distinct is that it runs inside a full Linux virtual machine on your own computer. Not a container, not a sandbox process — a proper VM, completely isolated from your host system by a hardware-level hypervisor.
The analogy: you've given a temp worker a key card that only opens one room. They work in a physically sealed office on your floor — the VM. Their phone only dials certain numbers (~22 allowlisted domains). They can pass notes to your Jira or Slack via connectors, but they cannot walk into your main office, open your filing cabinets, or take anything off your desk. Because they literally can't see any of it.
Receives prompts. Returns tool calls. All inference here.
[ Your host machine — Claude Desktop (Electron app) ]
Manages the VM lifecycle. Hosts MCP server processes.
Makes real API calls on behalf of connectors (outside the VM).
[ Your host machine — Linux VM (hypervisor isolated) ]
Ubuntu 22.04. 4 vCPUs, ~4 GB RAM, 10 GB disk.
Only sees your mounted folder(s) via VirtioFS.
Network through a local proxy to ~22 allowlisted domains.
[ Inside the VM — bubblewrap + seccomp sandbox ]
Claude Code CLI runs here. A second isolation layer on top of the VM.
The MCP connector detail that matters most
When Cowork wants to create a Jira ticket or post to Slack, the API call does not come from inside the VM. The VM sends the instruction to the host via the MCP SDK over a stdio pipe. The host-side connector process makes the real HTTPS request using credentials stored on your machine — never inside the VM.
This is good news for credential security: your API tokens never enter the VM. But it means the connector's network access is unrestricted by the VM's allowlist. The VM is controlled. The connector traffic is not.
What stays where
- Files in your mounted folder (real-time VirtioFS sync)
- VM execution — runs locally, not in the cloud
- MCP credentials and API tokens (host only, never in VM)
- Git tokens (scoped proxy; raw token never in VM)
- Everything outside your mounted folder
- Your prompts and task descriptions
- File contents Claude reads inside the VM
- Retained 30 days (Teams); no ZDR option on Teams
- US-based infrastructure only — no EU residency option
The security gaps
EDR and antivirus cannot see inside the VM
CrowdStrike, Defender, and similar tools run on your host. The VM is isolated at the hypervisor level — they cannot inspect processes, file access, or network activity inside it. Anthropic explicitly confirms this by design. OTel telemetry is the only monitoring surface available inside the VM boundary.
MCP connector calls are unaudited and unrestricted
When Cowork uses a connector to call Jira, Slack, or Google, the API call executes on your host with host-level network access — outside the VM's allowlist entirely. There is no per-action audit record of what data was passed to those services through Cowork. This is the biggest data governance gap for enterprise use.
Cowork activity doesn't appear in audit logs — on any plan
Even Enterprise customers cannot see Cowork task activity in Anthropic's Compliance API or standard audit exports. This is a platform-wide gap, not a plan limitation. OTel is the only path to any form of Cowork monitoring.
Session transcript stored locally in plaintext
Like local Claude Code, a full plaintext record of the Cowork session — including any file contents read — lives at ~/.claude/projects/ on the host for 30 days by default.
No EU data residency option for Cowork
Claude Code CLI can be routed via AWS Bedrock EU or Google Vertex EU. Cowork has no equivalent. It always sends inference through Anthropic's US infrastructure. Relevant for any organisation processing EU personal data under GDPR.
The VM is your strongest local isolation. It's also a blind spot for your endpoint security tooling. OTel hooks are the only monitoring path that works inside the boundary.
The four environments compared
Same Claude. Four completely different execution environments. Here's how they line up on the questions that matter for security decisions.
The diagram below maps the full execution and sandbox flow for Claude Code (local) and Cowork side by side — showing exactly where each layer sits, what it can touch, and where the MCP path breaks out of the VM boundary.
| Question | Artifacts | Code (local) | Code (web) | Cowork |
|---|---|---|---|---|
| Where does it run? | Anthropic cloud | Your machine | Anthropic cloud VM | Local VM on your machine |
| Touches your local files? | Never | Yes — project folder | Never | Yes — mounted folder |
| Runs shell commands? | No | Yes — OS sandboxed | Yes — cloud VM | Yes — VM + OS sandbox |
| Isolation type | CSP-locked iframe | OS sandbox (bubblewrap / seatbelt) | Anthropic-managed isolated VM | Hypervisor VM + bubblewrap inside |
| EDR visibility? | N/A — cloud | Partial | N/A — cloud | No — VM blindspot |
| Audit logs | Conversation transcript | OTel + local transcript | Full session audit log | OTel only |
| Local transcript on disk? | No | Yes — 30 days plaintext | No | Yes — 30 days plaintext |
| Credentials in execution env? | No | Yes — local env vars | No — scoped proxy token | No — MCP proxy on host |
| Internet access | Allowlisted only | Via OS proxy only | Trusted / Custom / None | ~22 domains (VM); unrestricted (connectors) |
| Requires local install? | No | Yes — npm | No — browser only | Yes — Claude Desktop |
What changes by subscription plan
The architecture I've described above is identical on every plan. What differs is the data handling, compliance scaffolding, and which features are available.
| Feature | Free / Pro / Max | Teams | Enterprise |
|---|---|---|---|
| Model training on your data | Opt-in (default-on from Oct 2025) | No — commercial terms | No — commercial terms |
| Data retention | 30 days (opted-out) or 5 years (opted-in) | 30 days | 30 days or ZDR |
| GDPR Data Processing Agreement | No — consumer terms | Auto-included | Auto-included + custom |
| HIPAA BAA | No | No | Available via sales |
| Zero Data Retention (ZDR) | No | No | Self-serve |
| Audit logs / Compliance API | No | No | Yes — conversations only |
| Cowork audit coverage | OTel only | OTel only | OTel only — same gap on every plan |
| MDM controls (isLocalDevMcpEnabled etc.) | No | Yes | Yes |
| Cloud session Routines | Pro: 5/day, Max: 15/day | 20/day | 25/day |
| EU data residency | No | CLI only, via Bedrock/Vertex | CLI only. Cowork: no option on any plan. |
For regulated industries: The sandbox security is the same on every plan. What Teams and Enterprise add is the legal and compliance layer — a DPA so you can process personal data under GDPR, no training on your data, and on Enterprise, ZDR and BAA options. If you're handling HR records, patient data, or financial data, Free and Pro plans are not appropriate regardless of how the sandbox works.
The one thing to hold on to
Every one of these environments runs on the same underlying principle: define the boundary, enforce it at the OS or hypervisor level, and minimise what crosses it. Artifacts never touch your machine. Local Claude Code is fenced to one folder. Cloud Claude Code runs in a clean VM that never sees your machine at all. Cowork runs in a sealed VM on your own computer.
None of them store your credentials in the execution environment. All of them send your prompts — and the context you give them — to Anthropic's cloud.
The sandboxes protect your local system from Claude. They do not protect the data you share with Claude from leaving your organisation.
The governance question — what am I allowed to give Claude to work with? — is a policy decision, not a technical one. The architecture gives you the tools to enforce it. The policy is yours to set.
Know which room you're working in. The room determines the risk.