How is computer use's permission model fundamentally different from connectors or browser interaction?
Why does Cowork allow this cross-app action cascade instead of locking everything to a single application?
Mechanically, how do the action cascade and screenshot-based navigation combine to produce this behavior?
What's the practical impact for someone who routinely works across multiple apps?
You only checked the box letting Claude access your mail app in Cowork — a simple ask: clean up the inbox, flag a few important messages. Midway through the task, Chrome pops up on screen and a new tab opens on its own. You never authorized Claude to use a browser.
This isn't a permissions bug. It's a direct consequence of how computer use is designed to work.
The official documentation lays out a priority order for how Claude touches your computer: try a connector first (fastest, most reliable), then browser interaction, and only as a last resort, direct screen interaction. When a task genuinely needs that last step — seeing the screen, clicking, typing — Claude asks for permission per application: one "allow" doesn't cover every piece of software on your machine; each new app it touches requires fresh consent. Some sensitive categories (investment and trading platforms, crypto tools) are blocked by default, and you can add specific apps to a blocklist yourself.
That already sounds like a careful design. The problem is that "application" as the unit of permission doesn't map one-to-one onto "what the user actually wants accomplished."
One line in the official docs names the core risk directly: "clicking a link in your email app might open it in Chrome, even if you haven't explicitly granted Claude permission to use Chrome." This happens because when Claude operates the screen, it's observing the outcome of the whole operating system's behavior, not confined to a single app's sandbox — the mail app itself invoking a browser to open a link is normal OS-level behavior, and Claude is simply using that existing mechanism, not bypassing or breaking any permission you set.
In other words, the boundary you think you drew is at the app level, but the boundary that actually governs behavior is at the operating-system level. The two overlap as long as everything stays inside one app, but the gap opens up the moment any action triggers a cross-app call — clicking a link, pasting clipboard content, dragging a file.
Computer use requires Claude to "take screenshots of your computer to understand how to navigate," which means anything currently displayed on screen is, in principle, within Claude's view — not just the app you authorized, but background windows, notification pop-ups, or any other tab you happened to leave open. This is fundamentally different from the closed scope of a connector or File Access: a connector only returns the specific data you queried, while computer use sees whatever the whole screen looks like at that moment.
On macOS 15 and later, Claude works in background windows by default and doesn't take over your mouse and keyboard — it only asks for your permission the first time a task in that session genuinely needs the full screen. This design reduces disruption, but it doesn't change the underlying nature of screenshot-based navigation: what's visible can potentially be captured.
If your work environment typically has a financial system, an internal messaging tool, and a customer database all open on screen at once, it's worth asking before granting computer use: does this task genuinely need to step outside the mail app's scope? If not, check whether a matching connector exists first — a connector's access scope is a well-defined API call with no action-cascade risk, and it's considerably faster than screen interaction. If the task genuinely requires coordinating across multiple apps, closing unrelated windows and adding sensitive apps to the blocklist before you start is far more reliable than discovering afterward that Chrome opened on its own.