Since VS Code 1.144 (October 28, 2026), Copilot in VS Code runs by default on the Agent Host, a separate process: closing the window no longer stops the agent, and you can follow it from GitHub Mobile.
It’s the change GitHub announced at Universe. It seems minor, but it changes your daily workflow with agents: you launch a long refactor, close the project, step away from your desk, and follow it from your phone. Here’s what the Agent Host is, what actually survives when you close things, how to reach your session from another device, and what security tradeoffs it brings.
What is the Copilot Agent Host in VS Code?
The Agent Host is a dedicated process, separate from any VS Code window, that runs agent harnesses (Copilot, Claude, and Codex) and owns their sessions. Because the session lives outside the window, the same session can be displayed in multiple windows at once and continues running when the window that started it disappears.
It speaks the Agent Host Protocol (AHP), which is open: VS Code, the Agents window, and any client you build yourself are simply clients of the same live session.
The Copilot harness inside the Agent Host is built on the Copilot SDK, the same runtime used by Copilot CLI and the GitHub Copilot app. GitHub’s stated goal is for the agent to behave identically across all three products. (We explain why the SDK matters strategically in GitHub Copilot No Longer Wants to Be a Copilot.)
Does Copilot in VS Code already use the Agent Host by default?
Yes, for new sessions. The Copilot harness is the default for new sessions in both the editor and the Agents window, and it runs through the Agent Host.
You choose the harness in the Session Target control before your first prompt. The other options are still there:
| Harness | Where it runs | When you close the window |
|---|---|---|
| Copilot | Agent Host (Copilot SDK) | The session keeps running |
| Local | VS Code extension host | The session stops |
| Claude | Claude Agent SDK, integrated into VS Code | — |
| Codex | OpenAI Codex extension, or the experimental integration with Agent Host | — |
The Local harness is the previous behavior: the window owns the session, so closing it stops the work.
Does the session keep running if I close VS Code?
If you close the window, yes. If you quit the application, no, at least for sessions managed by VS Code desktop on your own machine. The documentation is explicit: closing an editor window is not the same as quitting the application, and for local Agent Host sessions you need to keep VS Code open.
Two more rules worth knowing:
- Reconnecting to a session doesn’t mean the work continued while the host was stopped or the machine was off. If the laptop was suspended, so was the agent.
- Disconnecting a client doesn’t stop a running task. To stop the agent, use the session’s stop action.
If you need work that survives closing your laptop, that’s a different product: cloud sessions, which start from the Agents window, run on GitHub infrastructure, and can be continued from VS Code, the Copilot app, GitHub Mobile, github.com, or Copilot CLI.
How do I control Copilot from my phone?
You register your machine as a GitHub Environment, and from that point any client with the same GitHub account, including GitHub Mobile, can see and work with sessions on that machine. At the time of publication, GitHub Environments is in Preview.
According to VS Code documentation:
- On the machine with your workspace, open Remote Connections from the title bar of the Agents window or from the Chat view entry area.
- Select GitHub Environments. That starts sharing. Complete any login or confirmation prompts that appear.
- If you like, rename the environment to recognize it on other devices.
The feature is controlled by the chat.agentHost.githubEnvironments.enabled setting.
The GitHub changelog describes a terminal route for the same thing: open a terminal on the machine, navigate to the project folder, and run:
code agent host --github-environment
To connect from another VS Code (or another desktop client), sign in with the same GitHub account, run Connect to Environment… from the Command Palette, choose the machine, and select the existing session. Use Refresh Environments if it doesn’t appear.
From your phone, according to GitHub, you can review progress, give instructions, or start new tasks on your development machine. At the time of publication, neither GitHub nor the VS Code documentation had published step-by-step instructions for GitHub Mobile, and the documentation clarifies that available actions vary by client.
To stop sharing, open Remote Connections on the host and select Off.
The requirement never changes: the machine and its Agent Host have to keep running.
How do I run the agent on another machine with VS Code Remote SSH or a tunnel?
The Agents window can connect to an Agent Host on the same machine or on a host via SSH, dev tunnel, or WSL. The agent then uses the code, tools, and dependencies from that machine, and keeps running even if you disconnect or close VS Code locally.
Via SSH
Select New (Ctrl+N on Windows/Linux, ⌘N on macOS), choose SSH from the environments dropdown, and enter a connection string like user@hostname. VS Code installs the necessary CLI on the remote machine when needed.
With a vscode tunnel (dev tunnels)
On the remote machine, run code tunnel (or code-insiders tunnel) and authenticate the first time. Then select New, choose Dev Tunnels, the account type, and the tunnel. You can also start a standalone host directly with code agent host --tunnel.
From the browser
With a tunnel running, open https://insiders.vscode.dev/agents, choose Continue with GitHub, and select your host. The browser connects only through dev tunnels or GitHub Environments, not directly via SSH.
The remote machine has to be on and accessible. Connecting to a powered-off machine won’t turn it on.
Is it safe to expose your machine this way?
It’s a trusted owner model, and the documentation is direct about the tradeoffs:
- Session actions are replicated to GitHub, and conversation content does not have end-to-end encryption.
- Any connected client gets owner access to the host’s sessions, tools, and workspace resources.
- An anonymous dev tunnel allows anyone who finds the URL to start agent sessions on your machine. Always require GitHub or Microsoft authentication.
If the machine stores client credentials or code you can’t expose, combine it with local sandbox, which reached general availability on October 7 for Agent Host sessions: GitHub Copilot Local Sandbox.
Copilot CLI or VS Code: what changes with the Agent Host?
The difference is narrowing. The Copilot harness in VS Code uses the same Copilot SDK as Copilot CLI, and a machine registered as a GitHub Environment exposes its sessions to Copilot CLI as well. You can start in the editor and pick up from the terminal, or vice versa.
Installing Copilot CLI also goes through VS Code: on Windows, from the VS Code installer; on macOS, when adding VS Code to PATH; on Linux, by running copilot.
What doesn’t change: the shared SDK doesn’t guarantee identical tools, models, permissions, or customizations across products. Choose by interface, don’t expect total parity.
What doesn’t work the same as with the Local harness?
The Copilot harness doesn’t outright replace every workflow from the Local harness. The documentation lists these limitations:
- Copilot harness sessions don’t have access to all tools built in or provided by extensions.
- Not all sessions or personal settings sync.
- Extension tools only work in chats in the editor window where that extension runs.
Before moving a workflow you depend on, verify that its tools and MCP servers are available in the Copilot harness. If they aren’t, the Local harness is one click away in Session Target.
Can Copilot use your desktop apps (Copilot computer use)?
Experimentally, yes, on macOS and Windows. Enable chat.agentHost.computerUse.enabled in Settings, restart VS Code, and run /computer on in a Copilot session running on your computer (/computer off turns it back off). Each application requires your approval; on macOS you grant system permissions once. The setting is shared with Copilot CLI and the GitHub Copilot app, and organizations can disable it by policy.
Can you build your own client for the Agent Host?
Yes, that’s what the open protocol is for. Agent Host Protocol v1.0 is already published. Run code agent host to start a standalone host on localhost, protected by a connection token, and connect with one of the client libraries for TypeScript, Rust, Go, Kotlin, or Swift. If VS Code already has a host running, code agent endpoints returns its endpoints.
Status as of November 3, 2026: the Agent Host and Copilot harness by default are published in 1.144, without a preview tag. GitHub Environments is in Preview. Computer use, cloud sessions, and Dev Containers on the Agent Host are experimental.
What about you? What task would you leave Copilot running for while you step away from your desk?
- On my machine, with the editor window open
- On a remote server, via SSH or tunnel
- In the cloud, with a cloud agent
- I prefer another option (tell us which)
Comment below or, if this article reached you by email, reply directly to the email: your response will be published here.