VS Code Agent Host Makes Coding Sessions Less Tied To One Window
VS Code 1.134 moves agent sessions toward a dedicated Agent Host process, making long-running coding work easier to share, resume, and run near the workspace.
Visual Studio Code 1.134 puts more shape around how coding agents should live inside a developer tool. The release highlights an Agent Host that runs agent sessions in a dedicated process and speaks the Agent Host Protocol, instead of treating every session as something owned by one editor window.
That is a practical shift. Long-running coding agents need to survive window reloads, remote workspaces, busy extensions, and multi-window review. The Agent Host is VS Code’s answer: keep the agent close to the workspace, keep clients synchronized, and let the editor be a controller rather than the whole runtime.
What Changed
VS Code 1.134 adds visible workflow improvements for agent-heavy work: side-by-side chat groups, a prompt timeline, find in chat, and better layout behavior for session details.
The bigger architecture item is the Agent Host. VS Code describes it as a dedicated process for running AI coding agents. It can run locally as a utility process or remotely as a standalone server, and clients connect through the Agent Host Protocol over local IPC or JSON-RPC over WebSocket.
In plain terms: the session is no longer just a chat pane. The host owns the agent session, while VS Code windows observe, control, and contribute tools.
Why We’re Paying Attention
The old mental model for coding assistants was simple: open a chat, ask a question, get an answer, maybe apply a patch.
Agent workflows are different. A useful agent may run tests, edit several files, wait on tools, continue while the developer changes windows, and produce a diff that needs review later. It may also need to run on the same remote machine as the code and build tools, while the developer’s UI stays on a laptop.
That pushes IDE architecture toward three separate responsibilities:
- Host: own the session, workspace operations, tools, terminals, and ordered state.
- Client: show the state, ask for input, approve actions, and review changes.
- Agent adapter: translate a specific agent runtime into the common session model.
VS Code’s Agent Host is interesting because it treats that split as a first-class product direction, not a hidden implementation detail.
How It Works
The Agent Host Protocol site describes the pattern as one host between many clients and many agents. The host keeps authoritative session state. Each client subscribes to resources such as chats, terminals, sessions, and changesets. Mutations are sent as ordered actions so every attached client can stay in sync.
VS Code’s documentation calls out a few capabilities that matter for real teams:
- multiple clients can observe and control the same session;
- the host can run next to the workspace on a remote machine;
- an agent session can continue when no editor window is connected;
- different agent implementations can plug into one host-facing interface;
- agent work is less likely to be blocked by a busy extension host.
The release notes also say the Agent Host’s Copilot agent is powered by the Copilot SDK, aligning behavior across VS Code, Copilot CLI, the standalone GitHub Copilot app, and related Copilot surfaces.
A Small Useful Test
This post does not need a sample repo. The useful test is to look at your agent workflow and decide which process actually owns the work.
For VS Code users experimenting with the Agent Host, start with this checklist:
Agent session ownership check
1. Can the agent session survive a VS Code window reload?
2. Can another window attach to the same session and see current state?
3. Are file edits applied directly to the worktree, or held as pending editor changes?
4. Which MCP servers and tools are available from the host without a specific editor window?
5. If the workspace is remote, does the agent run near the code and build tools?
6. Where are user-level instructions and MCP config read from?
7. What is the review path before agent-generated changes are committed or merged?
The VS Code docs mention a standalone host command shaped like this:
code agent host
By default, Microsoft says the command starts a localhost server protected by a connection token. A tunnel option can expose it through a dev tunnel. That is powerful, but it should be treated like developer infrastructure: know where it is listening, who can reach it, and what workspace it can modify.
Cost And Operational Notes
The VS Code release itself is free, but the Copilot-backed agent experience depends on the Copilot surfaces and entitlements a team already uses. Remote hosts, cloud agents, and shared agent sessions can also have separate policy and budget controls depending on the product surface.
Operationally, the important details are small but easy to miss:
- Review behavior changes. VS Code says Agent Host sessions apply edits directly to the session folder or worktree. Teams should review diffs and commit intentionally.
- Tool availability changes. Extension-provided tools are only available in chats in an editor window where that extension is running. Host-level tools and client-contributed tools are not the same thing.
- Configuration locations matter. The Agent Host reads harness-agnostic customizations from locations such as
~/.copilot,~/.claude, workspace.mcp.json, and~/.copilot/mcp-config.json. VS Code can forward some VS Code MCP configuration, but interactive-input servers are an edge case. - Remote access deserves the same care as SSH. A remote Agent Host sits near the workspace and can run commands there. Keep it local or tunnel-protected unless there is a clear reason to expose it.
For small teams, the right rollout is boring: enable the new agent workflow for one non-critical repo, document which tools are available, run a session long enough to reload or reconnect, then inspect the resulting diff before trusting it with larger work.
What We’d Watch Next
The useful direction is not just “agents in the editor.” It is portable session state.
If AHP-style hosts mature, a coding session could start from an IDE, continue from a terminal, get reviewed from a web app, and run on the machine where the tests actually pass. That makes agent work more inspectable and less dependent on one chat window staying alive.
The risk is tool sprawl. Once clients can contribute tools and hosts can run remotely, teams need clear inventory: which tools are host-owned, which are client-owned, which need approval, and which can touch secrets or production-like systems.
VS Code 1.134 is worth watching because it moves agent UX toward operations. Sessions need ownership, durable state, review surfaces, and remote boundaries. The Agent Host gives that conversation a concrete place to start.