VS Code’s Agent Host Protocol Turns Agent Sessions Into Infrastructure

Rohit Ramachandran

Jul 17, 2026Updated Jul 17, 2026

• ai
• agents
• microsoft
• vscode
• developer-tools
• open-source
• ai-infrastructure
• software-architecture

VS Code’s Agent Host Protocol Turns Agent Sessions Into Infrastructure

Close a VS Code window while a coding agent is halfway through a migration. Open the same session in another window. Check its progress from a browser on your phone. Approve a tool call there, then return to the IDE and see the same ordered history, terminal state, changes, and pending work.

That sounds like interface polish. Underneath it is a distributed-systems problem.

Microsoft’s answer is the Agent Host Protocol, or AHP: a client-facing protocol for turning one live agent session into a shared, synchronized resource. In VS Code 1.129, released July 15, 2026, Microsoft began rolling out a dedicated agent-host process for Copilot, Claude, and Codex. The same session can connect to multiple VS Code windows because the session no longer belongs to any one window.

The host owns it.

That architectural move is more important than the acronym. Long-running agents cannot become dependable infrastructure while their truth is trapped inside one chat panel. Their turns, approvals, tool calls, terminals, changesets, errors, and reconnect behavior need an authority outside the view that happens to render them.

AHP is Microsoft’s attempt to standardize that authority.

It does not replace the Model Context Protocol (MCP), which connects AI applications to tools and data. It does not replace the Agent Client Protocol (ACP), which connects one client to one coding agent. AHP sits above those layers and coordinates many clients around shared session state.

That is the useful way to read this release: MCP made capabilities portable; ACP made agents portable; AHP is trying to make the live session portable.

The release has two layers: a VS Code product and an open draft

The launch becomes easier to evaluate when the product and protocol are separated.

The product layer is the VS Code 1.129 agent host. It runs agent harnesses in a dedicated process rather than tying every session to a particular editor window. Microsoft names Copilot, Claude, and Codex as supported harnesses in the rollout. Users opt in with chat.agentHost.enabled, an organization-manageable setting, then select a harness.

The protocol layer is the open Agent Host Protocol specification, its MIT-licensed GitHub repository, generated schemas, and official client libraries.

As of July 17, the latest versioned specification release is 0.5.2. Microsoft labels the spec DRAFT and says breaking changes are expected. The repository’s main branch can move beyond a tagged release, and each language client has its own release track.

That means AHP is real enough to power product work, but not stable enough to treat as a forever contract.

The version warning is not boilerplate. A company can prototype against AHP now, but a production commitment should include version pinning, capability checks, contract tests, and a budget for migration. The official versioning rules negotiate a shared SemVer version during initialization, with capabilities used to introduce new behavior before it becomes baseline.

Why the session needs its own protocol

A chat panel can get away with local state when an interaction lasts 30 seconds and one person watches it from one screen.

An agent session cannot.

A serious coding session may last for hours. It can create terminals, stream reasoning and output, request approval, edit dozens of files, pause for input, recover from a failed command, and continue after the user disconnects. More than one human or client may need to observe or steer it. A mobile UI should not need to embed the whole agent runtime. A review surface should not need to know Claude’s private event vocabulary. A CLI should not invent a different definition of “waiting for input” than the IDE.

AHP puts an authoritative host between those clients and agent backends.

The host owns a set of URI-addressed channels. Clients subscribe to the ones they need, receive a snapshot, and then reduce ordered actions into local state. The root catalogue, sessions, chats, terminals, changesets, resource watches, and telemetry each have a protocol home.

The core move is simple:

window-owned conversation
        ↓
host-owned session resource
        ↓
many synchronized views

Once the session has an identity and a state contract, the interface becomes replaceable. One view can emphasize live conversation. Another can show only approvals. Another can monitor ten hosts. Another can render a phone-sized status and change-review surface.

This is the same kind of separation that made language servers useful. Editors did not need to contain every language implementation. They spoke LSP to a language server. AHP is attempting a related split between agent experiences and the process that owns live agent state.

But there is a crucial difference: agent state is active authority, not passive syntax information. It can represent a pending command, a credential challenge, a terminal, a file operation, or an approval that changes what runs next.

That makes the host a security and governance boundary, not merely a rendering backend.

MCP vs ACP vs AHP: stop making one protocol do three jobs

The agent ecosystem now has enough protocols that casual explanations blur them together. The distinctions are operational.

The official AHP and ACP guide is explicit: AHP is a coordination layer; ACP is a communication layer. An AHP host can speak AHP upward to several clients and ACP downward to an agent. It translates agent-specific streaming events into agent-agnostic state actions.

MCP sits on a different axis. The MCP documentation defines a standard for connecting AI applications to external systems. Its familiar primitives are tools, resources, and prompts. AHP intentionally does not redefine those primitives. It can surface MCP-server lifecycle and authentication state, and its MCP integration guide defines an optional constrained mcp:// side-channel for client-facing MCP Apps, but the upstream MCP specification remains authoritative.

