A desktop monitor shows an AI assistant coordinating tasks across a browser, spreadsheet, and database interface.
GitHub Copilot can now control desktop apps directly, not just a terminal or code editor. Computer use is now available in public preview in GitHub Copilot CLI and the GitHub Copilot app on macOS and Windows. Copilot can now click buttons, type into forms and move between windows on your machine. That's useful, and it also deserves some caution.

What computer use can do​

GitHub lists the actions Copilot can take. It can read accessible app content and visual context, click controls, enter and edit text, press keys, scroll, drag, and navigate workflows across applications.

GitHub's pitch focuses on software that has no other way in. The company says this expands what Copilot can help automate, including workflows in legacy and GUI-only software that do not provide an API, command-line interface, or MCP integration.

Many offices still run tools like this: an old line-of-business app, a vendor portal, a reporting tool with no API. Until now an AI coding assistant couldn't do much with them. With computer use, Copilot works through the same windows and controls you do.

GitHub's demo is ordinary office work. It shows Copilot using computer-use tools to navigate an expense-report workflow in Safari. GitHub's other suggestions are similar. You can ask Copilot to summarize notifications in a browser, update content in a presentation, or move information through a workflow in a desktop application.

GitHub doesn't publish a compatibility list, and it doesn't promise that any particular third-party app will work. The Safari demo is an example, not a guarantee.

Section summary: Copilot can now act through visible, on-screen controls on macOS and Windows. It's aimed at software that has no API, CLI or MCP connection. It's a public preview with no published compatibility list.

Windows users: check which surface you're on​

The GitHub Copilot app also runs on Linux. WinBuzzer reported that it launched as a standalone agentic desktop client for macOS, Windows, and Linux on paid Copilot plans. Computer use doesn't cover Linux. GitHub's CLI documentation says it works only in local sessions on macOS and Windows.

That leaves two limits:

  • Linux users: Running the Copilot app or CLI on Linux doesn't get you computer use. GitHub's announcement and documentation only name macOS and Windows.
  • Remote or cloud sessions: The documentation says computer use is for local sessions. A Copilot session running in a cloud sandbox can't control apps on your own desktop.

Most WindowsForum readers are on a supported platform. If you use Linux or work remotely, check which surface you're on before assuming the feature is there.

How to turn it on​

GitHub gives two ways in.

In GitHub Copilot CLI​

  1. Start an interactive Copilot CLI session.
  2. Run /computer on. GitHub's documentation says the CLI saves this preference and turns on the bundled computer-use plugin.
  3. Use /computer show to check its status and /computer off to disable it. The status command shows whether the computer-use plugin, its MCP server and the related skills are enabled.

In the GitHub Copilot app​

  1. Open Settings, select Computer Use, and turn on Enable Computer Use.
  2. You can also use /computer on.

What success looks like​

When it's working, /computer show reports the plugin and MCP server as enabled. The first time Copilot tries to control an app, you should get an approval prompt, unless your permission mode or a saved approval skips it.

On macOS there's an extra step. Computer use guides you through the required Accessibility and Screen Recording permissions. GitHub doesn't describe a matching OS-level permission step for Windows, so don't expect one.

Approvals and permission modes​

GitHub's announcement puts it simply: "You remain in control. Copilot asks for approval before controlling an app, and you can review or reset apps that you have chosen to always allow."

The CLI documentation adds detail. Computer use follows whatever Copilot CLI permission mode is active, and that mode decides whether Copilot asks before controlling an app. Run /permissions show to see the current mode. When Copilot asks, you have three choices:

ChoiceEffect
AllowGrants access for the current computer-use session only
Always allowSaves the approval for that app for future sessions
Decline / cancelRefuses the request

There are two details GitHub's documentation calls out:

  • Always allow carries over between tools. If you always allow an app in the CLI, that approval also applies to computer use in the GitHub Copilot app on the same computer. One click covers both.
  • Deny rules still win. Any deny rules you've configured take precedence over saved approvals.

To stop an action in progress in the CLI, press Esc twice. GitHub also says to check that the app and action in each prompt match what you asked for. Don't approve prompts on autopilot.

