GitHub Copilot's Computer Use Preview vs Claude and OpenAI's New Agent Stack (October 2026)

GitHub shipped computer use for Copilot into public preview on October 1, 2026, for macOS and Windows. The pitch is narrow and specific: Copilot can click controls, type and edit text, press keys, scroll, drag, and carry a workflow from one application into another, targeted specifically at the long tail of desktop software that has no API and no command line interface to automate against. It is approval gated by design. Copilot asks before it takes over an app, and the user can review or reset the list of apps they have permanently allowed. On macOS, setup requires granting Accessibility and Screen Recording permissions, the same operating system level permissions any screen automation tool needs, and organizations can disable the feature entirely through managed settings.

Two days before that, at its own DevDay, OpenAI shipped something architecturally different: Dots, described as persistent workers rather than chat threads. Each dot gets its own isolated cloud computer and browser environment, separated from the user's personal machine unless deliberately connected, and runs continuously in the background, able to manage multiple projects and learn from feedback over time rather than resetting at the end of a session. Dots integrate with more than four thousand apps through OpenAI's plugin ecosystem, with governance controls that let an organization set rules to allow, require approval for, or block specific actions, plus an auto review step before consequential operations. The current generation runs on GPT 6 Astra. A first dot comes bundled with ChatGPT Pro and Business Premium at no additional cost, and dot conversations do not count against standard ChatGPT usage limits, though OpenAI has not published pricing for additional dots beyond the first.

Two different trust boundaries, two different failure modes

The architectural difference here is not cosmetic. Copilot's computer use model runs the agent on hardware the user already trusts, with the operating system's own permission model as the backstop, and the practical risk is the one GitHub's own design explicitly addresses: an agent with desktop control is one over broad approval away from touching something it should not. The per app allow list and the ability to review and reset permissions is a direct response to that risk, and it keeps the blast radius of any failure bounded to whatever is already running on that machine.

Dots' isolated cloud computer model moves the blast radius question somewhere else entirely. Because each dot runs on its own machine, a Dot that misbehaves cannot directly touch the user's actual laptop the way a desktop computer use agent theoretically could if its guardrails failed. What it trades for that isolation is the exact pattern this week's other major story illustrates: an agent with its own persistent internet connected computer and background execution is precisely the shape of system that needs airtight egress controls, because the agent, not the user, is now the thing deciding what that computer talks to while nobody is watching. A persistent, always on agent with its own browser and continuous background operation is a materially larger attack surface than a session scoped agent that only acts while a human is present to interrupt it.

{
  "agent_policy_illustrative_example": true,
  "allow": [
    { "action": "read_file", "scope": "project_directory" }
  ],
  "require_approval": [
    { "action": "send_email" },
    { "action": "execute_shell" }
  ],
  "block": [
    { "action": "outbound_request", "unless": "domain_in_allowlist" }
  ]
}

A policy shaped like that, explicit allow, require approval, and block tiers evaluated per action rather than a single binary permission grant, is the common thread across every computer use and persistent agent product shipping right now, Copilot's, OpenAI's, and Anthropic's included. The products differ in where the agent physically runs and how long it persists, not in whether they need this kind of tiered control. If you are building your own agent harness rather than buying one, that three tier structure, allow, require approval, block, evaluated at the action level rather than the session level, is the baseline worth copying regardless of which vendor's compute model you build on.

Why the persistence question matters more than the click accuracy question

Most early coverage of both releases focused on task success rate: can the agent actually click the right button, fill the right field, finish the workflow. That is a real and measurable question, and it is also the easier one to improve over time with more training data and better grounding. The harder, more durable question is what happens when these agents are not session scoped. Copilot's computer use is explicitly interactive, it asks before taking over an app, which bounds it to moments when a human is present to say no. Dots are explicitly the opposite: designed to keep working while no one is watching, which is the entire point of a persistent worker, and also the exact property that turns a narrow automation mistake into a multi day unsupervised one if the governance rules around it are wrong.

For a team deciding between these models, the real question is not which agent clicks more accurately today. It is whether your organization is set up to monitor and audit an agent that keeps running after everyone has gone home, with the same rigor you would apply to any other unattended production system with network access.

When this applies to your stack

If you are evaluating computer use or persistent agent products for your own engineering or operations workflows, treat the architecture question, session scoped and interactive versus persistent and isolated, as the primary decision criterion, and treat task success rate as secondary. A session scoped agent on a trusted machine and a persistent agent on an isolated cloud machine solve different problems and carry different operational obligations. If you want help designing the governance and monitoring layer around either model before you roll it out to a team, that is the kind of agentic infrastructure work we do for clients building on Claude, OpenAI, or a mixed stack.

FAQ

Can GitHub Copilot's computer use feature run unattended like OpenAI's Dots? No. Copilot's computer use is interactive by design, asking for approval before taking over an app, which keeps it bounded to sessions where a user is present. Dots are explicitly built to run continuously in the background without a user watching.

What does a Dot actually run on? The current generation of OpenAI's Dots runs on GPT 6 Astra, with each dot given its own isolated cloud computer and browser environment separate from the user's personal machine.

Is Copilot's computer use available to everyone? It is in public preview for macOS and Windows as of October 1, 2026. GitHub has not announced general availability timing, pricing, Linux support, or whether free tier users will get access.

How does this compare to Claude's computer use capability? Claude's computer use has been benchmarked separately against OpenAI's Operator and Perplexity's Comet on OSWorld and WebArena; see our dedicated comparison for those results. The architectural question in this piece, session scoped versus persistent and isolated, applies across all three vendors' approaches.