Close the Editor, Keep the Agent: VS Code 1.144 Frees Sessions From the Window

The headline: this is the release where the editor becomes a command post

Visual Studio Code 1.144 shipped as a stable release on 28 October 2026, under the title "Agents Across Every Environment." That title is the whole story in five words: an agent session no longer belongs to one editor window. Until now, closing VS Code meant killing a running agent. Now an Agent Host, a separate process, keeps sessions alive locally, remotely, or in the cloud, so you can return from any client and pick up the same conversation. Once you grasp that, everything else in the release — cloud sessions, cloud automations, an open protocol, model comparisons — falls into place.

Why does this deserve its own piece rather than disappearing into the pile of Universe announcements? Because it changes the default assumption of the work. In the autocomplete era the assumption was "the person sits in the editor, the model helps alongside." In the agent era it is becoming "the person directs, agents work in several places, the person nods at the critical points." Under the first assumption, closing a window costs little. Under the second, closing a window cuts power to the command post. Version 1.144 patches that gap first — it makes "the session stays alive" infrastructure — and only then talks about model choice and permissions. The order matters.

Agent Host: the session stays alive because a separate process holds it

Microsoft's description of Agent Host is short but weighty: a separate process that keeps your agents running on your local machine or remotely, independent of any individual VS Code window. Paired with it is the Agents window, one interface for managing sessions across workspaces and environments, whether you started them or an automation did. When you create a session, the environment picker asks first where it should run: this computer, the cloud, an eligible remote host, or a supported Dev Container. The other options then change with the environment — a local session, for example, lets you specify branch and worktree isolation.

One misreading is worth heading off explicitly: local and remote-hosted sessions still need their machines to stay on. Only cloud sessions keep running after your computer goes off. Microsoft states this plainly in the cloud sessions section: the repository and tools run in a managed environment on GitHub's infrastructure, so your development machine does not need to stay online — but local uncommitted changes are not automatically copied into the cloud's separate workspace. "Runs while my computer is off" and "syncs my local edits automatically" are two different claims; the first is true, the second is not something to assume. The most common first disappointment with cloud sessions comes from exactly that assumption: you changed half a file locally, switch to the cloud, and the change is not there. That is not a bug; it is the design, and you should decide which workspace is the source of truth before you start.

Remote environment management has also been consolidated. A new Remote Environments dialog brings GitHub Environments, Dev Tunnels, WSL distributions, and SSH hosts into one place, where you can see each remote's status, connect or disconnect, and choose which remotes appear in the pickers. Previously those entry points were scattered, and with several agent sessions running it was easy to lose track of which session ran on which machine. Version 1.144 does not add a feature here so much as it gathers the answer to "where does this run?" into one place. That kind of tidying looks unglamorous, but for anyone juggling several sessions a day, it is productivity itself.

Agent Host Protocol 1.0: the open protocol is the longest-lived part

If you judge by one release, cloud sessions steal the show. If you judge by three years, Agent Host Protocol (AHP) 1.0 may matter more. Microsoft describes it as the protocol VS Code uses to communicate with its agents locally and on remote machines, now published in a first version, open and extensible, designed so anyone can build custom interfaces for agents or build agent platforms that plug into any interface speaking it. You can add a WebSocket-based agent host to your VS Code instance with the "Agents: Add Remote Agent Host..." command in the Agents window, and run "code agent endpoints" to list the endpoints of your editor's running agent host. Microsoft also says it publishes libraries in six languages, and has found that agents are good at writing clients and hosts with them.

Why should an open protocol excite anyone? Because it frees the session from a particular vendor's client. The Language Server Protocol did something similar years ago: once editors and language services shared a language, a real tooling ecosystem grew. AHP aims to be the LSP of the agent world: if your interface speaks AHP, it can drive someone else's agent host; if your platform implements a host, someone else's interface can direct it. This is only version 1.0, and whether the ecosystem follows, and in what shape, is unknown. But the direction is right: agents should not be locked inside one window, and a protocol has to come first before an ecosystem can grow. When judging 1.144, do not just count the buttons it added; ask whether it paved the road for the next batch of tools.

