GitHub Copilot can now handle desktop applications for you: it reads the window, clicks buttons, types in fields, and switches between apps. Activate it with /computer on in Copilot CLI or from Settings → Computer Use in the Copilot app. GitHub launched it in public preview on October 1, 2026, for macOS and Windows.
It’s designed for software your agent couldn’t reach before: legacy desktop tools, admin consoles with only graphical interfaces, and any program without an API, CLI, or MCP server. Until now, an agent’s world ended at the terminal and file system. Computer use extends it to the screen.
What is computer use in GitHub Copilot?
Computer use is a set of agent tools that let Copilot interact with desktop applications the way you would. According to GitHub’s documentation, Copilot can:
- read application content through the operating system’s accessibility tree, and take screenshots when it needs visual context
- click on controls
- write and edit text
- press keys, scroll, and drag elements
- carry a workflow from one application to another
The agent decides when to use these tools while solving your prompt, and each action is logged in the session’s tool activity.
In Copilot CLI it arrives as an included plugin, computer-use, which runs on its own MCP server. It’s worth knowing for when you need to troubleshoot (more below).
Don’t confuse it with the computer use in Microsoft Copilot Studio and Microsoft 365 Copilot: they share the name, but it’s a different product, designed for agents created in those platforms.
Does it work on Windows, Mac, Linux, and VS Code?
At the time of publishing this note, computer use was available on:
- Copilot CLI and the GitHub Copilot app
- macOS and Windows
- local sessions only
It was not available on Linux, in VS Code, or on Copilot’s cloud agent.
How do you activate computer use in Copilot CLI?
Computer use comes disabled by default. In an interactive Copilot CLI session, run:
/computer on
The CLI saves your preference and activates the included plugin. On macOS, it then guides you to grant two system permissions:
- Accessibility, to interact with application controls
- Screen Recording, to inspect windows when it needs visual context
The other two commands:
| Command | What it does |
|---|---|
/computer show |
Shows whether the plugin, its MCP server, and associated skills are enabled |
/computer off |
Disables computer use |
If your company disabled the feature, /computer on warns you it’s blocked by managed settings, and your local preference can’t override that policy.
What about the Copilot app?
Open Settings, select Computer Use, and enable Enable Computer Use. You can also type /computer on in a session.
Is Copilot computer use free?
Computer use doesn’t appear as a separate product: it’s a feature of Copilot CLI and the Copilot app. According to GitHub’s documentation, Copilot CLI is available on all Copilot plans; if you get Copilot through an organization, the Copilot CLI policy must be enabled in that organization’s settings.
At the time of publishing this note, neither the changelog nor the documentation indicated an additional cost for using computer use, nor did it detail how it consumes your AI credits. It’s a public preview and GitHub warns it may change, so check the documentation before using it at scale.
How to use it without it doing what it shouldn’t?
GitHub recommends describing the outcome you want, the applications involved, and the constraints. Constraints are what most people forget. The example prompt from the documentation itself ends with an explicit limit:
Open APP_NAME and summarize the status information shown in the
main window. Do not change any values or submit any forms.
Start with read-only tasks like that: summarizing a status screen, extracting data from a legacy tool, checking a value. Move to tasks that modify data only once you’ve seen how the agent behaves with that particular application.
To stop it mid-action, press Esc twice in the CLI, or click Stop or press Esc in the app.
What does “Always allow” do and when shouldn’t you use it?
Computer use follows your active permissions mode. In the CLI, /permissions show tells you which one is active. When Copilot needs to control an application, it asks you, and you can choose:
- Allow: access only for the current computer use session
- Always allow: saves the approval for future sessions
- deny or cancel
Always allow deserves a second look, for two reasons:
- It’s shared between the CLI and the app. An approval saved in one applies to the other on the same machine.
- Later actions on that app run without asking again. GitHub’s documentation explicitly recommends against it for applications with sensitive information or capable of high-impact actions: your email client, banking apps, anything that sends, pays, or deletes.
You can review and remove saved approvals from the Copilot app. Removing one doesn’t revoke access an already-running session has. Denial rules always take priority over saved or automatic approvals.
What risks does computer use have?
GitHub’s documentation is direct about it. Computer use interprets interfaces that change with app version, operating system, and window state. That means it can:
- click the wrong control or type in the wrong field
- struggle with non-standard or dynamic controls
- repeat an action, or get stuck, when timing or window state changes
The biggest risk is what’s on your screen. Everything visible in a window it inspects becomes context for Copilot, including information about other people. And unexpected content on screen can lead the agent to actions you didn’t ask for. GitHub’s conclusion: computer use doesn’t replace human judgment, especially before actions that modify data or affect others.
At the time of publishing this note, GitHub’s documentation didn’t clarify whether Copilot’s local sandbox restricts computer use actions. Don’t assume it does.
Computer use or MCP? What each is and which to use
Use computer use last, when no other tool can do the job. GitHub’s own documentation says the same: if an API, an MCP server, a terminal command, a file tool, or a browser tool can complete the task, that tool gives more structured information and more predictable results.
The reason is structural. An MCP server (Model Context Protocol) gives the agent named tools, defined parameters and responses: a call returns data with a contract. Computer use, on the other hand, reads pixels and accessibility labels, which change with every interface update, every theme, or every window size. A workflow that works today can silently break with the next version of the app.
A practical order:
- API or CLI. If the tool has one, use it.
- MCP server. If one exists, or if you can write a small one, it’s reusable and auditable.
- Browser tool. For web applications.
- Computer use. For the legacy desktop tool that offers none of the above.
That fourth case is real in almost any company: an old ERP client, a provider’s console, a reporting tool nobody’s touched in ten years. That’s where computer use earns its place. Copilot isn’t the first agent to do it: Codex Desktop already controls your Mac. What’s new is it now comes with your Copilot license and with the same permissions model you already use.
How do you disable computer use across the company?
With enterprise managed settings. Set features.computerUse to false:
{
"features": {
"computerUse": false
}
}
According to GitHub’s reference, this prevents users from enabling computer use in Copilot CLI and the Copilot app, and no local setting can override it. With true, or if you omit the key, the decision stays with each user’s local settings.
What to do if computer use isn’t working?
The diagnostic steps GitHub suggests for the CLI:
/computer showsays it’s not available: check that the feature is available for your account and you’re in a local session on macOS or Windows.- It’s enabled but does nothing: run
/pluginto check that thecomputer-useplugin is enabled, and/mcp listto check that its MCP server is connected. - On macOS: verify that the computer use helper has Accessibility and Screen Recording permissions.
What about you? Which desktop application from your work would you give to an agent first, if it could handle it on its own?
- Yes, I’m already testing it
- Yes, but only for read-only tasks
- No, I prefer to integrate via API or MCP
- I prefer another option (tell us which)
Comment below or, if this article reached you by email, reply directly to the email: your response gets published here.