Copilot computer use: removing saved approval does not end session access

Desktop reach creates a different permission decision

GitHub's October 1 announcement brought computer use to public preview in Copilot CLI and the Copilot app on macOS and Windows. Copilot can read application content and visual context, click controls, enter or edit text, and navigate desktop workflows. That opens a route to legacy business software without an API, command-line interface or Model Context Protocol (MCP) integration. It is not a new October 17 release. [1][2]

For a team considering that route, the consequential choice is not just whether Copilot can open the application. It is whether to save access beyond the task—and how to withdraw access already granted. GitHub's current documentation says deleting a saved app approval does not revoke access in a running session. A permission cleanup can therefore leave the current session's access intact. [2][3]

First check whether a structured route can do the job. GitHub says a direct API, MCP server, terminal command, filesystem tool or dedicated browser tool typically provides more structured information and predictable results when it can complete the task directly. That is provider guidance, not a performance comparison measured for this briefing. [2]

Saved approval, session access and interruption are separate

Computer use is disabled by default. Once enabled, it follows the tool-permission settings of the Copilot surface running the session. In the app, review Tool Permissions under Settings → Sessions. When approval is required, the documented choices are Allow for the current computer-use session, Always allow for future sessions, or decline/cancel. Do not read the announcement's simpler approval wording as a promise to ask before every action. [1][2][3]

• Saved approval: Always allow is stored locally and applies to both Copilot CLI and the app on that computer. Later computer-use actions can control the application without asking again. [2][3]
• Future-session cleanup: in the app, open Settings → Computer Use → Always allowed apps and click the delete icon beside the application. This deletes the saved approval for future sessions in both surfaces; it does not revoke already-granted running-session access. [3]
• Current-operation interruption: in the app, click Stop or press Esc. In Copilot CLI, press Esc twice. These are documented interruption controls, not evidence that completed edits were undone. [2][3]
• Session-access revocation: the app runbook separately instructs users to end the session to revoke application access granted to that session. Removing the saved entry and stopping an operation are not substitutes for this step. [3]

Other controls still matter. GitHub says deny-tool rules take precedence over automatic or saved approvals, and enterprise managed settings can disable computer use. On macOS, Accessibility and Screen Recording permissions support application interaction and visual inspection. Neither those OS permissions nor a saved app approval is a business decision authorizing every reachable action. This briefing does not establish an OS sandbox or test any of these controls. [2][3]

A short decision sequence before a GUI-only task

The following is our proposed operating sequence, not an executed Copilot procedure. GitHub warns that changing interfaces or window state can lead to wrong controls, misplaced text or repeated actions. Visible windows can also expose sensitive information. Its specific advice is to avoid Always allow for applications containing sensitive information or supporting high-impact actions. [2]

• Define the permitted result. Name the application and information Copilot may see, then separate preparation from consequential actions such as submission, payment, notification or deletion. If a structured direct route meets the need, evaluate that first.
• Inspect the starting permissions. Check the actual surface's tool-permission setting and existing saved app approvals. For an eligible bounded task, prefer current-session access when prompted over a persistent grant. That limits duration; it does not demonstrate a per-action confirmation barrier.
• Resolve any required business restriction before proceeding. If the task must exclude submission, establish how that restriction is enforced and checked. A written instruction to stop at a draft is not evidence of a technical block. Narrow or pause automation if the required boundary remains unresolved.
• Review actual effects before repeating work. If behavior is unexpected, interrupt it; separately end the app session to revoke its session-granted access and remove any saved approval that should not carry forward. Inspect the application's actual state before another attempt. A stop or error does not establish that a consequential action never happened. [2][3]

Completed hypothetical example: prepare an expense, do not submit it

Fictional planning example—not run. A team uses a GUI-only legacy expense application. Its proposed evaluation would use a separate training account containing only synthetic receipts. The requested output is a draft expense, not a submission, payment or notification. No such account or workflow was used for this briefing.

The team's completed decision is not to select Always allow. The production application contains personal and financial information and supports high-impact actions. At most, the team would consider session-limited access in the non-sensitive training environment after reviewing its actual tool permissions and separately established restrictions. Production submission remains outside the delegated task. This is a proposed business boundary, not a Copilot feature inferred from an approval prompt.

The unresolved condition is whether the training environment can exclude submission. If that restriction cannot be established, the decision is to narrow the task to reviewing synthetic information or pause GUI automation—not to assume that saying “do not submit” prevents a click. There is no claimed successful draft, time saving or verified restriction.

If the application had previously been always allowed, the proposed cleanup would address both time horizons: remove the saved approval for future sessions and end the current app session to revoke the access granted there. If an operation were active, use Stop or Esc to interrupt it first. Then inspect the actual application result before any further action; none of those controls proves that earlier changes were reversed. [3]

What this decision still depends on

All three sources are GitHub-owned. They clarify the provider's documented permission lifecycle, not independently verified implementation, revocation timing or task reliability. The current Docs pages were observed on October 17; their publication/update dates and equivalence to the October 1 wording were not established. Account-level availability, minimum compatible client versions and actual enforcement remain unverified here.

A demonstrated application-side restriction and an authorized check on the intended client could change whether a particular draft-only workflow is suitable. Until then, keep the choice narrow: use a structured route where it fits; otherwise decide which app access is justified, for how long, and who reviews the actual result. Removing a saved approval answers the future-session question—not the current-session one.