GitHub Copilot no longer operates only where code, a terminal or a structured integration is available. On October 1, GitHub released computer use in public preview for Copilot CLI and the Copilot app on macOS and Windows. Once enabled, the agent can read visible content, click, type, scroll, drag and navigate steps across applications.

That matters for processes still trapped in legacy or GUI-only systems with no API, command-line interface or MCP server. An expense workflow, for example, may require copying information from a browser, completing fields in an old application and updating a presentation. Copilot can now carry out those interactions through the interface, much like a person sitting at the computer.

This expands the reach of automation. It does not turn the interface into a dependable API.

The last mile of software without integrations

GitHub itself recommends using APIs, MCP servers, terminal commands, filesystem tools or dedicated browser tools when they are available. Structured controls tend to provide more predictable information. A visual interface can move a button, open an unexpected window or respond at a different speed.

In its official computer use documentation, GitHub acknowledges that the agent may select the wrong control, enter text in the wrong place, repeat an action or fail to continue. Application versions, window state and timing can change the outcome too.

Computer use covers the last mile of a process. It does not remove the fragility of automating a screen that can change.

The feature can be valuable when a proper integration is impossible or disproportionate. For frequent, critical or high-volume processes, however, visual automation should be treated as an architectural choice with a maintenance cost, not a universal replacement for integration.

Approval helps, but scope matters more

Computer use is disabled by default. A user must turn it on with /computer on in the CLI or through the app settings. Copilot may request approval before controlling a program, and organization administrators can disable the feature through policy. On macOS, it also relies on Accessibility and Screen Recording permissions.

Three decisions deserve attention before granting access:

  • which applications the agent may control;
  • which data can appear in the windows it observes;
  • which actions require human confirmation immediately before execution.

Users can save an “Always allow” approval locally, and that decision applies to both CLI and app sessions on the same computer. This removes interruptions, but it also permits later actions without another prompt. GitHub advises against always allowing applications that contain sensitive information or support high-impact actions.

A payroll screen, a financial system or a messaging tool should not be treated like a presentation editor. The technical permission may look the same. The consequence of a bad action does not.

Human control does not begin at the approval button. It begins with the applications, visible data and allowed consequences.

Start with a small, reversible test

GitHub recommends stating the desired outcome, the applications involved and important constraints. A responsible rollout should add a test environment, non-sensitive data and a task that is easy to reverse. Teams should also observe whether the agent recognizes an unexpected state instead of insisting on the next click.

Computer use moves Copilot toward broader work automation outside software development. The opportunity is meaningful for organizations that still depend on software without modern integrations. So is the boundary: the more authority an agent has over the desktop, the more disciplined permissions, supervision and error recovery must become.

Sources: GitHub's computer use announcement and its documentation of capabilities, permissions and risks.