Loading...
Claude Code can control your screen, but the feature ships with seven hard constraints: a machine-wide lock, no headless mode, plan gating, provider exclusions, macOS-only CLI support, fixed screenshot downscaling, and per-app approval. Here is what each one blocks and how to work around it.
Give Claude, Codex, or any AI assistant the ability to see your screen and automate any task. Runs locally on your Mac or PC.
Claude Code computer use limitations fall into seven categories: a machine-wide lock that permits one session at a time, no support for the non-interactive -p flag, Pro and Max plans only, no third-party API providers, macOS only in the CLI, forced screenshot downscaling with no configurable target, and per-app approval that resets every session. Anthropic documents all seven, and each has a workaround.
Each one is a scoping decision for a research preview that hands a model control of a real desktop, and most of them exist because the safety story would be harder without them. You tend to discover them halfway through building a workflow. Below is each limit, what it blocks, and what you can do instead.
| Limit | What it blocks |
|---|---|
| Machine-wide lock | A second session touching the screen |
No -p flag | CI, cron, scripted runs |
| Pro or Max only | Team and Enterprise seats |
| No third-party providers | Bedrock, Google Cloud Agent Platform, Foundry |
| macOS only in the CLI | Windows and Linux terminals |
| Fixed downscaling | Reading small on-screen text |
| Per-app approval | Unattended multi-app runs |
Computer use holds a machine-wide lock from the first computer use action until the session that took it exits. The final clause surprises people: finishing the task does not release the lock. Only exiting the session does.
The failure mode plays out like this. You run a UI test in one terminal tab, Claude clicks through the flow, reports success, and goes idle. You switch to a second tab, ask Claude to screenshot something, and the attempt fails with a message telling you which session holds the lock. The first session sits idle, and it still owns your screen.
The lock is a lock file, and Anthropic documents it as a deliberate guardrail. If the holding process crashes, Claude detects that the process is gone and releases the lock. If the process is alive and idle, you exit it.
This matters most for anyone running a long-lived agent session alongside ad hoc work. That session keeps the lock until you exit it.
Computer use requires an interactive session, so the non-interactive -p flag does not work with it.
That requirement removes an entire category of use cases. You cannot run claude -p "run the smoke test and screenshot failures" in a GitHub Action, schedule a cron job that validates a native build overnight, or pipe a prompt into a shell script and read the result back out. If your plan was to wire screen control into an automated pipeline, the CLI will not do it.
The interactive requirement follows from the approval prompts. Per-app approval and the Esc abort both assume a human is watching the terminal, and a headless run has nobody to answer them.
Computer use requires a Pro or Max plan. Team and Enterprise plans do not include it.
The direction runs opposite to what most people expect. The higher-tier organizational plans do not have the feature. Individual subscribers do. If your company standardized on Enterprise seats, nobody on that plan can enable computer use, and buying more Enterprise seats does not help.
Run /status to confirm which plan your session uses. This is worth checking before you spend an hour debugging why computer-use is missing from /mcp.
Computer use requires claude.ai authentication. Third-party providers including Amazon Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry do not carry the feature.
Anthropic's own documentation is blunt about the consequence: if a third-party provider is your sole path to Claude, you need a separate claude.ai account to use the feature. For many regulated or cloud-committed teams, that ends the evaluation. Those teams route through Bedrock or Foundry for data residency, procurement, or an existing cloud commit, and "open a separate consumer account" is not an answer their security review accepts.
Together with the plan restriction, the eligibility check narrows further. You need a claude.ai login, on Pro or Max, on macOS, in an interactive session. Miss any one and the server does not appear.
Computer use in the Claude Code CLI runs on macOS only. Linux and Windows terminals do not support it.
The Desktop app follows a different rule, and the distinction is easy to miss. Desktop supports computer use on both macOS and Windows, while the CLI supports macOS alone. Anthropic points Windows users at Desktop instead. Linux has no supported path on either surface.
Anthropic publishes a short table of other CLI gaps worth knowing about. The Desktop app offers a configurable denied-apps list and an optional auto-unhide toggle, and the CLI offers neither. Auto-unhide stays on, and no denied-apps configuration exists yet.
On macOS you also grant two system permissions before anything works: Accessibility, so Claude can click, type, and scroll, and Screen Recording, so Claude can see the screen. macOS often demands a full restart of the requesting process after you grant Screen Recording, which explains most permissions prompts that will not stop reappearing.
Claude Code downscales every screenshot before sending it to the model. A 16-inch MacBook Pro at native Retina resolution captures at 3456x2234 and arrives at about 1372x887, with the aspect ratio preserved.
No setting changes the target size. When text or controls are too small for Claude to read after downscaling, Anthropic's stated guidance is to increase their size inside the app instead of lowering your display resolution.
For most GUI work this is fine and saves you from managing resolution by hand. Dense interfaces suffer, though: log viewers, spreadsheets, IDE gutters, small-font terminals, anything where the information you care about occupies a handful of pixels. The model reads what survives the resize, and no flag lets you send more.
Enabling the computer-use server does not grant access to every app. The first time Claude needs a specific app in a session, a terminal prompt shows which apps it wants to control, any extra permissions such as clipboard access, and how many other apps it will hide while it works. You choose Allow for this session or Deny, and approvals last only for that session.
Apps with broad reach trigger an extra warning. Claude Code flags terminals and IDEs as equivalent to shell access, notes that Finder can read or write any file, and notes that System Settings can change system configuration. Claude Code blocks none of them, and the warning exists so you can decide whether the task warrants that reach.
Control also varies by app category: browsers and trading platforms stay view-only, terminals and IDEs stay click-only, and everything else gets full control.
Two behaviors follow from this design. Claude hides other visible apps while it works, then restores them when the turn ends. Claude Code keeps your terminal window visible and excludes it from screenshots, so Claude never reads its own output and on-screen text in your session cannot feed back into the model. Both choices make sense, and both mean a multi-app workflow starts with a round of prompts every session.
Some of these you route around inside Claude Code. Others need a different tool underneath.
The lock, the -p restriction, the plan gate, and the provider exclusion all share a root cause: computer use ships as a built-in computer-use MCP server tied to your claude.ai subscription. Swap in a third-party MCP server for screen control and those four constraints no longer apply. OpenOwl is one such server, with 40 MCP tools for screenshots, clicking, typing, OCR, accessibility tree queries, and window management.
| Limit | Workaround |
|---|---|
| Machine-wide lock | An external MCP server runs per session, with no cross-session lock file |
No -p flag | Claude Code loads MCP servers in -p runs, so headless works |
| Pro or Max only | An external server authenticates with its own key, independent of plan tier |
| Third-party providers | MCP servers work the same whichever provider Claude Code points at |
| macOS only | No workaround for macOS-only tooling |
| Fixed downscaling | Capture a region, or read the accessibility tree instead of pixels |
| Per-app approval | Fewer prompts, and fewer guardrails |
Two rows deserve a straight answer.
OpenOwl does not fix the macOS limit. OpenOwl ships for macOS and nothing else. If you need screen control from a Windows or Linux terminal, neither tool helps, and the Claude Desktop app on Windows remains your only supported option.
Downscaling is a constraint everywhere. OpenOwl downscales too, capping transport width at 1280 pixels. Every screen-control tool does, because full-resolution Retina captures are enormous. The escape hatch is what differs. OpenOwl's screenshot tool takes region_x, region_y, region_w, and region_h, so cropping to the region you care about spends the pixel budget on less area and raises effective detail per element. Better still, skip pixels: accessibility tree queries (find_element, list_elements, smart_find) and OCR (find_text, click_text) read UI state as structured data, where font size stops mattering.
Per-app approval involves a tradeoff in both directions. An external MCP server does not gate access per application, which removes the per-session prompt round. It also removes the sentinel warnings that tell you a terminal approval is equivalent to shell access. That is a real tradeoff, and you should make it on purpose. For a broader comparison, see our rundown of computer use agents.
Testing costs nothing. The free tier covers 50 tool calls per day, enough to check whether a headless run or a second concurrent session behaves the way you need before you commit.
No. Computer use holds a machine-wide lock from the first computer use action until the session that took it exits. Finishing the task does not release the lock. A second session that tries to act on the screen fails with a message naming the session that holds the lock. Exit that session to release it. If the holding process crashed, Claude detects the dead process and releases the lock on its own.
No. Computer use requires an interactive session, so the non-interactive -p flag does not work with it. This rules out CI jobs, cron entries, and any scripted run that pipes a prompt in and reads output back. You can reach a third-party MCP server that provides screen control from a -p run, because Claude Code loads MCP servers in non-interactive mode.
Not in the CLI. Computer use in the Claude Code CLI runs on macOS only. The Claude Desktop app supports computer use on both macOS and Windows, so Windows users should use Desktop instead. Linux has no supported path in either surface. If computer-use does not appear in your /mcp list, check the operating system requirement first.
No. Claude Code downscales every screenshot before sending it to the model, and no setting changes the target size. A 16-inch MacBook Pro at native Retina resolution captures at 3456x2234 and arrives at about 1372x887. Anthropic's guidance is to increase text and control size inside the application instead of changing your display resolution. Capturing a cropped region rather than the full screen also raises effective detail per element.
No. Computer use requires a Pro or Max plan, and Team and Enterprise plans do not include it. It also requires claude.ai authentication, so it does not work if your sole path to Claude is Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry. Organizations on those paths need a separate claude.ai account, which is often the blocker in practice.