You can start a Copilot task in GitHub Mobile, continue it on github.com, and finish it in VS Code or the CLI, keeping the same session. On October 28, 2026, GitHub announced a connected cloud experience and began rolling it out gradually to paid plans: by default, the agent runs in a managed cloud sandbox, and its compute counts against the shared GitHub Actions allowance.

For developers, this changes two practical things at once: where the agent runs and which budget pays for its compute. So it is worth assessing the update as a change to workflows and cost accounting, not just as a new Copilot button.
One task moves between clients
GitHub describes a single session available through its website, mobile app, Copilot CLI, Copilot app, VS Code, Slack, and Microsoft Teams. Users can start a task with a question or repository context, then continue it in another interface. Cloud sessions support Bash, GitHub CLI, code search, connected tools, connectors, and MCP servers.
By default, sessions run in an isolated cloud sandbox on GitHub infrastructure. When stopped, the sandbox saves a snapshot so the task can be resumed later. If a user does not have write access to a repository, Copilot automatically works with it in read-only mode. Access to an organization’s session data is tied to single sign-on and organization settings.
How compute accounting changes
GitHub is replacing the included Actions compute entitlement, previously measured as a fixed number of standard-runner minutes, with a shared monetary pool. It can be used for standard GitHub-hosted runners and Copilot cloud sandboxes; for Team and Enterprise Cloud plans, the pool also covers larger hosted runners. Each compute type retains its own published rate, so the same allowance is consumed at different speeds depending on the resource used.
According to GitHub’s announcement, billing for cloud sandboxes begins in November 2026, and their compute draws on the included Actions allowance. Once that allowance is used up, additional usage is charged at the applicable rates and according to payment settings; account budget limits can stop spending if the relevant setting is enabled. This makes the key question for administrators concrete: how much of the shared allowance will agent sessions require, and how much compute will remain for builds?
What teams should check
- Access and policies. The new cloud environment is available on paid Copilot plans; rollout began on October 28 and is gradual. Check the “Copilot in the cloud” policy, permitted MCP servers, and repository write permissions.
- Work scenarios. Choose a few typical tasks: investigating a bug, changing code, and analyzing multiple repositories. Assess how convenient it is to move a session between clients and whether connected tools provide enough context.
- Compute budget. Record current Actions spending on builds, then track cloud-session spending separately. Keep in mind that products draw from the shared allowance at their own rates and that it resets at the start of the billing cycle.
- Billing timeline. Before sandbox billing begins in November, assign budget owners and configure spend tracking so sandbox launches do not become an unexpected line item in the shared pool.
The update’s main benefit is task continuity across interfaces and running the agent in a cloud environment isolated from the local computer. For a team, the decision to enable it depends on how useful session portability and cloud execution are compared with sharing compute allowance with CI. Test both effects on typical tasks and compare actual spending with current build costs.
GitHub outlined availability, how sessions work, and the shared allowance in its announcement of the new Copilot cloud experience; access on the website and mobile are covered in the GitHub Copilot documentation.