Computer MCP / Docs / When not to use it
When NOT to use Computer MCP
It is not a sandbox, it does not run in CI, it is macOS only, and for anything in a browser there is a better tool. The honest limits, from the people who built it.
We would rather you find this page before you install than after. Every item below is a real limit in the current build, not a caveat added for form. Where something is a deliberate design choice we say so, and where it is simply not measured yet we say that too.
Do not use it when you need containment
This is the big one, and it is the thing most easily misread about this product. Consent is not containment. The gate decides whether an action happens. Once you approve it, the agent is driving your real Mac, with your real logged-in sessions, your real keychain-backed apps and your real terminal. There is no sandbox underneath.
If what you actually need is a blast radius, run the agent against a virtual machine or a second user account and give it nothing you would mind losing. Then the question stops being "will it ask me first" and becomes "what can it reach at all", which is a much better question to be able to answer.
Do not use it on a server, in CI, or over SSH
It needs a Mac with a real logged-in graphical session, a screen that is awake, and two permissions that a human granted by clicking. None of those exist on a build runner. Over SSH there is no window server to talk to, so both the accessibility API and the screenshot return nothing useful. This is not a gap we intend to close: the product assumes a person's own machine, and most of the safety design only makes sense there.
Do not use it on Windows or Linux
There is no build, and there is no plan for one. The three guarantees are built directly on macOS APIs: the Accessibility API for knowing that a field is a password field, and ScreenCaptureKit for the picture. A port would be a different product with different guarantees, not this one recompiled.
Do not use it to read a secret off the screen
It cannot, and that is the point. Secure fields are blacked out before the image is
written, and computer_inspect never returns their value. If your task depends
on an agent reading a password back, this is the wrong tool and you should be glad it is.
There is a route for the opposite case, where a human needs to supply a secret
mid-task: computer_ask_user puts the cursor in the field and returns only true
or false, and you type on your own keyboard. No secret passes through the model.
The honest limit: only what macOS marks as secure is covered. A password sitting in a plain text editor, an API key in a terminal buffer, a token in a browser devtools panel: none of those carry the marking, and none of them are hidden. The redaction is exactly as good as the application's own field types, which is very good in native apps and login forms, and worth nothing in a text file.
Do not use it for web automation
You can drive a browser through it, and you will have a worse time than you need to. Clicking a web page through the accessibility tree means fighting a layer that was built for screen readers, not for automation, and you lose the DOM entirely. For anything that lives in a browser, use Browser MCP instead: same people, same licence, and it drives your real signed-in Chrome with the page structure intact. The two are complementary, not competing.
Do not expect it to see behind a full-screen app
A macOS app in true full-screen mode gets its own Space, and from outside that Space both the accessibility API and the screenshot see nothing of the windows underneath. This looks like a bug the first time and it is not one; it is how Spaces work. Leave the app windowed, or bring the target Space forward first. This is the single most common thing people report as broken. Troubleshooting has the details.
Do not install it expecting a shell
No shell execution, no arbitrary file reads, no URL fetching. Each would be a few lines of code, and each is left out on purpose: a computer-control server with a shell inside it is remote access under a friendlier name. If you want a shell, install a shell MCP server. Then you have chosen it, and the choice is visible in your config where you can see it.
So when is it the right tool?
When the work is in native macOS applications, on the machine you actually use, and the reason you have not automated it already is that you did not want to hand an agent an unguarded pointer to that machine. That is the case this was built for: the long unattended run on a real desktop, where the log tells you afterwards what happened and the password fields were never in the picture in the first place.
And when it is not that, one of the tools above is better, and we would rather say so here than have you find out two hours in.
FAQ
Is Computer MCP a sandbox?
No. It is a consent gate and an audit log, not containment. Once you approve an action the agent drives your real Mac with no isolation underneath. If you need a blast radius, run it against a virtual machine or a separate user account.
Can I use it in CI or on a headless Mac?
No. It needs a logged-in graphical session, an awake screen, and two macOS permissions a human granted by clicking. None of those exist on a build runner, and over SSH there is no window server, so both the accessibility API and the screenshot come back empty.
Will there be a Windows or Linux version?
No, and there is no plan for one. The guarantees are built on macOS APIs: one macOS system for knowing a box is a password box, and another for taking the picture. A port would be a different product with different guarantees.
Why can the agent not read my password back to me?
Because secure fields are painted black before the screenshot is written and computer_inspect never returns their value. If a task needs an agent to read a secret off the screen, this is the wrong tool. If it needs a human to supply one, computer_ask_user does that without the secret passing through the model.
Does it hide every secret on my screen?
No. Only what macOS itself marks as secure: password fields in native apps and login forms, plus whole windows of listed password managers. A password in a plain text editor, an API key in a terminal buffer or a token in a devtools panel carries no such marking and is not hidden.
Should I use this or Browser MCP for web tasks?
Browser MCP, without hesitation. Driving a web page through the accessibility tree means fighting a layer built for screen readers and losing the DOM. Browser MCP drives your real signed-in Chrome with the page structure intact. Same people, same licence.
The agent cannot see a window that is clearly open. Why?
Most likely an app is in true full-screen mode, which puts it on its own Space. From outside that Space, neither the accessibility API nor the screenshot can see the windows underneath. Leave the app windowed or bring that Space forward first.