I had an agent halfway through rewriting a set of Bicep modules on Tuesday night when my laptop decided it was time for an update and a restart. Session gone. Not the files, those were fine, but the conversation, the plan it had built up, the three things it had already checked. I started again on Wednesday morning, slightly grumpy, and then the Universe announcements landed and the very first item was about exactly that problem.
GitHub published a changelog post on 28 October covering everything Copilot-related in VS Code 1.144, which shipped the same day. It’s a long list. Some of it I’ll use daily, some of it I’ll ignore, and a couple of things I’d want to talk to an admin about before anyone on a team switched them on. Here’s my read of it.
Agents that outlive the window#
The big structural change is something called the Agent Host. Until now a Copilot session belonged to the VS Code window it was started in. Close the folder, lose the session. The Agent Host is a separate process that owns the sessions instead, so you can close a project window, open it again later and pick up where the agent got to. The docs are careful to say that closing a folder is not the same as quitting the application: if you quit VS Code on your own machine, the host goes with it. So it wouldn’t have saved me from Tuesday’s forced restart, but it does cover the much more common case of tidying up windows.
Where it gets more interesting is running the host somewhere else. You can start one on a remote machine with code agent host and reach it over Remote SSH or a dev tunnel, and the Agents window in your local VS Code treats it like any other session. Quit VS Code locally and the remote agent carries on. For anyone who already keeps a build box or a jump VM in Azure with the right network access and the right identity, this is a genuinely nice fit: let the agent run its long deploy-and-check loop on the VM, and only watch it from your laptop.
The same session is also visible from the other Copilot clients. Start it in VS Code, check on it from the GitHub Copilot app, github.com, GitHub Mobile or Copilot CLI. The changelog says a session started from a Slack or Teams DM can be continued from those clients too. I haven’t tried that path and I’m slightly wary of what “started in a Teams DM” looks like in practice, but the VS Code to CLI handover is the one I’d actually use.
Driving it from your phone#
The bit that will get the most screenshots on social media is controlling an agent on your own machine from GitHub Mobile. The changelog says you open a terminal in the project folder and run code agent host --github-environment, keep the machine and host running, and the session appears in the mobile app where you can nudge it or start new tasks. I couldn’t find that flag in the VS Code release notes or the Agent Host docs, only in the changelog itself, so treat the exact command as GitHub’s wording rather than something I’ve run. The Agent Host docs do list GitHub Environments as a preview feature with the same “host must stay running” warning.
Comparing models side by side#
The Agents window can now run the same prompt through several models or harnesses in parallel and show the results next to each other. There’s a Judge model that recommends one answer, and a Synthesize option that merges ideas from the attempts into a single result. VS Code calls this an agent bake-off in the release notes and it’s on by default for new sessions in the Agents window, controlled by sessions.chat.compareAgents.enabled. The changelog lists it as preview, and it doesn’t work inside Dev Containers.
I’ve wanted this for a while, mostly for Bicep. The models disagree surprisingly often about things like whether to use a user-defined type or a plain object parameter, and seeing two or three answers at once is quicker than running the prompt three times and keeping notes. Whether I trust the Judge to pick is another matter. I’d use it as a tie-breaker, not an oracle.
Computer use, with the obvious caveat#
Copilot can now click around in your desktop apps. On macOS or Windows you enable chat.agentHost.computerUse.enabled in settings, restart VS Code, and run /computer on in a session that is running on your own machine. Every application needs approving the first time, and the approvals are shared with Copilot CLI and the Copilot app on the same computer. The release notes label it experimental; the GitHub docs page calls it public preview. Either way it’s off by default, which is correct.
I can see the use. Something that can read a dialog in the Azure portal, or drive a GUI tool that has no CLI, saves real time. I can also see a model clicking “Delete” in something it shouldn’t be in. If you’re an admin, the docs say enterprise-managed settings can disable it tenant-wide and that a local enable doesn’t override that policy. I’d want that decision made deliberately rather than by whoever finds the setting first.
Connectors and the customisation marketplace#
Two things that reduce setup friction. Copilot connectors let an agent pull context from services such as Slack, Notion and Microsoft Learn without you installing an MCP server for each. You connect once from the Browse page and the connection follows your account across Copilot clients. It’s preview, it’s on all plans, and it only works with the Copilot harness. The new Customizations page in the Agents window sidebar (or the Chat: Open Customizations command) is a marketplace for skills, MCP servers and plugins, also preview and enabled by default.
On Business and Enterprise plans both of these sit behind the Editor preview features policy, so if you don’t see them that’s likely why. Alongside that, admins get more plugin control: policies to require or block named plugins, restrict installs to approved marketplaces, and lock the toggles in the Plugins view. At repo level a .github/copilot/settings.json file can register marketplaces and enable default plugins, but the changelog is explicit that these are defaults rather than enforcement. Contributors can turn them off unless enterprise policy says otherwise.
Smaller things worth knowing#
The Copilot harness, built on the Microsoft Copilot SDK, is now the default for new sessions in both the editor and the Agents window, which is the thing that makes behaviour consistent between VS Code, Copilot CLI and the Copilot app. If you’ve been following my Copilot CLI posts, the custom agents you write there carry across unchanged.
Copilot CLI can now be installed from the VS Code installer on Windows (a tick box), as part of adding VS Code to your path on macOS, or by running copilot on Linux. That’s from the changelog rather than the release notes, and the screenshot GitHub used was of the Insiders installer, so check the stable one before telling anyone it’s there.
And for the people who like building tools, the Agent Host Protocol is published as an open spec with client libraries for TypeScript, Rust, Go, Kotlin and Swift, so you can write your own front end against the same sessions VS Code uses. I have no plans to, but it explains how the mobile and CLI handover works.
Caveats#
A lot of this is preview or experimental, and the labels aren’t consistent between the changelog, the release notes and the GitHub docs. Computer use is “experimental” in one place and “public preview” in another. Expect settings to move.
The Agent Host only helps if the process stays up. On a laptop that means VS Code stays open; on a remote box it means the VM and the host process stay running, with the cost and the patching that implies.
The Agent Host docs also note that the Claude and Codex harnesses are disabled when Copilot enterprise-managed settings apply, which is worth knowing before you promise a team they can bake off against other models.
Final thoughts#
If you only change one thing after reading this, open the Agents window, start a session there rather than in a chat panel, and close the project folder halfway through on purpose. Seeing the session still there when you reopen it is the moment the Agent Host makes sense, and everything else in this release builds on that. The remote host on an Azure VM is the one I’ll be setting up next week, and I’ll write that up once I’ve found out what breaks.
