GitHub Copilot computer use lets the Copilot CLI and the Copilot app click, type and drag inside desktop applications on a developer's laptop. It's off by default, so the exposure starts when a developer opts in. Admins have one switch to block it outright, features.computerUse, and developers can grant OS-level permissions on their own before anyone sets it. Our view is that the policy call belongs before the first "Always allow" click. It sits alongside our wider coverage of AI coding agents and what the research actually shows.
What GitHub shipped on 1 October 2026
GitHub's changelog says computer use "is now available in public preview in GitHub Copilot CLI and the GitHub Copilot app on macOS and Windows." In the CLI you switch it on with /computer on, check it with /computer show and turn it off with /computer off. In the app it's Settings > Computer Use > Enable Computer Use.
GitHub's concepts page lists what Copilot can do once it's on: read accessible app content and visual context, click controls, enter and edit text, press keys, scroll, drag and move through multi-step workflows. It also carries the caveat that the feature is "in public preview and subject to change."
What it can reach and the permissions it needs
On macOS, the app how-to says Copilot needs two grants: Accessibility, described in-app as "allow computer use to interact with application controls," and Screen Recording, "allow computer use to inspect application windows when visual context is needed." There's a "Check again" button once the user has granted them.
On Windows, the docs we reviewed list no prerequisites. We won't guess at what's missing.
Approval is per app. Copilot asks for approval when the active permission mode requires it, and the user picks one of three outcomes: allow for the current session, "Always allow" (saved for future sessions), or decline. In the CLI, pressing Escape twice stops a running action. In the app, press Esc or click Stop. The CLI how-to adds the detail that matters for policy: saved approvals also apply to the app on the same computer. One click in the CLI is a standing approval in both tools.
The risks GitHub names itself
The concepts page doesn't oversell. It says 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."
Two pieces of its advice are worth repeating to developers. "Always allow" is stored locally, and GitHub says to avoid it for apps with sensitive information or high-impact actions. GitHub's own caveat is that Copilot "can select the wrong control, enter text in the wrong location", which is the practical reason a standing approval is risky. And try the direct route first: if "an API, MCP server, terminal command, filesystem tool, or dedicated browser tool can complete the task directly, that tool typically provides more structured information and predictable results." Computer use is the fallback for desktop apps with no API.
This is a different kind of reach from what we covered in how Copilot's local sandbox restricts files and network. A sandbox bounds what a session can touch in the repo and on the network. Computer use points the agent at GUI apps outside the repo altogether. Claude Code mods, which run with the user's own access, widen an agent's reach in a similar way: the limit is whatever the developer's machine can do.
What admins can control, and what they can't
The enterprise-managed-settings reference documents one key, features.computerUse. Set it to false and users can't enable computer use. Set it to true, or leave it out, and users control it through local settings. The reference says "a local setting cannot override this restriction," so a false holds.
The scope is narrow. The setting covers the Copilot CLI and the Copilot app. It doesn't cover VS Code, the cloud agent or JetBrains. The reference names the file managed-settings.json and lists MDM, server-managed and file sources as delivery methods, but it gives no per-OS file paths, and the GitHub pages we reviewed don't say which Copilot plans include computer use. We're not going to fill those gaps with a guess. For how this fits with deny, ask and allow rules for shell and file edits, see setting deny, ask and allow rules for Copilot agents.
How to decide: disable or allow
1. Inventory which desktop apps a team would automate
Ask each team to name the desktop apps they'd point Copilot at. This is judgment, not a GitHub requirement, but a list of zero names is an answer on its own.
2. Check whether an API, MCP server or CLI covers the task
GitHub's own guidance is to prefer those tools. Anything on your list that has an API or a terminal interface doesn't need computer use.
3. Set features.computerUse in managed settings
To block it, put false in managed-settings.json through whichever of the documented methods you already use. Leave the key out, or set true, to let users decide. The reference gives the key name and values but we haven't reproduced its file syntax here, so copy the format from that page.
4. If allowing, set expectations on "Always allow"
Tell developers to skip "Always allow" for apps with sensitive information or high-impact actions. They can review saved approvals in the app under Settings > Computer Use > Always allowed apps and use the delete icon. Per the app how-to, removing an application "deletes its saved approval for future sessions in both the app and CLI."
5. Check status on a test machine
Run /computer show to see whether the computer-use plugin and MCP server are enabled, and /computer off to turn it off for a user. With false set in managed settings, run /computer on on a test machine. GitHub says the CLI then reports that it is blocked by managed settings. This is our suggested test, not a documented procedure.
What this means for your AI tooling policy
Judgment, not GitHub's advice: default to false during the preview. The cost of waiting is small, because teams without a named desktop app that lacks an API lose nothing. The cost of not deciding is that any developer who opts in can grant Accessibility and Screen Recording and a standing "Always allow" on their own laptop, and that approval spans the CLI and the app.
Re-open the question per team when someone names a legacy desktop tool they need automated. Then allow it, with the guidance on sensitive apps from step 4. Because the preview is "subject to change," put a review date on the policy. When the policy is set, a plan for measuring what your AI coding spend returns is the next place to go, since a feature you've blocked shouldn't be in the number you're measuring.
FAQ
Is Copilot computer use on by default?
Computer use is off by default. GitHub's concepts page says it is "disabled by default", and users turn it on with /computer on in the CLI or Enable Computer Use in app settings. Admins can block it before anyone does.
Can an organization disable it?
Yes. Set features.computerUse to false in managed settings. GitHub says a local setting cannot override that restriction.
Does it work in VS Code or the cloud agent?
No. The managed-settings reference lists the CLI and the Copilot app as supported, and not VS Code, the cloud agent or JetBrains.
Which Copilot plans include computer use?
The GitHub pages we reviewed don't state plan eligibility. Check your organization's admin settings and GitHub's current docs before you plan a rollout.
Does Windows need extra permissions?
The docs list no Windows prerequisites. macOS needs Accessibility and Screen Recording.