GitHub Copilot desktop computer-use preview: activation, app permissions and stopping actions

Which tasks suit desktop control? Check for direct tools first

The October 1 announcement confirms Copilot can interact with desktop apps: read accessible content and visual context, click, type and edit, press keys, scroll, drag and connect workflows across apps. Examples include gathering information from legacy desktop software or updating a presentation with verified content, beyond merely generating code.

The product documentation recommends direct API, MCP, terminal, filesystem or dedicated browser tools where available, as they generally produce more structured, predictable results. Desktop control fills GUI-only gaps; an available direct interface need not become automated clicking just because the feature is new. This article did not operate readers’ apps or independently test success rates.

Check entry points, activation and macOS permissions separately

Current documentation lists macOS/Windows support for GitHub Copilot CLI and Copilot app, disabled by default. Run /computer on in CLI. In the app, enable Enable Computer Use under Computer Use settings, or use /computer on. This article describes official controls without changing local switches. Neither source supplies a complete plan, region and minimum-version eligibility table, so do not promise immediate or free access to every account.

On macOS, setup requests Accessibility to operate controls and Screen Recording to inspect windows when visual context is needed. Feature activation, OS permission and application access are separate layers. Organizational settings can disable computer use; local activation cannot override enterprise policy. If access is missing, verify the client and organization configuration rather than adding extensions or changing networks instead of checking eligibility.

Saved access spans CLI and app; revoking it does not replace stopping

Computer use follows the current Copilot surface's tool-permission settings. An app-access request can be allowed for the current session, saved for later or denied. An announcement saying approval is requested does not mean confirmation occurs before every click. Explicit deny rules take precedence over automatic or saved approvals.

Choosing Always allow stores app permission locally for both Copilot CLI and app on the same computer. The app can list and remove individual permissions, affecting future sessions on both surfaces without revoking access already granted to a running session. If an ongoing action is wrong, interrupt it too; deleting the app from saved permissions does not mean it has stopped.

Verify results on a copy before expanding scope

Public-preview behavior depends on window state, app version, controls and timing, and may select the wrong location, enter the wrong field or repeat actions. Start with a nonsensitive document copy and explicit goals, apps and constraints so results can be compared easily with the original. This is a validation checklist, not a completed local demonstration.

1. Confirm official client access and organizational policy, then choose a copied file and one app. Specify output location, original content to preserve, and boundaries before saving or submitting.
2. Handle access requests under client permissions and assess current-session needs first. Do not automatically expand one experiment into long-term approval for every app.
3. Inspect tool activity in the session and compare the final document or interface values. A completion notice cannot replace checking the correct file, fields and quantities.
4. On error, press Esc twice in Copilot CLI, or click Stop or press Esc in Copilot app. After stopping, inspect completed changes and decide recovery; interruption does not imply automatic undo.
5. If you saved Always allow, inspect the app's list and remove permissions no longer needed. Handle running sessions separately, and review visible content and mutation effects before expanding to other apps.

Separate availability, permissions and network faults

The announcement establishes public preview only in the named desktop clients, without evidence of equivalent tools for Linux, mobile, every IDE or cloud agents. Visual context may contain information in the current app window. For payments, sharing or changing others' data, define app access and action boundaries first; interface control does not establish business authorization.

Enterprise disabling, OS permissions and tool permissions are not proxy-connection issues. Consult the proxy connection checklist only with network evidence such as timeouts, TLS or proxy authentication. Network tools cannot replace app approval, override enterprise policy or turn preview into GA. Update this same guide when eligibility, supported platforms or permission semantics change.