GitHub Copilot Can Now Operate Your Computer. Don't Touch "Always Allow" Yet.

What shipped, exactly

On October 1, 2026, GitHub moved Copilot's new computer use capability into public preview for the Copilot CLI and the GitHub Copilot app, on macOS and Windows. The changelog entry is short and unhyped: Copilot can now interact with desktop applications on your behalf — reading accessible app content and visual context, clicking controls, entering and editing text, pressing keys, scrolling, dragging, and navigating workflows across applications.

The target is the automation blind spot nobody has quite solved: professional software with no API, no CLI, and no MCP server. Legacy enterprise tools. Vendor portals that predate REST. Slide decks. Expense-report workflows — GitHub's own example is Copilot navigating an expense report in Safari. The pitch is a natural-language instruction instead of a custom automation script: describe the outcome, and Copilot figures out the clicking.

A few facts that keep the story honest. The feature is disabled by default — nothing changes until you switch it on. It is not in VS Code in this release (the October 1 announcement names only the CLI and the standalone app). There is no Linux support listed, no general-availability date, and no pricing or plan tier mentioned. And GitHub's own documentation says the quiet part out loud: when an API, filesystem command, or purpose-built tool exists, that route gives more structured information and more predictable results. Computer use is the fallback for when the interface itself is the obstacle — slower, less repeatable, and fragile when a dialog moves or an app updates its layout.

The permission model is the feature

Copilot asks for approval before controlling an app, and the approval dialog is where the interesting design lives. Three choices: allow for the current session, save an always allow for future sessions, or deny. The "always allow" grant is stored locally and applies to both the CLI and the app on the same machine. You can remove a saved approval from the app's settings — but that removal only affects future sessions; it does not revoke access already granted in a running one. Deny rules, where set, take precedence over saved approvals. And organizations can disable the whole feature through managed settings, a policy a local user cannot override.

On macOS, first-time setup walks through two separate OS-level grants: Accessibility permission (to actually interact with controls) and Screen Recording permission (to inspect windows when visual context is needed). This is worth pausing on. Screen Recording means the agent is looking at your screen — which means it sees whatever is on it.

There is no blanket guarantee that Copilot asks before every click. Once access is granted, the agent can perform multiple interactions within the session. The documented escape hatches are Stop or Esc in the app and a double Esc in the CLI to interrupt an active operation. For a first run, session-only permission is the easier-to-audit choice: grant the smallest set of applications the task needs, review each proposed action in context, and don't leave finance or admin software broadly approved.

How to turn it on (the useful version)

In the Copilot CLI: run /computer on, use /computer show to check its status, and /computer off to disable it. In the Copilot app: Settings → Computer Use → Enable Computer Use (the /computer on command works there too). If your organization disabled the feature, the local toggle can't override that policy.

The best prompting guidance is also the least magical: describe the outcome you want, the applications involved, and the constraints. "Read the totals in this expense window and put them in a draft spreadsheet. Stop before submitting either form" beats "handle my expenses," because it names the visible sources, the destination, and the exact point where a human should inspect the result. A narrow first run tells you more than a broad one: pick a reversible task, state the boundary, watch the session trace to confirm the agent is reading the intended window and writing into the right field, then check the numbers against the source yourself. A successful click is not proof the right data moved. Visual interfaces are stateful — a popup, a delayed load, or a shifted button can make a repeated action unsafe.

Why this week of all weeks

Timing makes this launch read differently. Days before the announcement, researchers documented roughly 13,000 internal screenshots — billing records, money-movement consoles from real companies — that AI coding agents had uploaded to public GitHub repositories through a screenshot tool that defaulted to a public repo. We covered that story in detail last week: the agent solved the "share a screenshot" problem by publishing it to the world. An agent that can see your screen can leak what your screen shows.

This week also brought a reminder that the safety layer is thinner than the marketing suggests. Researchers at Salt Labs demonstrated bypassing the prompt-injection protections of an AI agent called Manus by encoding a hidden instruction in JavaScript obfuscation and planting it in an email — the agent decoded and executed arbitrary code before its security mechanisms intervened. The specific flaw was patched, but the pattern is the lesson: prompt inspection is necessary, not sufficient. And GitHub's own documentation concedes the point in plain language — visible windows may contain other people's information, and unexpected on-screen content can influence an agent's behavior. An agent that reads the screen reads everything on it, including text an attacker hid there.

That is what makes the defaults of this launch interesting. Disabled by default, per-app approval, an always-allow list you can review and reset, an org-level kill switch, deny rules that win. These aren't friction bolted onto a feature — they are the feature. The industry spent 2026 learning that controlling an agent's tools matters at least as much as inspecting its prompts, and this release is built like someone internalized that lesson.

What to actually do this week

If you're an individual developer: switch it on, but keep it on a leash. Pick one reversible, GUI-trapped task — a vendor portal, a slide deck update, moving numbers between two apps — and run it with session-only approvals. State the boundary in the prompt, watch the trace, verify the output against the source. Keep it away from anything holding credentials, money movement, or other people's data until you've seen it behave. And leave "always allow" alone for now; a stored, cross-surface grant is a convenience you should earn with repetition, not grant on day one.

If you run a team: make the org-level decision before anyone asks you to. Disabling computer use until general availability is the defensible default; allowing it with explicit deny rules for sensitive systems is the middle path. Either way, decide it on your schedule, not after someone's expense report ends up somewhere interesting.

Watch for the two missing surfaces: VS Code and Linux. Neither is in this preview, but both would change who this reaches — and how much of a developer's day an agent can touch. This is the boring, permission-gated version of agent autonomy. That's exactly why it's worth paying attention to.

References

• GitHub Changelog — "GitHub Copilot can now interact with desktop apps with computer use" (October 1, 2026)
• izood.net — "GitHub Copilot Computer Use: Setup, Apps & Safety" (October 3, 2026)
• Technobezz — "GitHub Copilot Gains Computer Use for Desktop Apps" (October 1, 2026)
• SC Media — "Researchers bypass AI agent protections with JavaScript obfuscation" (October 3, 2026)
• Byte by Mahmud — "PixelLeak: Your Coding Agent Solved the Screenshot Problem by Making It Public" (October 3, 2026)