- Book: LLM Observability Pocket Guide
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
You hand an agent such as GitHub Copilot, Claude Code or Codex a refactor, it starts a long turn, and you close the VS Code window to get it out of the way. Until this summer, that killed the work, and on the extension-host path it still does. The agent ran inside the window's extension host, and as the VS Code team put it in their architecture post, that "ties the agent runtime to one VS Code window."
VS Code 1.129, released on July 15, 2026, introduced the fix: the Agent Host, "a dedicated process that runs agent harnesses such as Copilot, Claude, and Codex." Two September releases then let that process run somewhere else. 1.138 put agent sessions inside a local Dev Container, and 1.139 extended that to SSH, Tunnel and WSL hosts.
What you give up when an editor renders an agent's session, instead of running the agent's own command-line interface, is the real story. The opposite design exists too, and I picked it for my own tool.
What the Agent Host owns
The Agent Host docs are short and precise: "The Agent Host is a dedicated process that runs agent harnesses and manages their sessions." A harness is the agent runtime itself. Per the architecture post, the Copilot harness is built on the GitHub Copilot SDK, and the Claude harness loads Anthropic's Claude Agent SDK, with an adapter that maps sessions, tools and permissions into the host's model.
Editor windows don't talk to the agent. They talk to the host, over the Agent Host Protocol (AHP), an open, MIT-licensed spec (repo) that describes itself as "synchronized multi-client state for AI agent sessions." The architecture post calls it "state-first": the host turns harness events into "durable, display-ready state and ordered Redux-like actions." A client that subscribes gets a snapshot of the current state, then an ordered stream of actions. A client that drops and reconnects replays the actions it missed.
This is the one message example on the protocol's home page:
{
"channel": "ahp-chat:/demo",
"action": {
"type": "chat/activityChanged",
"activity": "Waiting for input"
},
"serverSeq": 1
}
The serverSeq is the important field. The host stamps every mutation with a monotonic sequence number and broadcasts it to every subscribed client, so two windows rendering the same session converge on the same state. The same page shows actions such as chat/turnStarted, chat/toolCallStart and chat/turnComplete.
Transport depends on where the host runs. Per the docs, "VS Code uses a message port for local IPC and AHP JSON-RPC over WebSocket for remote connections." The host can be a local utility process or a standalone server on another machine, started with code agent host (the docs name a --tunnel option too).
What it buys you
The session outlives the window. The docs say it plainly: "An active turn can continue after its project window closes while the Agent Host remains running." Compare the extension-host path on the same page: there the window owns the session, so "closing the window stops ongoing work."
Several windows, one session. The 1.129 notes say "the same session can be connected to and rendered from multiple VS Code windows at once," and the host is rolling out to both the editor window and the Agents window. Agents on the host also got tools to list, read and create sessions, and to message sessions they created, which always asks for your confirmation.
The project's own toolchain. With chat.agentHost.devContainer.enabled on, folders with a supported Dev Container configuration get a Use Dev Container action in the Agents window, and the session runs in that container (1.138). Docker has to be installed. In 1.139 the same action works for projects on SSH, Tunnel and WSL hosts, as long as the remote folder has a Dev Container config and the remote host has Docker. Both releases say the feature is rolling out gradually, so the setting may be off for you, and the docs label Dev Container support "experimental."
Faster bookkeeping. 1.139 moved session metadata into a central catalog. With about 645 sessions, the first listing after launch went from 1.3 s to 0.1 s, per the release notes.
Policy enforcement. In 1.142 (October 14), when an organization sets managed permissions or turns on sandbox.enabled, VS Code "requires the Copilot harness in Agent Host for full chat sessions" so it can enforce them. The same release starts rolling out the Copilot harness as the default for new sessions, and points Windows users who want sandboxed commands to an Agent Host session.
If you want to try it, these are the settings the release notes name:
// settings.json
{
"chat.agentHost.enabled": true,
"chat.agents.claude.preferAgentHost": true,
"chat.agentHost.codexAgent.enabled": true,
"chat.agentHost.devContainer.enabled": true
}
What it costs
The price is that the thing you look at is the adapter's picture of the agent, and some parts of the agent don't fit that picture.
The agent's own interface is the first thing to go. Claude on the host runs through the Claude Agent SDK, which still runs the Claude Code engine underneath. Anthropic's SDK command docs draw the boundary: you can dispatch commands "that work without an interactive terminal," and commands such as /theme and /terminal-setup don't appear in the session's command list. Send one anyway and the SDK answers that it "isn't available in this environment." That SDK is also an extra download. Per 1.138, the Claude and Codex agents "rely on an SDK that is not shipped with VS Code," fetched the first time you need it.
Some of VS Code's own features don't carry over either. The third-party agents docs list Canvases as unsupported for both Claude and Codex. The Codex harness on the host is marked experimental, and using it through a Copilot subscription requires Copilot Pro+ (signing in with a ChatGPT subscription is the alternative). While the 1.142 enterprise policies apply, "Claude, Codex, and terminal chat are unavailable."
Then there is the lifecycle. The architecture post says: "For local sessions, VS Code must remain running because it manages the local Agent Host." For remote sessions, the docs tell you to keep the remote machine and the process serving the session running, and they note that reconnecting doesn't mean work continued while the host was down. The architecture post also calls the implementation and specification "under active development," and it scopes AHP carefully: it standardizes the client-facing session model, not how an agent reasons, manages context or calls tools.
The other design: the vendor's CLI in a real terminal
I build Hermes IDE, so weigh this section with that in mind. It took the opposite default, and wrote down why in ADR 003, dated 2026-09-27.
The ADR's argument: each vendor's terminal interface keeps adding features, so a rendered view falls behind and has to be rebuilt for every vendor. So every new Hermes session runs the agent's own CLI in a real terminal, Claude Code included. Hermes observes what agents report on purpose (hook payloads, OSC 9/99/777 and BEL notifications, exit codes) plus git, reads the terminal stream only for rendering and for status guesses it labels as guesses, and never answers a permission prompt for you. A structured view is allowed only where the vendor offers a stable, documented machine protocol, and only as a per-session opt-in.
Codex on orders-types and Claude Code on orders-api, each in its own terminal and hermes/ worktree, with status, context use, cost and branch in the sidebar.
The piece that maps onto the Agent Host is session survival. Per the README, the Rust backend owns a background session host, and on macOS and Linux "agents keep working while Hermes quits, updates or crashes, and you reattach where they left off." Same goal as VS Code's host, different unit: the thing that survives is the vendor's CLI process and its terminal, not a protocol session.
There is a funny overlap, too. Hermes's optional "Agent view for Claude" runs the same Claude Agent SDK, in a small per-session bridge. Both tools use that SDK for a rendered Claude view. The difference is which one you get by default.
The terminal-first design has its own costs:
- The README promises background sessions on macOS and Linux only. On Windows it makes no such promise.
- A terminal is a byte stream, so some statuses are inferred. Hermes says when a status is a guess, but a flagged guess is still not a
serverSeq-stamped event. - The README lists SSH and tmux sessions. It does not describe running a session inside a Dev Container. If you want the agent inside your project's container, VS Code has that today.
- Each vendor's CLI keeps its own quirks, and you live with every one of them.
Which one fits your work
Pick the Agent Host if you live in VS Code, use Copilot, want one session visible from several windows, or need the agent inside a Dev Container on a remote box. Its protocol gives you something a terminal can't: every turn and tool call as an ordered, typed event.
Pick the vendor's own CLI, in Hermes or a plain terminal, if you depend on the vendor's newest commands the day they ship, or you run several vendors side by side and want each one to behave the way its docs say. Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux. You can download it or read the code on GitHub. It isn't affiliated with Nous Research, Anthropic, OpenAI, Microsoft or any agent vendor.
I haven't benchmarked the two against each other. The question worth asking is whether the interface you rely on belongs to the editor or to the vendor.
If this was useful
The part of this story I find most interesting is observability. An AHP session hands you every turn and tool call as an ordered event, while a terminal agent tells you only what its hooks and notifications choose to report. Knowing what an LLM system actually did, and which signal you can trust, is what the LLM Observability Pocket Guide is about, from traces and evals to token cost.
Top comments (0)