By GitHub shipped computer use in Copilot CLI and the standalone Copilot app on October 1. Copilot can now click buttons, fill forms, scroll, and navigate desktop applications on your behalf — including GUI-only legacy tools that have no API, CLI, or MCP integration. It is in public preview on macOS and Windows. The important question is not what it can do in a demo. It is what you should actually let it touch.
Not Screenshots — Accessibility APIs
The technical approach matters here. Copilot computer use reads your applications through OS accessibility APIs — the macOS Accessibility API and Windows UI Automation — not by taking screenshots and parsing pixels. That distinction has real consequences. Accessibility API access is more structured and generally more reliable. It fails, however, on apps that use canvas-based UIs, which includes many design tools, games, and some web-based apps embedded in Electron wrappers that do not expose accessible elements.
The other important design choice: it runs in the background without blocking your keyboard or mouse. If you have ever watched an RPA bot take over your screen, this is different. You can keep working while Copilot handles the form in another window.
Enable it in CLI with /computer on. In the app, it is under Settings. It is off by default — which gives enterprise teams a window to set policy before users find the toggle themselves.
The Use Case That Actually Justifies It
Early adopters are using computer use for expense filing in proprietary enterprise portals, end-to-end testing by driving iOS and Android simulators, and vendor form automation. The GitHub changelog lists expense reporting, travel booking, and e2e test drives as the headline use cases. Someone drove Blender with it. Someone drafted a newsletter in an Edge-based editor that had no API surface.
These are interesting but not the point. The point is the class of software every organization runs that has no API, no CLI, no webhooks, and no MCP server. The HRIS that predates REST. The procurement portal that was built in 2009 and will not be replaced until 2031. Computer use is not a productivity toy for automating things that already have integrations. It is the tool for the stuff that has nothing.
What Enterprise Admins Need to Do Now
If you manage GitHub Copilot for an organization, set a policy before someone enables this on a machine with access to sensitive data. The relevant setting in your .github-private/.github/copilot/settings.json, per the GitHub enterprise managed settings docs:
{
"features": {
"computerUse": false
}
}That disables it org-wide. Org-level settings override individual user preferences, including “Always allow” entries users have saved locally.
A separate setting worth reviewing at the same time is disableBypassPermissionsMode. Setting it to "disable" blocks YOLO mode — the auto-approval mode that lets agents run commands and access files without asking. Computer use combined with YOLO mode is a much larger surface than either alone. The setting applies across Copilot CLI, VS Code, and JetBrains.
GitHub’s Own Warning
The official documentation is unusually candid: “Computer use can automate interactions across desktop applications, but it also introduces security risks. Ambiguous instructions or unexpected on-screen content may cause unintended actions that affect your device, data, or connected accounts.”
Read that carefully. The agent reads your application’s accessibility tree, which includes credential fields, PII in open records, and anything else rendered in the accessible UI layer. You are sending that content to GitHub’s infrastructure. Only use computer use with applications and tasks whose visible content you are comfortable providing as context.
Computer Use vs. MCP: Pick the Right Tool
If the tool you need to automate has an MCP server, use the MCP server. It is structured, deterministic, and auditable. Computer use is for when there is no MCP server, no API, and no other path. Think of it as a last resort that happens to be genuinely useful for a large category of real software.
The two approaches are complementary. As more tools ship MCP servers, the surface where computer use is the right answer shrinks. For now, that surface is still substantial.
The Verdict
Computer use is a real capability solving a real problem — the vast population of GUI-only software that the rest of the automation ecosystem cannot touch. The non-blocking design is smart. The accessibility API approach is more principled than screenshot-based alternatives. The enterprise controls are adequate if you configure them.
The catch is that “public preview” means exactly that. Reliability on non-standard UIs is unpredictable. The security surface is real and worth taking seriously. The killer use cases — legacy enterprise apps — are often the same apps that hold the most sensitive data.
Enable it selectively. Set the org policy. And do not let it loose on anything you would not want GitHub to see.
