How to Use GitHub Copilot Session Continuity: The Beginner's Guide

CodexFuse Team · 2026-11-02T20:27:27.526Z · 14 min read min read

GitHub Copilot session continuity keeps one cloud agent session synced across phone, web, VS Code and CLI. A beginner's guide to the one-session model, Agent Host, and the Agent Host Protocol.

Start your coding agent on your phone at standup, steer it from your laptop at your desk, and check on it from a browser at lunch — GitHub Copilot session continuity keeps one cloud agent session alive across every client while the agent keeps working. It is GitHub's October 28, 2026 answer to the old pain: agent work used to die when you closed the laptop or switched machines. This beginner's guide covers the one-session mental model, the start-on-phone → steer-at-desk → check-at-lunch arc, which session type actually follows you across devices, the Agent Host isolation that survives a closed window, the open Agent Host Protocol, and the plan gates and billing meters. If you want the full product tour first, read our GitHub Copilot app guide — this page covers only the cross-client session arc.

What Is GitHub Copilot Session Continuity, Exactly?

GitHub Copilot session continuity is the ability to start one cloud agent session on one client — your phone, VS Code, github.com, the Copilot app, or the Copilot CLI — and pick up the same session, with its work and context intact, on any other client while the agent keeps running on GitHub's infrastructure. It is the centerpiece of "Copilot in the cloud," the new unified experience GitHub launched on October 28, 2026. GitHub's changelog sums it up in one line: start a cloud agent session from your phone at standup, steer it from VS Code at your desk, check on it from github.com at lunch. Say the one-sentence version once, because it is the whole mental model: the session lives in the cloud, not in your editor window.

Is This Just --resume for the Whole Account? The Old Surface, Drawn Once

No — and this is the most common beginner confusion, so it gets drawn once. The Copilot CLI's older --resume and --continue flags recovered a session on the same machine; the older /remote on flow let you steer a CLI session from your phone through a QR code, but your local machine had to stay online the entire time. Session continuity is the new shape: the session runs on GitHub's infrastructure, so for the cloud sandbox part no machine of yours needs to stay awake. Independent walkthroughs of that old QR remote-control flow exist on daily.dev and dev.to, while no hands-on walkthrough of the new cloud session arc appeared on page one when this guide was written on November 3, 2026.

Draw the second confusion line once too: Microsoft Copilot — the consumer chatbot on Windows and in cars — is a different product. Everything here is GitHub Copilot, the developer agent. And keep the sibling lanes straight: the Copilot app guide above owns the product tour, the CLI owns the terminal remote-access surface, and Copilot Projects owns the multi-repo workspace — this page owns only the cross-client session arc.

How Does the One-Session Model Work?

The one-session model has three parts, and beginners who name all three stop fighting the feature within a day. First, the agent's working environment is a sandbox on GitHub's side — a cloud sandbox or a GitHub Actions runner — so closing your laptop does not stop it. Second, every client is a window onto that one running session: VS Code, the Copilot app, GitHub Mobile, github.com, and the CLI all read and write the same session state. That shared state is what makes a copilot session across devices feel like one continuous task instead of five scattered chats. Third, the session's history syncs across surfaces, so you can even ask Copilot about your synced sessions — GitHub's docs note you can only query sessions you started yourself, and syncing must be enabled and permitted by your organization's policies.

Start on Phone, Steer at Desk, Check at Lunch: Your First Session Arc

Run this arc once, end to end, and session continuity stops being a concept and becomes a habit. It is GitHub's own demo sequence — start from your phone, steer from VS Code, check from the web — restated here as a beginner checklist.

1. Start it from your phone at standup. From GitHub Mobile, open a new cloud agent session and describe the task in one paragraph. Sessions started in a Slack or Microsoft Teams DM work the same way: start there, continue anywhere.
2. Steer it from VS Code at your desk. Open VS Code and look at the Agents window — the same live session is there, with the editor and the Agents window in sync and no restart needed. Steer with a follow-up message, approve or dismiss what it proposes, and let it keep working.
3. Check it from github.com at lunch. Open the session on the web or on your phone — the full history, diffs, and the proposed pull request are all there. The agent never stopped while you were away.
4. Close the laptop and mean it. This is the payoff step: with a cloud sandbox session, nothing on your machine holds the work, so shutting the lid does not cancel the agent. Confirm it once in the session history, then trust the model.