AHP standardizes the coordination plane. It can compose with ACP and MCP without replacing either one.

The stack matters because “supports agents” is not a single interoperability claim.

A product may support MCP and still trap every session inside one application. It may support ACP and still have no answer when two clients approve the same request. It may support AHP and still use a proprietary adapter below the host. Buyers should ask which boundary is portable.

Inside AHP: state first, events second

Many agent integrations expose a stream of backend events and leave every client to reconstruct meaning.

AHP makes a stronger choice. Durable, user-visible truth belongs in state. The protocol describes immutable state trees, typed actions, pure reducers, snapshots, subscriptions, and replay. A client should be able to render the core session without understanding the backend’s internal tool names or reasoning loop.

The channel model gives that state an address.

This is a selected builder view, not a complete list of every current or proposed channel. The draft also covers resource watches, telemetry, comments, and an optional MCP side-channel.

Large content can be stored by reference instead of inflating every state snapshot. Lazy subscriptions let a client load the session list first, then subscribe only to the chats, terminals, or changesets it is rendering. A mobile overview does not need the same payload as a full IDE.

That creates a useful product boundary: the protocol state should describe what the user needs to see and do, not mirror every private event inside the agent harness.

The tradeoff is translation. The host must map Copilot, Claude, Codex, or ACP events into common actions. If the normalized model is too narrow, important provider behavior leaks into opaque _meta fields. If it becomes too broad, every client inherits complexity it does not need.

The quality of that mapping will determine whether AHP produces real interoperability or merely a common outer shell.

The clever part is optimistic reconciliation

Shared state is easy when everyone only watches. It becomes hard when several clients can act.

Imagine an approval appears in two VS Code windows and a browser. One client accepts while another rejects. Or one client begins a turn while a second sends a queued message. The interface must feel immediate, but all clients must eventually agree on what actually happened.

AHP’s answer is write-ahead reconciliation.

Each client keeps confirmed state, pending local actions, and a computed optimistic state. When the user acts, the client applies the action locally before the server round trip. The host then accepts or rejects it, assigns a monotonic serverSeq, and echoes the authoritative action—plus its origin—to subscribers.

The originating client removes the matching pending action. Other clients apply it as foreign state. If the host rejects an action, the optimistic effect is reverted.

The UI stays responsive, while the host remains the authority for conflicts, ordering, and recovery.

The official reconciliation guide notes that many chat actions are append-only, which makes rebasing straightforward. True conflicts use server-wins semantics.

Reconnection uses the same sequence model. A client sends its last seen server sequence and subscriptions. If the gap is still in the replay buffer, the host returns missed actions. If not, it returns fresh snapshots. Protocol notifications are not replayed, so clients re-fetch the relevant catalogue state.

This is where AHP stops looking like “an agent API” and starts looking like session infrastructure.

What AHP makes possible beyond one editor

Microsoft’s first-party use is already concrete. VS Code’s remote agent sessions documentation says the Agents window uses AHP over SSH or a dev tunnel to reach a remote machine. The browser client at insiders.vscode.dev/agents can chat, review changes, and manage sessions while work continues on the remote host.

That is one product. The protocol suggests a broader ecosystem.

One particularly interesting product is an attention router. A client could show only sessions in InputNeeded, sessions with errors, and completed changesets awaiting review. That turns several background agents into a human work queue.

Another is a compliance viewer that cannot initiate turns or execute terminal input but can observe approvals, tool-call state, and changes. AHP’s shared state model makes that conceivable, although access control and role semantics still depend heavily on the host and transport deployment.

A third is a handoff experience: begin a session in an IDE, inspect it from a tablet, and let an automated process archive or annotate the result. The protocol does not make all those clients trustworthy. It gives them a common state boundary on which trust can be built.

This extends the control-plane argument RohitAI made in the Codex Remote guide. Remote steering becomes much more durable when it is based on a host-owned session contract instead of one product’s private chat state.

The security boundary moved with the session

The dedicated host improves process separation and continuity. It also becomes a privileged target.

An AHP endpoint can expose session metadata, working directories, tool requests, terminal state, file changes, protected-resource challenges, and commands that steer an agent. Treating it like an ordinary chat endpoint would be a category error.

The AHP transport specification is candid about the boundary. AHP does not prescribe a transport beyond requiring reliable, ordered, complete, bidirectional messages. Access control for the AHP endpoint itself is a transport-layer concern outside the wire protocol.

Separately, AHP’s authentication specification defines protocol-level authentication for agents and backing resources. It uses OAuth protected-resource metadata concepts from RFC 9728 and bearer-token delivery semantics from RFC 6750. Clients discover per-agent requirements and push tokens for resources the host has advertised. That solves resource authorization discovery; it does not secure an anonymously exposed WebSocket or dev tunnel.

