Pimp My IDE / garage dispatchBack to the garage
October 12, 2026 / desktop agents / permission design

The screen is an authority boundary.

A desktop agent can cross application borders with clicks, keys, screenshots, and pasted text. Give each route its own fuse.

A shell sandbox does not explain who can read the screen or control a trusted application. Record desktop permission and command isolation separately.

Desktop control changes the unit of permission.

GitHub put computer use into public preview for Copilot CLI and its desktop app on macOS and Windows. The tool can read accessible content and visual context, click controls, enter text, press keys, scroll, drag, and move through workflows across applications.[1]

That is useful for legacy and GUI-only software. It also means permission cannot stop at "may run a command." The desktop route has four separate questions. What can the agent observe? Which applications can it control? What data can move between them? Which approvals survive the session?

A desktop approval grants a route through changing windows, not one fixed command over known arguments.

Use the narrow tool before the visual tool.

GitHub's documentation says an API, MCP server, terminal command, filesystem tool, or dedicated browser tool usually provides more structured information and more predictable results. Computer use is for tasks that require a visual interface.[2]

This is a routing rule, not a preference. A direct tool exposes named inputs and outputs. A desktop agent has to infer state from controls, accessibility data, screenshots, timing, and window position. Each extra inference is another place for stale state or the wrong target.

IF DIRECT_TOOL_EXISTS=YES
  USE_DIRECT_TOOL
ELSE
  NAME_APPLICATIONS
  NAME_ALLOWED_ACTIONS
  NAME_SENSITIVE_VIEWS
  SET_STOP_PATH
  REVIEW_RESULT

Saved approval is not current intent.

Computer use is off by default. When an application asks for approval, a user can allow it for the session, save approval for later sessions, or deny it. A saved "Always allow" decision applies to Copilot CLI and the Copilot app on the same computer. Removing it blocks future sessions, but does not revoke access already granted to a running session.[2]

That last detail belongs in the control itself. A permission list needs two actions: remove future approval and stop the active session. Showing only one creates a false kill switch.

Screen permission and shell isolation cover different routes.

On macOS, computer use asks for Accessibility permission to control application elements and Screen Recording permission to inspect windows when visual context is needed. Apple says third-party collection follows that party's terms and privacy policy, and macOS lets users review screen-recording access in Privacy & Security settings.[3]

Local sandboxing limits command access to files, networks, credentials, and system functions. GitHub says the sandbox is off by default. Without it, agent-run shell commands have the same access as the signed-in user. The local sandbox uses operating-system controls and is lighter than a separate virtual machine or container.[4]

Do not merge these controls into one "safe mode" lamp. A shell can be restricted while a desktop route sees sensitive windows. A desktop route can be disabled while a command still reads broad filesystem paths. Record both states.

The stop path has to match the live route.

GitHub documents a live interrupt. Press Escape twice in Copilot CLI. In the desktop app, use Stop or press Escape. The same documentation warns that changing layouts, timing, window state, ambiguous instructions, and unexpected on-screen content can cause wrong controls, repeated actions, or unintended changes.[2]

Put the stop instruction beside the control that starts desktop authority. Test it against a disposable workflow. Then review the target application, visible information, requested permission, result, and any saved approval before using the route on consequential work.

Interactive makeover / one broad approval replaced with four fuses

Wire the desktop route.

This browser-local panel drafts an authority review card. The checks select required sections. They do not inspect your machine, configure permissions, or prove isolation.

ObserveActTransferRetain

Choose the authority mode

Use the smallest mode that can finish the task. The selected mode changes the requested action, not the evidence status.

Authority mode
Authority card sections

Authority card empty

No route sections are selected. No desktop authority has been reviewed.

Four circuits open

Each selected circuit joins the review bus. Selection requests a field. It does not grant permission.

Review gate openSelect the sections that the operator must fill before the desktop route starts.
0 / 4 selected
Sources read / October 12, 2026

Source log

Open the release, permission, sandbox, and operating-system notes
  1. GitHub Changelog, "GitHub Copilot can now interact with desktop apps with computer use", published October 1, 2026 and read October 12, 2026. This is the first-party release notice for the public preview, supported interactions, approval prompt, and enable or disable commands.
  2. GitHub Docs, "About computer use in GitHub Copilot", read October 12, 2026. This documents direct-tool preference, application approvals, shared saved decisions, active-session revocation limits, interrupt paths, and stated risks.
  3. Apple Mac User Guide, "Allow apps to use screen and audio recording", read October 12, 2026. This covers macOS authorization, third-party privacy responsibility, and the settings route for reviewing access.
  4. GitHub Docs, "About cloud and local sandboxes for GitHub Copilot", read October 12, 2026. This documents default-off local isolation, filesystem and network controls, lighter-weight operating-system isolation, built-in-tool enforcement limits, and platform differences.
  5. GitHub Copilot weekly releases, October 5, published October 9, 2026 and read October 12, 2026. This was the discovery route for the local sandbox release and related agent controls.

Evidence boundary. This dispatch reviews published product behavior and documentation. It did not enable computer use, grant operating-system permissions, control a desktop application, or test a sandbox. The interactive fusebox is a planning aid. Its completed state means the template structure is selected, not that access is safe or configured.