One settings detail beginners miss: when you start a cloud session, GitHub offers three environment choices — Cloud (cloud sandbox), GitHub Actions-based, and Remote (a connection to a custom environment). Only the Cloud choice produces the portable kind — the copilot in the cloud sessions that are shared and resumed across clients. Pick Cloud when you want continuity.

Which Clients Keep the Session? Every Surface That Syncs

Session continuity is not one feature in one app — it is the same session showing up in five places. GitHub's October 28 changelog lists them explicitly.

If you are new to Copilot entirely, our GitHub Copilot beginner guide covers the editor basics this guide assumes. Each client is just a lens on the same running agent — which is exactly why the session-type choice below matters so much.

Cloud Sandbox or GitHub Actions: Which Session Actually Follows You?

The answer is the cloud sandbox — and this is the most useful table in the guide, because picking the wrong session type is the number-one reason beginners lose continuity. What follows is GitHub's own documented comparison, reported here as GitHub documents it, not as independently tested fact.

Two practical consequences. First, if you started in a GitHub Actions session and then hunt for it on your phone, you will not find it — it lives on the website only, so choose Cloud at start time. Second, continuity moves a session across clients, not across branches: if branching is new to you, our Git beginner guide covers the mechanics. For the CI-shaped sibling these sessions borrow, see our GitHub Actions guide.

Why Closing VS Code No Longer Kills the Agent: The Agent Host Arc

Before Agent Host, an agent session belonged to a VS Code window — close the window, lose the session. The new Agent Host isolates Copilot sessions from individual VS Code windows, so work continues in the background after you close the project folder or window. That is GitHub's changelog claim, and it is the technical reason the one-session model works at all.

Three more pieces complete the arc. First, the editor and the Agents window stay in sync with the same live session — switching views needs no restart. Second, VS Code Remote SSH and dev tunnels now extend to the Agents window: agents can run on a separate machine while your primary machine does other work, and the agent keeps running when you disconnect locally or quit VS Code. The catch travels with the power: the remote machine and its Agent Host must stay running, or the session stops with them. Third, you can control a dev machine from your phone: open a terminal on that machine, run code agent host --github-environment from your project folder, and GitHub Mobile can reach it — again, the machine and its Agent Host must stay on while you use it from the phone. GitHub also notes its Copilot harness, built on the Microsoft Copilot SDK, is now the default for new sessions in both the editor and the Agents window — a vendor claim about the plumbing, included so you know what runs under the hood.

What Is the Agent Host Protocol?

The copilot agent host protocol — GitHub's name for it is the Agent Host Protocol (AHP) — is the open protocol that lets connected clients stay in sync with a live session and catch up after reconnecting. Concretely: run code agent host on a machine, connect with a client library — GitHub's changelog names TypeScript, Rust, Go, Kotlin, and Swift — and your custom app shares the same live sessions as VS Code. The changelog links the protocol site at microsoft.github.io and calls the protocol "open"; treat "open" as GitHub's claim, because the protocol's full details live outside this guide. The protocol is the reason the app, the editor, the web, and your own future client can all be windows onto one session instead of four different sessions.

What Does It Cost, and Who Gets It? Plan Gates and Billing

Session continuity is not on every plan. GitHub's docs are explicit: the new Copilot in the cloud experience on GitHub.com and GitHub Mobile is available on paid Copilot plans, subject to organization and enterprise policies — users on Copilot Free keep the old Copilot Chat experience. Check your plan before you expect a session to show up on your phone.

Cloud sandbox usage is metered separately from AI credits. GitHub's billing docs name three meters: Compute at $0.000024 per compute second, Memory at $0.000003 per GiB second, and Storage at $0.005 per GiB month. GitHub's own worked example — 600 seconds × 4 GiB — comes to $0.0216 drawn from the account's included compute usage. Memory is metered on what is allocated, not what is actively used; storage is metered only while the sandbox is stopped, keeping a snapshot so you can resume.