The protocol’s clientId is an opaque connection identifier used for reconciliation and reconnect. It is not, by itself, a user identity or authorization claim. Bind commands and subscriptions to the principal established by the secured transport, not to a client-provided label.

VS Code’s remote-session guide makes the operational consequence explicit: a dev tunnel should require GitHub or Microsoft authentication. An anonymous tunnel could let anyone who discovers the URL reach the machine and start sessions, which becomes especially dangerous with auto-approval enabled.

The protocol also does not define a mandatory persistence backend, retention period, encryption-at-rest scheme, tenant model, or enterprise audit service. A replay buffer is not a compliance archive. A fresh snapshot is not proof of durable history. Those are host responsibilities.

This distinction echoes RohitAI’s analysis of portable OpenAI Skills: the artifact or protocol can move while credentials, permissions, approvals, and audit boundaries remain product-specific.

What builders should test before betting on AHP

A demo with two browser tabs is not an interoperability test.

Use two independently written clients if possible. Include a real agent adapter. Disconnect at inconvenient moments. Race two approvals. Change protocol versions. Try a tool-auth challenge halfway through a turn. Observe what each client renders after replay and after snapshot fallback.

One subtle test deserves special attention: semantic loss at the host adapter.

Suppose Claude exposes a permission state that does not map cleanly to AHP’s common tool-call lifecycle, or Codex attaches review metadata another agent does not produce. The host can place it in _meta, approximate it, or drop it. Compare the native client with the AHP client and document what disappears.

Protocol compatibility without behavioral parity can create false confidence.

The open-source Grok Build harness analysis reaches a related conclusion from another direction: source visibility helps, but the effective binary, configuration, network path, and service policy determine runtime behavior. With AHP, the state schema helps, but the host implementation, adapter, transport, storage, and authorization policy determine the system users actually trust.

Four consequences if AHP catches on

1. Agent sessions become addressable work objects

Today, teams often treat a session as UI history. AHP treats it more like a resource with a URI, state, lifecycle, subscribers, and ordered mutations.

That makes sessions available to workflow software. A ticket can point to a session. A reviewer can subscribe to its changeset. An incident dashboard can surface sessions waiting for human input. An automation can archive completed work.

The danger is turning every agent conversation into an immortal record. Host storage and retention need explicit product decisions; AHP does not make them for you.

2. The scarce interface becomes human attention

When multiple sessions continue without one editor window, the primary UI is no longer chat. It is triage.

Which session needs input? Which tool call is risky? Which changeset is ready? Which agent is stuck? Which terminal command failed?

AHP’s status and shared-state model can support that attention layer. The best client may be the one that shows the least conversation and the clearest interrupt queue.

3. The host becomes the interoperability choke point

Agent-neutral clients are valuable, but neutrality has a cost. Every backend event must be translated into common state. Whoever controls the host controls the mapping, lifecycle, policy, persistence, and visibility of the session.

The ecosystem could trade editor lock-in for host lock-in.

The antidote is not another slogan about openness. It is independent server implementations, conformance fixtures, recorded event traces, portability tests, and clear behavior for unknown extensions.

4. Protocol stacks replace monolithic agent SDKs

One SDK currently tries to do everything: model calls, tools, permissions, UI streaming, session history, remote access, and telemetry.

A cleaner architecture can split those contracts:

AHP  → shared session state and client coordination
ACP  → agent-to-client communication below the host
MCP  → tools, resources, prompts, and capability integration
host → policy, adaptation, storage, identity, and audit

That is more composable, but only if teams resist pretending the layers provide security or durability they do not specify.

My verdict

Agent Host Protocol is the most interesting part of VS Code 1.129 because it addresses a problem model benchmarks ignore.

An agent can be brilliant and still be operationally fragile if its work disappears with a window, cannot survive a disconnect, renders differently across clients, or lets two approvals race without an authority.

AHP gives that authority a shape: URI-addressed channels, immutable state, pure reducers, ordered action envelopes, optimistic clients, replay, snapshots, and version negotiation.

The design is thoughtful. The product integration is real. The draft is also moving quickly and has limited independent server evidence.

So the correct posture is neither “wait until 1.0” nor “standardize the company on it tomorrow.”

Prototype where shared sessions create real value. Build one narrow client. Test against VS Code’s host and, when available, another implementation. Keep provider adapters explicit. Treat transport access like remote command authority. Store audit events outside the replay buffer. Pin versions.

Most importantly, use the right mental model:

The chat window is a view.
The agent is a backend.
The session is the shared work object.
The host is the authority.

If Microsoft can turn that model into a stable, independently implemented protocol, the coding-agent market gets a missing layer of infrastructure.

Frequently asked questions