GitHub announced a connected Copilot cloud experience on October 28, 2026. Paid Copilot users can start one cloud task from GitHub.com, GitHub Mobile, the Copilot CLI, the Copilot app, VS Code, Slack, or Teams, then continue the same session elsewhere. GitHub says these sessions run in secure cloud sandboxes by default, can be resumed from snapshots, and draw from a shared Actions compute entitlement.
For QA teams, this is not just another chat surface. It changes the test boundary: context, permissions, artifacts, session state, and usage controls must remain reliable as an agent moves between clients.
What GitHub changed
- One session across surfaces: begin a task in one Copilot client and continue it in another.
- Cloud sandbox by default: GitHub-managed, isolated environments start quickly and save a snapshot when they shut down.
- Shared compute pool: Actions compute entitlement can cover standard hosted runners, cloud sandboxes, and eligible larger runners.
- Central controls: cloud access is governed by Copilot settings, enterprise permission policies, MCP allowlists, SSO, and repository access.
GitHub Copilot cloud sessions QA checklist
Run these checks against a non-production repository with a disposable test issue and a known branch. Capture the session ID, actor, time, model, repository, environment type, tool calls, and resulting commit or pull request for every run.
1. Verify continuity without context drift
- Start a task in one client with explicit acceptance criteria and a deliberately unique test token.
- Resume it from a second client and confirm the task, repository, branch, attached files, pins, and prior decisions are correct.
- Ask the agent to restate its constraints before it changes code. The unique token should be present only where expected.
- End the session, reopen it from a snapshot, and verify whether uncommitted files, terminal state, and task history behave as documented.
2. Test isolation and access boundaries
Try the same flow with read-only access, no repository access, an SSO-protected organization, and a repository excluded from Copilot cloud. Confirm that the agent cannot read or alter out-of-scope repositories, secrets, or connected-tool data. Test MCP and connector allowlists separately: a successful handoff must not silently broaden a session’s available tools.
3. Exercise approval and destructive-action paths
Give the agent a task that requires a tool approval, then hand it off to another surface before approving. Validate that the approval is explicit, attributable, not replayed unexpectedly, and visible in the audit trail. Repeat with a blocked shell command and an attempted write outside the allowed repository.
4. Establish compute and failure baselines
Measure a short test run, a resumed run, a cancelled run, and a retry. Check how each affects the shared Actions entitlement, budget alerts, and reporting. Include network loss on a mobile handoff, expired authentication, sandbox startup failure, and a task that exceeds the expected duration. The expected result should distinguish a safe pause from a duplicate action or an invisible cost increase.
Why this matters for QA engineers
Agent quality is no longer only about whether a generated pull request passes tests. With sessions that move between devices and resume later, QA must validate state integrity: the right context follows the task, protected context does not, approvals remain trustworthy, and metering remains explainable. Treat the rollout like a workflow-platform change and build a small regression suite before enabling it broadly.
A practical rollout gate
Start with one repository and one low-risk defect-triage workflow. Define pass criteria for cross-client continuation, policy enforcement, snapshot recovery, auditability, and cost visibility. Only then expand to shared connectors or write-enabled tasks. This keeps the promise of continuous agent work from becoming a blind spot between clients.