One more detail: AHP is not only for local use. Microsoft states explicitly that it covers cloud automations too. That means a scheduled or event-triggered cloud agent speaks the same language as the session you watched in the editor during the day. The benefit of a unified protocol shows up here: review, handover, and audit tooling can be reused across both. If every kind of session spoke its own dialect, the operational cost of automation would explode ahead of its benefits.

Cloud sessions and cloud automations: the computer is off, the work is not

The cloud session flow is described concretely. From the Chat view or the Agents window, select Cloud, choose a GitHub repository, and start a task; then send follow-up instructions, respond to approval requests, and review the agent's changes; later, reopen the same cloud session from the sessions list and continue the conversation. Your cloud sessions are also reachable from other Copilot clients — check progress on GitHub.com, glance at the GitHub Mobile app, then return to VS Code to keep working. That is "across every environment" in its most literal form: the session follows you, not the window.

Two gates must be passed on unchanged. First, the cloud experience requires a paid Copilot plan. Second, it is subject to organisation policies. Free users should not expect everything to unlock on upgrade, and team users should check with administrators first. Cloud Automations, in preview, follow the same logic: the setting is chat.automations.cloud.enabled, enabled by default, created and managed directly in the Agents window, running on GitHub infrastructure on a schedule or in response to repository events, even when your computer is off. Microsoft's examples are practical: automatically triaging issues as they are assigned to you; building shared workflows for your team that act as Copilot; limiting allowed tools and adding filters for precise control, such as triggering only when you are assigned an issue with a specific label.

My judgement is that cloud automations deserve more serious attention from small teams than cloud sessions do. Cloud sessions solve "switching between devices," which for many people is a nice-to-have. Cloud automations solve "who does the routine work in the repository when nobody is watching," which is real saved labour. But the saving depends on writing the trigger and tool scope narrowly: trigger only on assignment with a specific label, allow reading and opening pull requests but not merging, never allow configuration changes. Once an automation is too broad, a questionable pull request merged overnight turns a morning into a rollback exercise rather than a time saving. Narrow first, widen later — always the right order for automation.

Choosing a model: let Fusion take it, or stage a bake-off yourself

Model choice is the release's second thread, and Microsoft offers two routes. The first is Copilot Fusion: instead of picking a model per task, select Fusion in the model picker and let Copilot route and orchestrate. It combines the multi-model orchestration of Project HydraFusion with Copilot's task-aware model selection. For each request, Fusion chooses the models, reasoning effort, and execution pattern: one model for a simple task, one model drafting and others reviewing or critiquing for harder ones. Effort levels are Standard for everyday coding, High for more demanding tasks, and Max for the most complex. You are billed for each model Fusion uses at its standard rate, and through 30 November 2026 paid Copilot plans receive a 30 percent discount on Fusion usage. Fusion is now generally available, although High and Max are offered on Copilot Pro+, Max, Business, and Enterprise plans.

The second route is model comparisons, also called Agent Bake-Off: run the same prompt across multiple models or harnesses and review them side by side. This release enables comparisons by default for eligible new sessions in the Agents window (setting sessions.chat.compareAgents.enabled, unless overridden by user settings or experiments), and extends them to more scenarios: folderless chat without a project can run independent attempts without a Git repository, judge, or synthesiser; a local or empty repository no longer requires a remote or an initial commit, with each isolated attempt starting from a snapshot of non-ignored working files without touching your source branch or index. One exception to note: model comparisons are not supported in Dev Containers.

These routes complement rather than compete. Fusion fits when you already trust the system and want to stop spending thought on model choice; comparisons fit when you do not yet trust it and want to see with your own eyes how models differ on your specific task. A healthy pattern is to bake off a new project or a new task type a few times until you have a feel for it, hand everyday work to Fusion, and re-check Fusion's output against a single model on critical tasks. Handing everything to automatic routing is as lazy as picking a model by hand forever — just lazy in the opposite direction. One note on scope: Fusion's general availability was already covered as a standalone story; this piece treats it as one part of 1.144 — the "stop worrying about model choice" half, after the "session stays alive" half — not as the whole release.

Memory, permissions, and the working set: the more capable the agent, the tighter the reins

