GitHub Copilot Computer Use: One Admin Switch, Real Risks

GitHub has given its Copilot coding agent eyes and hands outside the terminal. A new computer-use capability, now in public preview, lets the agent operate graphical desktop applications. For enterprise administrators, the control model is thin, and it arrives as researchers are already showing how Copilot's command-line agent can be turned against the developer running it.

What GitHub shipped

GitHub's changelog announced on 1 October 2026 that computer use is available in public preview in both Copilot CLI and the standalone Copilot app, on macOS and Windows.2 In the CLI, developers toggle it with /computer on, check its status with /computer show, and disable it with /computer off. In the app, the setting sits under Settings > Computer Use.2

Once enabled, GitHub's documentation says Copilot can:

• read accessible application content and visual context
• click controls
• type and edit text
• press keys and scroll
• drag items
• move through multi-step workflows

GitHub also notes the feature is "subject to change" while in preview.2

The pitch is straightforward. Until now, an agent working in a terminal hit a wall the moment a task required a visual interface, and the developer had to take back manual control.3 Computer use is meant to close that gap so the agent can carry tasks into GUI-only tools.3

The competitive backdrop

The timing is not accidental. The release landed in the same October cycle as a broader model reshuffle inside Copilot. It also coincided with a run of updates from rival agent tools: OpenAI's Codex CLI, Anthropic's Claude Code, and the open-source OpenCode project.3 Terminal-based coding agents have become a crowded field, and expanding what an agent can physically touch is an obvious way to differentiate. Copilot CLI looks markedly different from the tool that existed only months ago.3

One switch for admins

The governance story is less polished. Computer use is off by default, so exposure begins only when a developer opts in.2 But the only administrative lever described is a single setting, features.computerUse, that blocks the feature outright.2 There is no indication of finer controls, such as limiting which applications the agent may drive.

There is also a timing wrinkle. Developers can grant the required operating-system permissions themselves, before any administrator has set a policy.2 On macOS, the app needs two separate OS-level permission grants to function.2 In practice, an organization that hasn't acted is relying on individual developers' judgment about what the agent should be allowed to see and click.

That leaves security teams with a binary choice: disable the feature organization-wide, or allow it and accept that the agent can act inside any application the user can reach.

Why the injection research matters here

That choice looks sharper given separate research from Adversa AI on Copilot CLI. The firm described an encrypted prompt-injection technique. An attacker-controlled web page carries instructions in encrypted form and asks the agent to decrypt them in its local code-execution environment.1 Because the payload isn't readable text at first, conventional prompt-injection filters may not flag it. Once decrypted, the instructions can appear to come from a trusted execution step rather than an untrusted website.1 The researchers say this could lead the agent to read sensitive local files and send their contents to an attacker's server. They add that the risk extends beyond environment files to whatever else the agent can access.1

It's important to be precise. The Adversa finding concerns how Copilot CLI handles fetched web content and code execution. It is not described as an exploit of the computer-use feature itself.1 The sources don't connect the two directly, and GitHub's announcement doesn't address it.

Our read

Even so, the logic is hard to ignore. The Adversa research shows that the agent's own reasoning can be steered by content it encounters, and that its trust boundaries can be blurred.1 Computer use widens what a steered agent could do, from reading files to clicking and typing inside desktop applications.2 A single on/off switch is a reasonable starting point for a preview. It is a blunt instrument for an agent whose reach now extends to the whole desktop.

For most organizations, the prudent move is to set features.computerUse to off now, before developers start granting permissions on their own.2 The feature can then be re-enabled deliberately for specific teams once GitHub offers more granular policy or clearer mitigations. Computer use may well become standard for coding agents across the industry.3 The question is whether the controls will mature as quickly as the capabilities.