GitHub Copilot gains desktop app control in public preview

GitHub has put computer use into public preview for GitHub Copilot CLI and the GitHub Copilot app on macOS and Windows, giving the assistant a controlled way to operate desktop applications when a cleaner interface is not available.

The new capability lets Copilot read accessible app content and visual context, click controls, enter and edit text, press keys, scroll, drag, and move through workflows that span multiple apps. GitHub says the feature is meant for cases such as legacy desktop software, GUI only internal tools, presentation updates, browser notification summaries, and expense report style workflows that do not expose an API, command line path, or MCP integration.

What changed for developers

The practical shift is that Copilot is no longer limited to code, terminals, browser work, or tool integrations inside the development stack. A developer can now ask it to help with a workflow that crosses a local app boundary, provided computer use is enabled. In the CLI, GitHub says users can run /computer on, check status with /computer show, and turn it off with /computer off. In the Copilot app, the control lives under Settings, then Computer Use.

That matters for engineering teams with important work trapped in older desktop systems. Release notes, compliance records, bug triage exports, and internal admin screens often sit outside neat APIs. Computer use gives Copilot a path into those workflows without first waiting for every system to grow a modern integration.

The boundary is permissions

GitHub is also framing this as a feature that needs active control. The changelog says Copilot asks for approval before controlling an app, and organization managed settings can disable the feature. The docs add that computer use is disabled by default, follows tool permission settings, and lets users save or deny access for individual applications. On macOS, Copilot guides users through Accessibility and Screen Recording permissions.

The security tradeoff is straightforward. The more useful desktop automation becomes, the more important it is to avoid broad standing approvals for apps that contain sensitive data or can make high impact changes. GitHub warns that computer use can select the wrong control, enter text in the wrong place, or behave differently when windows and app versions change.

What to watch next

For now, teams should treat the preview as a targeted automation tool rather than a replacement for stable integrations. It is best suited to repetitive GUI work where the user can inspect each step and where a mistake is easy to reverse. The strongest adoption signal will be whether enterprises can pair this kind of agent control with clear audit trails, narrow approvals, and policies that keep sensitive systems out of reach unless there is a deliberate reason to include them.

Sources

• github.blog
• docs.github.com

Cover photo by cottonbro studio on Pexels, used under the Pexels License.