Anthropic's desktop app exposes two assistant surfaces — Cowork and Code — that look similar at the chat layer but are quite different underneath. The surface-level guidance ("use Code for developer work, Cowork for documents") is correct but doesn't explain why, which makes it hard to predict how each will behave in unfamiliar situations. This document is the mental model.
There are two axes that distinguish the two surfaces: trust model and execution environment. Security posture and UX both fall out of those, but they're consequences, not the root cause.
Cowork runs in a sandbox. The shell that Claude has access to is a Linux
container — Ubuntu, fresh on each session, isolated from the host
machine. The real filesystem is exposed only through specific mounts:
a folder the user selects, an outputs scratchpad, and an uploads
directory for files attached to the session. Everything else on the
machine is invisible. Claude can't see SSH keys, shell history, /etc,
other repositories, or the keychain. When Claude runs pip install, the
package lands in the container, not on the host. When the session ends,
the container is destroyed.
Code runs natively. Claude Code's shell is the user's shell — their
zsh or bash, their environment variables, their dotfiles, their
installed tools, their SSH agent, their cloud credentials. When it runs
git push, it uses their credentials. When it runs npm install -g, it
modifies the real machine. There is no sandbox between Claude and the
operating system; the only barrier is the per-command consent prompt.
This is the most important practical difference. In Cowork, the assistant cannot affect anything outside the mounts no matter what it decides to do, which means the user does not have to vet every action. In Code, the assistant can in principle do anything the user can do at a terminal, which means the user does have to vet every action — and the permission system exists precisely to make that vetting tractable.
Cowork is capability-restricted by default. The set of tools is curated: file tools for mounted folders, a sandboxed shell, a fixed list of connector MCPs (Gmail, Calendar, Drive, Slack, etc.), web fetch with content restrictions, and a small number of Cowork-specific tools like persistent artifacts and scheduled tasks. New MCP connectors can be added from a registry, but the surface cannot be extended to run arbitrary code against the real system. The verbs available are limited, but within those limits Claude generally does not ask permission — it just does the task.
Code is consent-restricted by default. The verbs are essentially
unlimited — anything that can be done in a terminal, Claude Code can
propose. The protection is that each shell invocation hits a permission
prompt unless the user has allowlisted the pattern in
.claude/settings.json. The model assumes the user is a developer who
can read a git rebase --onto invocation and decide whether to
authorize it. Hooks, plugins, MCP servers all extend the surface further
— and all run with the host machine's privileges once approved.
The two are different bets about who the user is and what work they're doing. Cowork assumes the user wants the task done and shouldn't have to think about permissions; the sandbox makes that posture safe. Code assumes the user wants full power and is willing to engage with each authorization; the permission prompts make that posture safe. Both bets are defensible, but they produce surfaces that feel quite different to use.
The trust model and the execution environment together produce a set of practical capability differences that are worth knowing:
| Concern | Cowork | Code |
|---|---|---|
| Shell | Sandboxed Linux container, ephemeral | The user's real shell, with full environment |
| Filesystem access | Mounted folders only (selected dir, outputs, uploads) | Anything the user's account can read |
| Git operations on the user's real repos | Only within the mounted folder; no SSH agent | Full access including push, with the user's credentials |
Slash commands (/plugin, /agents, …) |
Not available | Available |
| Plugins, hooks, custom subagents | Not available | First-class — registered via .claude/settings.json |
| Connector MCPs | Curated catalog, easy to add from registry | Available, but configured per-project in settings |
| Web fetch | Allowlisted with content restrictions for legal reasons | Available, fewer restrictions |
| Persistent artifacts | Yes — HTML pages that survive sessions and re-fetch data | No equivalent |
| Scheduled tasks | Yes — recurring or one-shot future runs | No equivalent |
| Permission model | Capability-restricted by default; little prompting | Consent-restricted by default; per-command approval |
The filesystem is shared between the two — files written in Cowork are visible to Code and vice versa — so handoffs between surfaces are seamless. The question is which surface's tools match the work.
A useful test: if the task touches development infrastructure — git, language tooling, tests, hooks, installed CLIs, repo structure — use Code. If the task is about producing or consuming outputs — documents, spreadsheets, presentations, emails, scheduled briefings, dashboards — use Cowork.
Concrete examples that belong in Code:
- Editing source code, running tests, refactoring
- Installing and configuring Claude Code plugins, hooks, or MCP servers
- Running
git rebase,git push, branch management, resolving merge conflicts - Bumping dependency versions and running the build to verify
- Anything that needs to invoke a CLI tool installed on the host (
uv,gcloud,kubectl,terraform, etc.)
Concrete examples that belong in Cowork:
- Drafting a Word document, slide deck, or PDF report
- Extracting structured data from PDFs, spreadsheets, or screenshots
- Working with Gmail, Calendar, Drive, Slack via connectors — searching, drafting, summarizing
- Building a persistent dashboard that pulls live data from a connector each time it's opened
- Setting up a recurring task ("every Monday morning, summarize last week's calendar")
- Producing a polished deliverable from raw inputs, where the final product is a file the user will share
Borderline cases that could go either way:
- Reading a code repository to understand it. Either works. Cowork is fine if the work stays at the file-reading level; Code is better if it might lead to edits and a commit.
- Generating a report from data in a git repository. Use Cowork if the report is the deliverable and the repo is just an input. Use Code if the report-generation script is the deliverable and needs to live in the repo.
- Drafting a CLAUDE.md or other AI-config file. Cowork is fine for the drafting; commit it from Code.
The principle behind the test: Cowork excels at producing artifacts; Code excels at modifying systems. If the deliverable is a thing — a doc, a deck, a dashboard — Cowork is usually the better surface even if the inputs come from code. If the deliverable is a change to a system — a commit, a configured tool, an installed dependency — Code is the only viable surface.
It's tempting to describe Cowork as "more secure" and Code as "more powerful," but the framing misses the point. Cowork's sandbox is not a security feature layered on top of an assistant that would otherwise be dangerous; it's a consequence of the design choice that Cowork users should not have to vet each action. Code's lack of a sandbox is not a missing safety net; it's a consequence of the design choice that Code users want full access and are willing to authorize each command. Both surfaces are safe to use within their intended posture. Trouble starts when users try to use one surface for the other's work — running development tasks in Cowork (the sandbox prevents the work from actually affecting the system) or running drafting tasks in Code (the permission prompts and lack of connector tools make the experience slow and clunky).
Pick the surface whose posture matches the work, and the security and UX consequences take care of themselves.