Cloud and Actions compute draw on the same monthly GitHub account allowance, separate from AI credits — and cloud sandboxes are explicitly not part of the "Bundled AI credits" budget type, so control sandbox spending with product-level or SKU-level budgets. Two billing-owner rules finish the picture: sessions working in repositories are billed to the repos' owner (all repos in a session need the same owner), and sessions without a repository are billed to the owner you choose, defaulting to your personal account — running copilot --cloud outside a git repo prompts you to pick. Our GitHub beginner guide covers the repos-and-owners basics behind that rule. All of this is GitHub's documented billing; plan amounts move, and no independent tested spend figures exist yet for real cloud sessions.

5 Beginner Mistakes That Break Session Continuity

Sources

1. GitHub Changelog, "GitHub Copilot in VS Code, Universe releases" (published October 28, 2026) — https://github.blog/changelog/2026-10-28-github-copilot-in-vs-code-universe-releases/
2. GitHub Docs, "GitHub Copilot on GitHub.com and GitHub Mobile" (Copilot in the cloud concept, session-type comparison, plan gates) — https://docs.github.com/en/copilot/concepts/copilot-surfaces/copilot-on-github
3. GitHub Docs, "Billing for cloud and local sandboxes for GitHub Copilot" (compute/memory/storage meters, worked example, budget types) — https://docs.github.com/en/billing/concepts/product-billing/cloud-and-local-sandboxes
4. llmrumors.com, analytical explainer on Copilot cloud sandbox vs Actions billing (page-one analytical coverage, explicitly not hands-on) — https://www.llmrumors.com/news/copilot-cloud-sandbox-actions-billing
5. daily.dev, "Control GitHub Copilot Remotely from Your Phone" (independent walkthrough of the older /remote QR remote-control flow — cited for contrast) — https://daily.dev/posts/control-github-copilot-remotely-from-your-phone-ljtekfymy
6. dev.to, "Steer GitHub Copilot CLI Sessions Remotely from Any Device" (independent walkthrough of CLI remote access — the old surface, cited for contrast) — https://dev.to/pwd9000/steer-github-copilot-cli-sessions-remotely-from-any-device-3mee

Frequently Asked Questions

Can I continue Copilot session on phone?

Yes, with a cloud sandbox session on a paid Copilot plan. Start the session from GitHub Mobile or from a Slack or Teams DM, then pick up the same session in VS Code, on github.com, in the Copilot app, or in the CLI. You can also control a dev machine from your phone by running "code agent host --github-environment" from the project folder on that machine — but the machine and its Agent Host must stay running while you use it.

Does closing my laptop stop the Copilot agent?

Not for cloud sandbox sessions: the agent runs on GitHub's infrastructure, so closing your laptop does not stop it. VS Code sessions are additionally isolated by the Agent Host, so closing the project folder or window does not kill the work either. The one exception is remote setups: if the agent runs on a separate machine via Remote SSH or dev tunnels, that machine and its Agent Host must remain running.

Is GitHub Copilot session continuity free?

The new Copilot in the cloud experience is available on paid Copilot plans; users on Copilot Free keep the old Copilot Chat experience. Cloud sandbox usage is metered on compute, memory, and storage, drawn from the account's included compute allowance and separate from AI credits. All pricing here is GitHub's documented billing — amounts move, and no independent tested spend figures exist yet for real cloud sessions.

What is the difference between a cloud sandbox session and a GitHub Actions session?

Cloud sandbox sessions are shared and resumed across clients, retain chat data for the life of the account, and can span repositories in one organization. GitHub Actions sessions are available on the GitHub website only, retain chat data for 28 days, are scoped to a single repository, and stop after a maximum execution time of 59 minutes. Both work one branch at a time with one pull request per task.

Can I build my own app that connects to Copilot sessions?

Yes — that is what the open Agent Host Protocol is for. Run "code agent host" on a machine, then connect with a client library for TypeScript, Rust, Go, Kotlin, or Swift; your app then shares the same live sessions as VS Code and catches up on missed updates after reconnecting. GitHub links the protocol site at microsoft.github.io; "open" is GitHub's own description of it.