GitHub Copilot Computer Use: One Admin Switch, Sandbox Unclear

GitHub spent the first week of October 2026 pushing Copilot in two directions. It made its coding agent more capable and more contained, but not necessarily in ways that line up. On October 1, it put computer use into public preview, letting Copilot drive desktop applications. Six days later, it declared local sandboxing generally available. Read together, the two announcements leave organizations with an uncomfortable question: which of Copilot's new powers are actually covered by its new walls?

What computer use does

Computer use lets the Copilot CLI and the standalone Copilot app on macOS and Windows operate graphical software directly. The agent reads the screen through the accessibility tree or screenshots. It then clicks, types, sends keystrokes, scrolls, drags, and chains actions across multiple apps. GitHub is pitching this at legacy tools that have no API or command-line interface 2. The broader framing is that Copilot no longer has to stop at the edge of the terminal or editor when a workflow touches a visual interface 5.

The feature is off by default. Developers turn it on with /computer on in the CLI, check its state with /computer show, and disable it with /computer off. The app has its own toggle under Settings 24. On macOS, the agent also needs Accessibility and Screen Recording permissions 2. Tool approvals marked "Always allow" are shared between the CLI and the app on the same machine 2.

The launch also has a competitive context. OpenAI's Codex CLI, Anthropic's Claude Code, and the open-source OpenCode project all shipped agent updates in the same window, and GitHub reshuffled the models inside Copilot at the same time 5.

What the sandbox covers

Local sandboxing started as a public preview on June 2, 2026. At that point it focused on isolating shell commands Copilot launched 1. It reached the Copilot app as an opt-in, per-project preview on September 23 1. As of October 7, it is generally available in the Copilot CLI, the Copilot app, and VS Code sessions that use Agent Host 1.

The mechanism is OS-level isolation through Microsoft eXecution Container (MXC), with a different backend on each platform [3]:

• macOS: Seatbelt
• Linux: Bubblewrap
• Windows: ProcessContainer, which was limited to Insiders builds during the preview

The scope is specific. The sandbox wraps shell commands, built-in searches, and local MCP and LSP servers as child processes 3. Inside it:

• The working directory is read/write, and the rest of the repository is read-only.
• Tools on PATH are read-only, so commands cannot tamper with their own dependencies.
• System locations and the home directory are read-only.
• Outbound internet and local network access are controlled separately 3.

A cloud mode is also available. It moves the entire session into an ephemeral, GitHub-hosted Linux container 3.

The gap, and the one switch

None of the sandbox descriptions mention GUI automation. That omission matters. The sandbox constrains processes Copilot spawns, such as files touched, network calls made, and binaries modified. Computer use works differently. It acts through the user's own desktop session, clicking inside applications the developer already has open and already has rights to. Restricting a child process's filesystem view does not obviously limit an agent typing into a logged-in admin console or an email client.

The sources do not explicitly confirm whether computer-use actions fall inside MXC's boundary. Based on how the isolation model is described, though, it would be unwise to assume they do.

That makes the governance controls carry most of the weight. Enterprises can block computer use through managed settings 2. In practice this comes down to a single key, features.computerUse. Setting it to false prevents developers from enabling the feature, and admins can confirm the block by trying /computer on on a test machine 4.

There is a timing problem, however. Developers can grant the OS-level permissions themselves before any policy is in place 4. Because the feature is opt-in, exposure begins when an individual developer decides to try it, not when an organization decides to allow it 4.

What to make of it

The defensible reading is that GitHub has built two separate safety stories:

• Process isolation for the agent's shell and tooling, now mature enough to call GA.
• Policy gating for desktop control, which remains a preview with a binary on/off control.

This is a reasonable sequence for a preview feature. Still, "Copilot is sandboxed" should not be read as "everything Copilot does is sandboxed."

For security teams, the practical steps follow directly:

1. Set features.computerUse deliberately rather than leaving it to individual developers.
2. Review which machines have already granted Accessibility and Screen Recording rights.
3. Treat "Always allow" approvals as shared across the CLI and app 2, not scoped to one tool.

Until GitHub documents how, or whether, desktop actions are contained, the admin switch is the control organizations can verify.