A third cluster in 1.144 is about letting the agent know you better while keeping it under control. First, memory: Copilot harness sessions can now use Copilot Memory, the same cloud memory service used by Copilot CLI, the cloud agent, and code review. Agents recall relevant repository facts and your preferences when a session starts, and store new learnings as you work, so you stop repeating the same context in every new conversation. Memories come in two scopes: repository facts, shared with others who have access to the repository, and user preferences, applying across all your repositories. Microsoft's example is blunt: "Across all my repositories, remember that I prefer concise commit message subjects." State the scope before you let it remember — that is step one of using memory well. It is enabled by default and respects your Copilot Memory settings on GitHub and your organisation's policies, and you can review and delete your memories on GitHub at any time.

Second, permissions: assisted permissions are now generally available. The logic is that the agent performs a model-based risk assessment for each tool call and automatically approves low-risk calls, so you are interrupted less; higher-risk or undetermined calls still require your explicit approval. Microsoft adds two limits: assisted permissions require folder isolation and may be restricted by your organisation. Read this as "fewer interruptions for low-risk work," not as "the agent decides what counts as low risk." Genuinely high-risk actions — changing configuration, deleting data, publishing externally — should stay on the human-confirmation list, not be deleted from it just because assisted permissions shipped.

The working set is still experimental, but its direction is right: the Copilot harness records edits made through agent tools in a working set, so you can review and decide which changes to keep or undo, with inline Keep and Undo controls in the editor, or manage files and pending changes from the working set above the chat input. Note the gap: changes made through terminal commands do not appear in the working set, and in the Agents window you use the Changes view to discard files. In other words, the working set covers what the agent itself changed, not every change. When reviewing agent work, check the working set first, then the terminal record — do not reverse that order. Memory saves repetition, permissions save interruptions, and the working set lets you dare to hand work over. Together they are the full picture of "the agent can work, and you can still trust it to."

What else changed, and where this release stops

Beyond the main threads, several smaller changes are worth knowing. Computer Use remains experimental, available only in Copilot harness sessions running on your own macOS or Windows machine; when a task needs it, the agent asks you to allow it, or you run /computer on, and /computer off turns it off. Image generation is in preview: agents can generate images from prompts with GPT Image 2.5 Flare, the default image model, and you can disable it by setting chat.copilot.imageGeneration.model to off, or set the watermark option to true to add a perceptible "Made with AI" watermark; image generation uses AI credits in addition to those used by the conversation model. Canvases, introduced as a preview in 1.142, are easier to find and manage in this release: view them in the Agent Customizations editor, filter by type in Browse, or open them from Add Context in chat.

Copilot connectors, also in preview, bring context into agent sessions through GitHub-managed MCP servers — the Slack discussion behind a change, project context from Notion, API documentation from Microsoft Learn — without local MCP server setup or configuration. Open Browse, choose Copilot Connectors, select Connect on a service, authorise in your browser, and the connection can be reused across supported Copilot clients signed in with the same account. The limits matter: connectors work only with the Copilot harness, Business and Enterprise require an administrator to enable editor preview features, your organisation's MCP restrictions apply, and some services require administrator approval. The new Markdown editor is closer to everyday writing: you can edit the rendered Markdown directly instead of only its source, with source mode still available. The overall look and feel has been refreshed in both light and dark themes.

Finally, state the release's boundaries plainly so nobody upgrades into disappointment. First, not everything is generally available: cloud automations, image generation, and connectors are previews, while computer use and the working set are experimental; the generally available core is the session-continuity framework, Fusion, and assisted permissions. Second, cloud sessions and some advanced features need a paid plan and organisational approval — a free upgrade does not unlock everything. Third, three limits are written in black and white in Microsoft's notes: model comparisons are not supported in Dev Containers, the working set does not cover terminal edits, and cloud sessions do not automatically copy local uncommitted changes. None of these are experience glitches. Version 1.144's value is that it freed the session from the window and gave it an open protocol; it did not solve "how do you govern a flock of agents running in several places." That question still has to be answered by your own trigger conditions, tool scopes, memory scopes, and confirmation lists. The editor has built the command post. The rules of command are still yours to write. As a practical upgrade path: open a cloud session in a non-critical repository first, run the full loop — start it, shut the machine down, glance at it on your phone, return to the editor and continue — and confirm your plan and policies allow it; then create one narrowly triggered cloud automation and watch it for a week, confirming it runs only when you want it to and only does what you allowed. Once both steps are steady, migrate everyday work gradually. Sessions can cross environments in one step, but trust cannot — it has to be earned one run at a time.