GitHub Copilot CLI Computer Use Preview Adds Desktop Control

What GitHub shipped

GitHub has moved its Copilot agent beyond the terminal and editor. On October 1, 2026, it released computer use as a public preview in Copilot CLI and the standalone GitHub Copilot app, on macOS and Windows only.56 With the feature on, Copilot can read app content through accessibility data and visual context, click controls, type and edit text, press keys, scroll, drag, and carry a workflow from one application to another.1 GitHub says the main target is legacy and GUI-only software that has no API, command-line interface, or MCP integration.1

The feature is off by default. In the CLI, developers turn it on with /computer on, check it with /computer show, and turn it off with /computer off. The app has a matching toggle under Settings.1 On macOS, setup walks users through granting Accessibility and Screen Recording permissions. Copilot also asks for approval before it controls any app, and organizations can disable the feature through managed settings.1

One week earlier, GitHub product manager Pierce Boggan described the use cases more broadly on X: automating expense reports, booking travel, and speeding up end-to-end testing. GitHub's own changelog shows Copilot working through an expense-report flow in Safari.1

How it works under the hood

Reports on the internals line up closely. The agent reads the operating system's accessibility tree first and takes screenshots only when it needs more visual context.25 In the CLI, the capability arrives as a bundled computer-use plugin backed by an MCP server. Users can troubleshoot with /plugin and /mcp list.68 Building it this way matters for developers. Computer use isn't a separate product. It's one more tool the agent can call, managed by the same plugin and MCP machinery Copilot CLI already uses for everything else.

Copilot CLI's public changelog suggests the work was under way well before the announcement. A June release note mentions skipping computer-use consent prompts in full allow-all sessions, and a September note says computer use now stays in sync between /computer and plugin toggles.24 The October launch looks more like a feature stepping out from behind a flag than a capability built in one sprint.

The scope is narrow. Computer use works only in local sessions. It doesn't cover Linux, even though the Copilot app runs there, and a Copilot session in a cloud sandbox can't control apps on a developer's own desktop.8 One governance-focused analysis notes that the managed-settings reference lists only the CLI and the Copilot app as supported surfaces, not VS Code, the cloud agent, or JetBrains IDEs.4

GitHub's own message: use something else first

The launch documentation spends a lot of space telling developers when not to use the feature. GitHub recommends direct APIs, MCP servers, terminal commands, filesystem tools, or dedicated browser tools whenever they exist, because they return more structured and predictable results.27 One developer outlet built its headline around that point. It also noted that GitHub openly warns about misclicks, stalls, and sensitive on-screen data ending up in the agent's context.7 Independent explainers draw the same line. They describe computer use as a fallback for interfaces with no programmatic way in, and they flag that visual automation can break when an app's UI changes.9

This caution is the right reading of what GitHub shipped. Copilot is not being turned into a general desktop robot. GitHub is filling a specific gap for teams whose workflows hit internal tools, old Windows apps, or vendor portals that will never have an MCP server.

The permission model, and where it falls short

The approval system is where the reporting gets most detailed, and most critical. When Copilot asks to control an app, the user can allow it for the current session, choose "Always allow" to save the approval for later sessions, or decline.4 Three details stand out:

• Approvals are shared across tools. An "Always allow" granted in the CLI also applies to the Copilot app on the same machine.48
• Deny rules always win. Any configured deny rule overrides saved approvals.28
• Revoking an approval doesn't stop a running session. Removing an app from the "Always allow" list leaves access in place for sessions already running.610

The third point is easy to miss and has real consequences. A developer who notices an agent doing something unexpected and deletes its saved approval hasn't actually stopped it. The documented way to interrupt an action in the CLI is to press Escape twice.48 One Japanese consultancy's advice to business users fits the situation well: start with tasks that can be undone if they fail, not with whatever the feature can technically do.10

For administrators, the control is a single managed-settings key, features.computerUse. Setting it to false blocks the feature, and no local setting can override that.4 One analysis points out a sequencing problem. Developers can grant the OS-level permissions themselves before an admin ever sets the key, so the policy decision should come before anyone clicks "Always allow."4

The reporting disagrees on one point. One roundup says GitHub hasn't published detailed guidance on what computer use may and may not touch, leaving teams to set their own limits, and describes the feature only loosely as interacting with "graphical environments."3 Several other outlets walk through GitHub's documentation on permission modes, deny rules, managed settings, and troubleshooting in detail.248 The better-sourced view is that GitHub's documentation is substantial. The real gap is that permission controls only work if people use them carefully, and a shared, persistent "Always allow" invites exactly the kind of careless approval that causes problems.8

There is also some uncertainty about how the feature behaves in practice. One summary of early user reports says it runs in the background without taking over the mouse, keyboard, or focused window. GitHub's documentation, as reported, doesn't confirm or rule that out. Developers should check it on their own machines before relying on it.

Late to a race the rivals started months ago

GitHub is not first here. At least one outlet framed the launch as GitHub catching up to computer-use features that OpenAI's Codex and Anthropic's Claude Code and Cowork had already shipped.7 The timeline backs that up. Anthropic's computer use came to Mac on March 23, 2026, through Claude Cowork and Claude Code, and reached Windows about ten days later.16 OpenAI released Codex Background Computer Use on April 16, 2026, as a macOS-first desktop feature.13 In May it added remote computer use, which lets Codex operate a Mac's desktop apps even with the screen locked, including from Codex Mobile.11 Google has focused on the browser, with a Gemini computer-use line that grew out of Project Mariner.13 Meanwhile, consumer access to Gemini CLI moved to Antigravity CLI on June 18, 2026.1112

That context explains GitHub's choices. Unlike OpenAI's locked-screen remote mode, GitHub requires local sessions and per-app approval, which is a deliberately conservative position.811 Copilot also supports Windows from day one. Compared with a macOS-first start, that could matter in enterprises still running Windows line-of-business software.813

Rival updates in October have focused on orchestration, not on screen control. One October comparison lists Codex CLI 0.162.0 adding managed Git worktrees and pinned tasks, Claude Code 2.1.296 adding model pinning and subagent-controlled context compaction, and the open-source OpenCode reaching 1.18.35 with signed macOS binaries and stats output.3 Seen together, the companies that shipped computer use earlier have moved on to managing parallel agents, while GitHub is closing a feature gap.

Part of a bigger Copilot push

Computer use didn't launch alone. On the same day, GitHub released dynamic workflows in public preview for the CLI, the Copilot app, and the Copilot SDK. These are reusable multi-agent orchestrations with checkpoints that can pause for human review.27 GitHub also introduced per-project local sandboxing in the Copilot app, which can limit filesystem access, network access, and Git credentials.5 New models arrived in the same stretch, including GPT-6.1 Sol and Claude Sonnet 5.5, alongside deprecations of older models that took effect October 2.

Taken together, these releases show a clear strategy. GitHub wants the CLI and the Copilot app to be a full agent runtime: one that coordinates multiple agents, runs them inside sandboxes, and now reaches into desktop apps when no API is available. One commentary argues that computer use is becoming a standard feature across major AI platforms rather than something that sets one vendor apart.25 For developers, that means the choice between tools will come down less to whether an agent can click buttons and more to how well its permission model, sandboxing, and admin controls hold up when an agent does something unexpected.

Bottom line for developers

Computer use in Copilot is a well-documented, cautiously scoped preview that arrives months after OpenAI and Anthropic. Its value is narrow but real for teams stuck with GUI-only tools. Sensible early adoption would start with read-only tasks, rely on session-scoped approvals instead of "Always allow," and set an organization-wide policy before the first developer turns it on.48