GitHub Copilot's Cloud Handoff Changes Where Agent Work Runs, and Who Pays

TL;DR: GitHub's October 28 release lets users on paid Copilot plans resume one cloud session across web, mobile, CLI, the Copilot app and VS Code; Slack and Teams can initiate work with the required organization setup.^[1] From November 2026, a cloud sandbox's running compute and allocated memory draw on the same monthly dollar-based allowance as eligible Actions jobs. GitHub lists that allowance at $12 for Free, $18 for Pro or Team, and $300 for Enterprise Cloud, but Copilot Free does not unlock the new cloud experience.^[1][5]

GitHub announced the connected Copilot cloud experience at Universe on October 28, 2026.^[2] The pitch is continuity: begin a task from an issue on a phone, inspect it on the web and steer the same session from a development client. GitHub says cloud sandboxes and the cross-surface experience are generally available on paid Copilot plans, with a rollout beginning October 28.^[1]

The real story isn't merely another place to chat. GitHub is turning an agent session into portable work while making its execution environment an explicit operational and billing choice. A prompt started in the cloud can outlive the device that sent it; its compute still belongs on somebody's bill. This article describes a workflow to evaluate from GitHub's published documentation. It does not claim that LLM Rumors ran a production session or measured its performance.

Cover image: generated editorial metaphor for a work folio moving along a crimson thread between devices, a compute workshop and an hourglass. It depicts neither the GitHub interface nor measured usage.

Session Continuity: Carry the Task, Not the Laptop

GitHub's model has three parts: the client where a person talks to Copilot, the session containing the conversation and activity, and the environment where commands run. A cloud sandbox is a GitHub-hosted Linux environment, separate from the user's machine. GitHub says it clones the relevant repositories, runs commands and tests there, and snapshots stopped work so it can resume in another client.^[3][8]

A practical handoff begins at the repository, issue or pull request. Attach the relevant context, ask for a bounded change and inspect the session log before requesting a pull request. GitHub says a web session opened over a pull request, file or repository attaches that page as context; its mobile interface accepts voice, images and files. The supported clients show the same cloud session list, so the next device can continue the same task instead of reconstructing the prompt.^[1][8]

Slack and Teams add another entry point: with organization policies enabled and the GitHub app connected, a user can mention @GitHub to request a code change or investigate a bug. Treat that as an intake path, not an automatic approval to merge. In organizations, single sign-on governs access to session data; without repository write access, Copilot is read-only.^[1]

What's often overlooked is the local exception. Copilot CLI sessions run on the user's machine by default. copilot --cloud starts an interactive cloud sandbox session; GitHub says the flag cannot be combined with the CLI's -p or -i modes. Remote control of an existing local CLI session from mobile leaves the original machine running and online. It is a different workflow from moving execution into a cloud sandbox.^[3][9]

Environment Choice: Cloud, Actions or Your Own Machine

GitHub documents Cloud, Actions and Remote environment choices. Cloud is the default where the client offers Cloud versus Actions. You choose at session start and cannot switch that session's environment later; start a new session if the task needs another environment.^[3][8]

These distinctions come from GitHub's environment documentation, not a speed ranking.^[3][8][9] A cloud sandbox respects repository and organization firewall rules. A newly allowed host requires a new session for the change to apply. If a task needs Actions setup steps, a self-hosted runner or Windows, select Actions at the start.^[3]

Here is the genius in the handoff, and its limit: a preserved cloud session removes prompt reconstruction across devices, but it does not make the local filesystem magically available. GitHub says commands in a cloud sandbox cannot read or change files on the user's computer. If the work depends on uncommitted local state, place that state in an authorized repository workflow or keep execution local.^[3] Our earlier cloud-versus-local task execution analysis examines that boundary from another product angle.

Billing Split: Actions Dollars Are Not AI Credits

GitHub changed the included Actions compute entitlement from a fixed standard-runner minute count to a shared dollar value. Eligible private or internal repository jobs on standard GitHub-hosted runners and cloud sandbox compute and memory draw from that value. Team and Enterprise Cloud accounts can also use it for larger hosted runners. Public-repository standard hosted jobs and self-hosted runners remain independently free under GitHub's stated rules.^[1][4]

The dollar figures are GitHub's listed GitHub account compute allowances, not included Copilot AI credits and not a promise that every account can start a cloud session.^[5] The pricing model also has three sandbox meters: running compute at $0.000024 per compute second, allocated memory at $0.000003 per GiB-second, and stopped-session snapshot storage at $0.005 per GiB-month, according to GitHub. GitHub's worked example prices 600 seconds and 4 GiB at $0.0216 of compute plus memory before any snapshot storage charge.^[4]

Let's be clear: the monthly pool is shared capacity, not a separate agent coupon. No eligible product has priority. A private-repository CI workload can reduce the remaining allowance for sandboxes, and sandbox use can reduce what remains for CI. Usage beyond the included amount follows the account's payment method and budgets; if there is no valid payment method, GitHub says use is blocked when the allowance is exhausted. A cloud sandbox budget must be product- or SKU-based. GitHub explicitly says the Bundled AI credits budget does not control sandbox spending.^[4]

A Safer Handoff: Route, Budget and Review

The uncomfortable truth is that seamless access can hide operational ownership. A session touching repositories is billed to their common owner; a repository-free session is billed to the selected owner, or the personal account by default. GitHub restricts multi-repository work in one sandbox to repositories with the same owner.^[4] A team should check that owner before treating a chat request as free experimentation.

For a first workflow, use a small issue with a clear acceptance check. Confirm the paid Copilot seat and the organization's “Copilot in the cloud” policy.^[6] Choose Cloud if the task needs cross-device continuity and the sandbox has the required dependencies and network access. Choose Actions for its specific setup or runner requirements. Confirm the billable repository owner and set a sandbox product or SKU budget, with “Stop usage when budget limit is reached” if a hard cap is required. Then inspect the session log, diff and test result before accepting a pull request.^[3][4][7]

Permissions still matter. GitHub says its “Copilot in the cloud” policy controls cloud access; existing repository exclusions and enterprise-managed agent permissions or MCP allowlists carry into the updated experience. Approval is requested for tool calls that require it. That is a governance boundary, not proof that every generated change is safe or correct.^[1][7]

GitHub is making agent work easier to resume. The durable advantage will come from routing each task to the right environment, measuring its real cost and reviewing the work that comes back.

Last updated: October 30, 2026