In practice, "you remain in control" holds only if you keep approvals on a short leash. Each Always allow is convenient, but it also means Copilot won't ask next time.

Section summary: Whether Copilot asks first depends on your permission mode and any saved approvals. Always allow covers both the CLI and the app on that machine, deny rules override it, and pressing Esc twice stops a running operation.

Notes for IT admins​

Admins have one main control. Organization-managed settings can disable the feature. GitHub's documentation says that when the organization blocks computer use, the CLI reports that managed settings prevent it, and a user's local setting can't override that.

Access also depends on existing policies. The documentation says Copilot CLI is available on all Copilot plans, but if users get Copilot through an organization, the organization's Copilot CLI policy must be enabled. The app has a similar requirement. When it entered technical preview, GitHub said Business or Enterprise users needed their admin to have previews enabled and the Copilot CLI enabled in policy settings.

Before allowing this on managed Windows machines, think about these questions:

  • Which apps on these machines hold sensitive data, such as finance or HR systems?
  • Do you want users saving Always allow approvals, or should deny rules block certain apps?
  • Do you allow preview features on production endpoints at all?

GitHub's announcement doesn't explain how screen contents are processed or which model runs the feature. With that unknown, a cautious first rollout makes sense.

How it compares with Copilot Studio​

Microsoft already offers a similar feature for business automation. Computer use in Microsoft Copilot Studio gives agents the ability to work with websites and desktop applications. The two work differently:

GitHub Copilot computer useCopilot Studio computer use
Where it runsYour local Mac or Windows sessionThe agent uses its own computer to complete the task
GuardrailsPer-app approval prompts, permission modes, deny rules, org policyAn allow-list of permitted sites and apps; the run stops automatically if it tries to go outside it
Intended userA developer or knowledge worker at their own deskBusiness agents, including teams already using Power Automate desktop flows

Both target the same problem: getting AI agents into software that has no API. GitHub's version runs live on your own desktop while you watch, which is why the approval prompts matter so much.

Some users had been asking for this. A feature request in the VS Code repository earlier this year said Copilot "lacks the ability to interact with the desktop environment", which the requester said limited its usefulness for automation.

Getting good results​

GitHub's advice: computer use works best when you describe the outcome you want, the applications involved, and any important constraints.

The CLI documentation gives a good starting prompt: ask Copilot to open an app and summarize the status information in its main window, and tell it explicitly not to change any values or submit any forms. Starting with a read-only task like this lets you see how Copilot handles an app before you let it change anything.

A sensible order for trying it out:

  1. Start with a read-only summary task in one app.
  2. Choose Allow rather than Always allow until you trust how it behaves.
  3. State your limits in the prompt, for example "don't submit" or "don't delete."
  4. Check every edit or submission yourself before relying on it.

When it doesn't work​

GitHub's documentation lists these checks:

  • /computer show says it's unavailable: Confirm the feature is available for your account, that you're in a local session, and that you're on macOS or Windows.
  • Managed settings message: Your organization has blocked it, and only an admin can change that.
  • Enabled but nothing happens: Run /plugin to check that the bundled computer-use plugin is enabled, and /mcp list to check that its MCP server is connected.
  • macOS only: Make sure the computer-use helper has both Accessibility and Screen Recording permissions.

Bottom line​

This is a public preview, and GitHub says it may change. It's a real expansion of what Copilot can do: it can now operate any app you can see on screen, not just your code and terminal. That's most useful for old, GUI-only business software that nothing else can automate. Because Copilot is clicking around your actual desktop, start with read-only tasks, keep approvals per session, and check its work before anything important gets submitted.

 

References

  1. GitHub Copilot can now interact with desktop apps with computer use GitHub Changelog 2026-10-01T19:11:26+00:00
  2. Using GitHub Copilot CLI to interact with desktop applications - GitHub Enterprise Cloud Docs docs.github.com
  3. Add Computer Use / Desktop Automation Support to GitHub Copilot · Issue #297666 · microsoft/vscode github.com