Claude Code Computer Use: What I Let Claude Click on My Mac (and What It Will Not)

Claude Code computer use lets Claude open the apps on your machine, see your screen, and click, type, scroll, and drag the way you would. In the desktop app it is a research preview on macOS and Windows, it needs a Pro or Max plan, and it is off by default. You turn it on under Settings, General, in the Desktop app section, and on a Mac you grant two system permissions, Accessibility and Screen Recording, before the toggle takes effect. After that, the first time Claude needs a specific app in a session, it asks, and you click Allow for this session or Deny. It is not the Browser pane and it is not the Chrome extension. Those handle web pages. Computer use is for everything that has no web page, no command line, and no API: a native Mac app, a design tool's export dialog, a simulator, a settings window.

I turned it on the week I needed Claude to test a small native utility I had it build for the club's publishing queue, an app with no browser surface at all. Below is what it did, what it asked for, what I said no to, and the order Claude tries other tools before it touches the screen. That order is the most useful thing on this page, because it is why computer use is rarely the tool you end up using and always the one you are glad exists.

Computer use is the broadest tool Claude has and the slowest, because every step is a screenshot, a look, and a click. So Claude tries the most precise tool first and only falls through to screen control when nothing else reaches the task. I call the order the CCC Last-Resort Ladder, and if you learn nothing else here, learn this, because it explains most of the moments where you enable computer use and then watch Claude not use it.

The per-app tiers, covered next, reinforce the ladder on purpose. Browsers are capped at view-only and terminals at click-only even when computer use is on, so Claude is steered back to the Browser pane or the sandboxed shell rather than clicking around in a Chrome window. My first real prompt after enabling it was to check a page in the club site, and Claude told me it would rather do that in the Browser pane. It was right. [Claude Code skills vs MCP servers](/blog/claude-code-skills-vs-mcp-servers) is the same instinct one rung up: give Claude the precise tool and it stops needing the blunt one.

Two settings live next to the toggle and both are worth setting on day one. Denied apps is a list of apps Claude will never be allowed to control, rejected without a prompt; mine has my password manager and my banking app in it. Unhide apps when Claude finishes controls whether the windows Claude hid while it worked come back on their own. More on the hiding below.

Enabling computer use does not hand Claude the whole machine. The first time Claude needs a given app in a session, a prompt appears in the chat naming the app, any extra access it wants such as the clipboard, and the level of control that app category gets. You click Allow for this session or Deny. Approvals last for that session and then expire; in sessions started from Dispatch on your phone they expire after 30 minutes and re-prompt. The tiers are fixed by category and you cannot raise them.

Apps with broad reach show an extra warning in the prompt. Terminals are flagged because approving one is equivalent to shell access. Finder on a Mac, or File Explorer on Windows, can read or write any file. System Settings can change the system. None of these are blocked; the warning is there so you decide whether the task justifies it. One catch to know: a denied app can still be affected indirectly by an action in an allowed app, so the denied list is a wall around direct control, not a wall around outcomes.

The utility I mentioned is a small menu bar app that watches the club's publishing queue and shows a count. Claude wrote it, compiled it, and, once computer use was on, launched it and clicked through it before telling me it was done. That is the part I could not get any other way: there was no page for the Browser pane to load and no test harness worth writing for an app this small. It opened the preferences window, changed the refresh interval, and reported that the label updated. Then it found the thing I would have shipped. At the default window size, the Save button in that preferences window sat below the visible area, so the interval could be changed and never saved. Claude resized the window to reproduce it, screenshotted the clipped state, fixed the layout, and re-ran the check.

A few things about how it works on screen are worth knowing before you rely on it. While Claude is controlling the screen it hides your other windows so it only interacts with the app you approved, and restores them when the turn ends, unless you turned that setting off. On macOS there is also a background mode where Claude works in the approved apps while you keep using the machine. Screenshots are downscaled automatically before they reach the model, so you do not have to lower your display resolution on a Retina screen; if Claude cannot read small text, make the text bigger in the app, not the screen smaller. And the documented emergency stop in the terminal version is the Esc key, which aborts the current action from anywhere and is consumed so nothing on screen can use it to dismiss a dialog.

The cost is time and tokens. A screenshot-look-click loop is slower than a shell command by a wide margin, so I do not leave computer use running on a long session where nothing native changes. [Claude Code context management](/blog/claude-code-context-management) covers why screenshots in the context window add up, and [how to debug with Claude Code](/blog/how-to-debug-with-claude-code) is where I send people once computer use has shown them the failing state, because from there it is ordinary debugging.

The sandboxed Bash tool runs commands in an isolated environment. Computer use does not. It runs on your actual desktop with access to whatever you approve. Claude checks each action and flags potential prompt injection from on-screen content, but the boundary is a different shape, and the guardrails are the tiers, the per-session prompt, the sentinel warnings, the denied list, and the fact that in the terminal version Claude never sees its own terminal window in a screenshot, so a prompt inside your session cannot feed back into the model. Those are real, and I still treat computer use as the one Claude Code feature where my judgment is the main safety control rather than a backup.

Practically, that means three habits. I only approve the app the task is about. I never run computer use on a machine that is signed into a client's systems, which is the same line I draw in [is Claude Code safe for client work](/blog/is-claude-code-safe-for-client-work). And I keep the Browser pane and the Chrome extension set up so Claude has somewhere better to go for anything web-shaped, which the ladder above then enforces for me. [Claude Code's sandbox, explained](/blog/claude-code-sandbox-explained) is the other half of this picture: what the Bash tool isolates, and the short list of things it was never meant to cover, computer use being one of them.

Enable it, set the denied list before you run anything, then give Claude a task that genuinely has no other route: a native build to click through, a GUI-only export, a settings window to verify. Watch the first prompt, approve exactly one app, and read what it reports. You will learn in ten minutes whether computer use belongs in your workflow, and the answer for most builders is: rarely, and when it does, nothing else will do.