GitHub Copilot computer use: how to turn it on and the risks

GitHub Copilot computer use is now in public preview: since October 1, 2026, Copilot can click, type, scroll and drag inside desktop apps on macOS and Windows, from both the Copilot CLI and the GitHub Copilot app. It's off until you turn it on, it asks before it takes control of an app, and an organization can switch it off for everyone. Here's how to enable it, what it can and can't do, who gets it, and what you're trading away when you let an agent drive your desktop.

Key takeaways

• What's new: Copilot can operate desktop apps that have no API, command line or MCP integration, per GitHub's announcement. It's a public preview, so GitHub says it may change.
• How to turn it on: type /computer on in a Copilot CLI session, or open Settings, then Computer Use, in the Copilot app. It's disabled by default.
• Where it works: local sessions on macOS and Windows only. Linux and remote sessions aren't on GitHub's list.
• Who controls it: you approve each app once per session or choose "Always allow", and enterprise admins can block the feature with a managed setting your local choice can't override.
• The trade-off: GitHub itself warns that unexpected on-screen content can trigger unintended actions, and that anything visible in an app window becomes context for Copilot.

What GitHub Copilot computer use can do

According to GitHub's overview of computer use, Copilot reads an app through your operating system's accessibility tree, the structured description of buttons and fields that screen readers use, and takes screenshots when it needs to see the window. With that it can click controls, enter and edit text, press keys, scroll, drag items and move between apps in one workflow.

GitHub pitches it for software that offers no other way in: legacy tools and GUI-only programs. Its examples include summarizing information in an old desktop app, updating a presentation, filling in data in GUI-only software and moving information from one app to another. The same page says that when an API, an MCP server, a terminal command or a browser tool can do the job, that route usually gives more predictable results, so computer use is the fallback, not the default.

GitHub is also upfront about the limits. Computer use reads interfaces that change between app versions, operating systems and window states, so it can click the wrong control, type in the wrong field, struggle with unusual or moving controls, or repeat an action when timing shifts.

How to turn on computer use, step by step

You need a local session on a Mac or a Windows PC. On macOS, the first run walks you through two system permissions: Accessibility, so Copilot can operate app controls, and Screen Recording, so it can look at app windows.

In the Copilot CLI, following GitHub's CLI instructions:

1. Start an interactive Copilot CLI session.
2. Type /computer show to see whether the computer-use plugin, its MCP server and its skills are enabled.
3. Type /computer on. The CLI saves the preference and enables the bundled plugin.
4. On macOS, grant Accessibility and Screen Recording when asked.
5. Type /permissions show to see the active permission mode, which decides when Copilot asks before controlling an app.

In the GitHub Copilot app, per the app instructions:

1. Open the app's settings and select Computer Use in the sidebar.
2. Turn on Enable Computer Use.
3. On macOS, under Prerequisites, grant both permissions. If the app doesn't notice the change, click Check again.

Typing /computer on inside an app session works too. To switch it off, use /computer off or the same toggle.

GitHub's advice for prompts is to name the outcome, the apps involved and the limits. Its own example asks Copilot to open an app, summarize the status shown in its main window, and change no values and submit no forms. To stop a run that goes wrong, press Esc twice in the CLI, or click Stop or press Esc in the app.

Which plans and platforms get it

GitHub hasn't published a plan list for computer use itself as of October 2, 2026. It lives inside two products that GitHub's docs say are available on all Copilot plans: the CLI and the GitHub Copilot app. If you get Copilot through work, there's an extra condition: the organization's Copilot CLI policy must be enabled for the CLI, and the separate Copilot app policy, which is on by default, must stay on for the app.

The platform limit is narrower than the app's. The Copilot app itself runs on macOS, Windows and Linux, but GitHub lists computer use only for local sessions on macOS and Windows. GitHub's troubleshooting note adds that if the option doesn't appear, you should confirm "that the feature is available for your account", which suggests the preview may not reach every account at once.

Approvals, always allow and admin controls

Computer use follows the tool permission settings of wherever your session runs. When Copilot needs an app, the prompt offers three answers: Allow for the current session, Always allow for future sessions, or decline. GitHub asks you to check that the app and action in the prompt match what you requested.

"Always allow" is stored locally and shared: approve an app in the CLI and the approval also applies in the Copilot app on the same computer, and the other way round. You can review the list in the app under Settings, Computer Use, Always allowed apps, and delete any entry. One catch from the docs: removing an app stops future sessions from using the saved approval, but doesn't revoke access already granted to a running session. To cut that off, stop the operation and end the session. Deny rules you've configured always win over automatic or saved approvals.

For companies, the switch is features.computerUse in GitHub's enterprise managed settings. Setting it to false stops users from enabling computer use in the CLI and the Copilot app; leaving it out or setting true leaves the choice to each user. When it's blocked, the CLI says computer use is blocked by managed settings, and a user's local preference can't override it.

The security trade-offs of letting an agent drive your desktop

GitHub's own warning is blunt. Its documentation says ambiguous instructions or unexpected on-screen content "may cause unintended actions" affecting your device, data or connected accounts, including personal, financial or enterprise systems, and that computer use "is not a substitute for human judgment." It also notes that windows can show sensitive information, including other people's, and that you should only use the feature where you're comfortable handing that visible content to Copilot as context.

The "unexpected on-screen content" risk is the one AI companies call prompt injection: text on screen that the agent reads as an instruction. Anthropic, which offers a similar tool for its Claude models, says in its computer use documentation that a model can follow commands found in content even when they conflict with the user's, and it recommends a dedicated virtual machine or container with minimal privileges. GitHub's docs describe Copilot's feature running on your own Mac or PC, with your apps and accounts, which is why its approval prompts and the "Always allow" list matter.

GitHub's practical advice follows from that: avoid "Always allow" for apps that hold sensitive information or can take high-impact actions (a banking app or your email client would be obvious examples). WinCentral's coverage of the launch framed the shift as Copilot moving from suggesting an action to taking it. Agents acting on their own have already caused trouble elsewhere: a forensics firm says OpenAI agents scraped 55 websites, and a Dutch security nonprofit suspects an AI agent was behind a help desk breach.

What happens next

GitHub hasn't given a date for general availability or said whether the preview will change which plans or platforms get it. Until then, GitHub Copilot computer use can change without notice, and an admin who hasn't set features.computerUse leaves the decision to each developer. More software news is on our hub.

Bottom line

If you have legacy or GUI-only tools that Copilot can't reach any other way, GitHub Copilot computer use is worth a try on a Mac or Windows PC: /computer on in the CLI, or one toggle in the app. Start with read-only tasks like GitHub's own example, keep "Always allow" off for anything that handles money, messages or private data, and if you run Copilot for a company, decide now whether features.computerUse should be false while the feature is in preview.

FAQ

Is GitHub Copilot computer use available on Linux?

No. GitHub lists computer use only for local sessions on macOS and Windows, even though the Copilot app itself also runs on Linux. Remote sessions don't get it either.

Is computer use turned on by default?

No. GitHub says computer use is disabled by default, and you have to enable it with /computer on or the Enable Computer Use toggle in the app before Copilot can use its tools.

Can my company block Copilot from controlling desktop apps?

Yes. Enterprise admins can set features.computerUse to false in managed settings, which stops users from turning the feature on in the CLI and the Copilot app. A user's local setting can't override that policy.