Computer use: no sandbox, per-app permissions, the blocklist

Cowork's built-in browser runs behind a proxy it cannot bypass. Computer use is the other thing, and the documentation describes it in one sentence worth memorising: "Computer use has no sandbox between Claude and your applications".

Claude "interacts directly with your desktop, apps, and browser—clicking, typing, and navigating your screen". Everything your logged-in session can do, this grant can do. That is a different category of permission, and treating it as "the browser, but more" is the mistake this page exists to prevent.

Where it sits in the ladder

Cowork prefers gentler tools first. Connectors where they exist; failing that, "Claude may work on your task in the browser built into the Claude Desktop app"; and only when neither serves does screen interaction come up.

That ordering is your first control: a task that can be done with a connector or the built-in browser never needs this grant at all. Before enabling computer use, ask which rung the task actually requires.

The permission model, precisely

Three mechanisms, and they compose:

Per-application prompts. "Claude asks for your permission before accessing each application". The grant is per app, which is real granularity — approving your spreadsheet does not approve your password manager.

A default blocklist for the sharpest categories. Some sensitive apps — "investment and trading platforms, cryptocurrency" — are blocked by default, before you configure anything.

Your own blocklist. Add any app, and "Any requests from Claude to use blocked applications will be automatically denied". Denied automatically means no prompt to click through at a weak moment — the same argument as deny rules over ask rules: a decision made once, calmly, beats one made mid-task.

What Anthropic says not to use it for

The guidance is a list, and it is quotable because you will want it verbatim when someone asks: managing financial accounts or investments, handling legal documents, processing medical information, and interacting with apps containing personal information of others.

That last item is the one people miss. Your mail client, your CRM, your chat apps are databases of other people's information, and pointing an unsandboxed agent at them is a decision about their data that they did not make.

Why "no sandbox" changes the injection maths

An instruction hidden in a page the built-in browser reads is contained by what the browser can reach. The same instruction, read by an agent with computer use granted, has your desktop: whatever is open, whatever is logged in, whatever a keyboard and mouse can reach.

The blast-radius question applies with nothing subtracted: if content this task reads were hostile, what could it cause with these permissions? With computer use the honest answer is "whatever I could", which is why the grant should be rare, per-task, and revoked after.

The habits that keep it bounded

Turn it on for the task, not for the account. A standing grant is a standing answer to the blast-radius question.

Close what the task does not need. An unsandboxed agent's reach is defined by what is open and logged in; a clean desktop is a smaller surface.

Build the blocklist before the first real task, while you are calm: password manager, banking, mail, anything holding other people's data. The default blocklist covers trading and crypto; the rest of your list is yours to write.

And watch the first runs. Unattended and unsandboxed is the maximum-trust combination, and trust is something the step trail should earn first.

What goes wrong

Reasoning from the browser to this. The browser is sandboxed behind a proxy. This is documented as having no sandbox. The names are adjacent; the grants are not.

A standing grant. Enabled once for a spreadsheet task in March, still enabled for everything in June.

An empty blocklist. The defaults cover two categories. Your password manager is not one of them.

Sensitive apps open in the background. The grant is per app, but an open, logged-in application is one misdirected click away, and the operator clicking is not you.

Using it where a connector exists. The ladder exists so the sharpest tool is the last resort, not the default.

How to check it worked

Open your blocklist and read it against the apps actually installed on the machine. Every app holding credentials, money, or other people's data should either be on it or have a reason it is not. If the list is empty and the grant has been on for weeks, the step trail is your record of what happened in the gap — read it before assuming the answer is nothing.