VS Code 1.132 Gives Agent Host Sessions an Attention Layer
Rohit Ramachandran
VS Code 1.132 Gives Agent Host Sessions an Attention Layer
VS Code 1.132 does not launch Microsoft's Agent Host Protocol. That happened in stages: VS Code 1.126 announced the AHP adoption, and 1.129 introduced the dedicated Agent Host for Copilot, Claude, and Codex.
The August 5 release is more revealing than another protocol announcement. It shows what happens after an agent session stops belonging to one chat panel.
The new /btw command opens a contextual side conversation without interrupting the running turn. Live pills expose changes, previews, subagents, and browser activity. The integrated browser turns selected page elements into precise, commentable inputs. Multiple windows can already attach to the same host-owned session.
Put those pieces together and VS Code starts behaving less like the room where an agent works and more like the console that decides what deserves human attention next.
That is the useful update to RohitAI's July 17 architecture explainer, VS Code's Agent Host Protocol Turns Agent Sessions Into Infrastructure. The earlier article covered why durable agent work needs an authority outside the window. Version 1.132 begins turning that authority into a product surface.
The caveat matters as much as the thesis. The rollout is gradual. AHP is pre-1.0. The Agents window is still Preview. Protocol features, VS Code surfaces, and Copilot, Claude, and Codex support do not move in lockstep. Microsoft is building an agent control plane, but it has not finished the compatibility, governance, or recovery contract.
Five releases turned architecture into operating behavior
The chronology prevents the wrong headline.
Microsoft first said VS Code was adopting AHP in version 1.126. Version 1.129 introduced the dedicated Agent Host process and multi-window attachment for sessions using Copilot, Claude, and Codex harnesses. RohitAI covered that architectural shift two days later.
Then the implementation kept moving.
- July 20 — AHP 0.6.0: asynchronous tool-risk assessments, turn timing, changeset review capabilities, and OAuth states that can pause and resume an MCP tool call.
- July 22 — VS Code 1.130: wider Agent Host rollout, worktree isolation across named harnesses, and assisted tool permissions.
- July 31 — AHP 0.7.0: side-chat primitives, selected-text provenance, cross-session chat attachments, multiple working directories, and richer terminal completion metadata.
- August 5 — VS Code 1.132:
/btw, cross-chat references, live activity pills, element-level browser comments, and removal of the dedicatedChatAgentHostEnabledpolicy.
That sequence matters because it shows three contracts forming at once:
- a state contract for what a session contains;
- an adapter contract for how different agent harnesses become that state;
- an attention contract for how a human observes and steers the work.
The AHP 0.6.0 notes and 0.7.0 notes are especially useful here. They show that permissions, authentication pauses, side conversations, terminals, attachments, and working directories are becoming first-class session state rather than loose UI events.
The control-plane boundary sits in the middle: clients observe and contribute capabilities; the host sequences state; adapters normalize agent-specific behavior.
The chat panel is turning into an attention router
The easiest feature to underestimate is the row of live status pills.
In VS Code 1.132, Changes opens a live multi-file diff for the current turn. Previews collects rendered Markdown artifacts. Subagents opens delegated work in separate chats. Browsers returns the user to an integrated browser the agent is operating.
None of those concepts is new by itself. Their placement is the signal. They sit above the chat input because a long-running session needs a compact index of active work, not a longer transcript.
The integrated browser moves in the same direction. A user can select multiple page elements, write a separate comment on each, and send that structured feedback to the agent. “The card looks wrong” becomes three anchored observations. That is less ambiguous for the model and easier for a reviewer to verify later.
/btw changes the interaction model again. Microsoft says the side chat shares the primary chat's context and prompt cache while the main turn continues. Selected response text can seed the question, and another chat can be attached by drag-and-drop or a #chat: reference.
This makes prompt-cache locality part of interface design. Instead of starting a cold, detached conversation to ask why the agent chose a migration path, the user can branch a question beside the running work.
But “shares the prompt cache” is not a performance result. Microsoft publishes no cache-hit rate, token reduction, latency improvement, or credit saving for /btw. Teams should measure those outcomes before describing side chats as cheaper.
There is also a cognitive trap: a side chat is a branch beside continuing work, not shared consciousness. The primary turn can move on while the side answer is being composed. Good clients should show which turn, selection, and attachment the branch came from, especially when the main agent is still editing files.
One session now runs on four capability clocks
“Supports AHP” is too coarse to be useful.
The protocol, host, client surface, and harness adapter can all report different capabilities. AHP 0.7 includes multiroot session primitives, while the current Agents window says multi-root sessions are not yet supported. The protocol can represent side chats, but the product documentation limits multiple chats in one session to Copilot and Claude. Codex is named as an Agent Host harness, yet current Agents-window support is narrower than the main editor path.
This is the readiness picture as of August 5:
| Capability | Protocol / host layer | VS Code surface | Builder implication |
|---|---|---|---|
| Shared sessions | Host-authoritative, multi-client state | Multiple VS Code windows can attach during gradual rollout | Test reconnect, conflicts, and stale clients; do not infer scale limits |
| Side and multiple chats | Capability-gated in AHP 0.7 | /btw ships; multi-chat is currently Copilot and Claude only | Negotiate features per harness instead of branching on provider name |
| Multiple roots | Session and chat primitives exist in AHP 0.7 | Not yet supported in the Agents window | Treat protocol support and product availability as separate gates |
| Unattended work | Host can run without an attached client | Only while the Agent Host remains running | Host restart, machine loss, and durable recovery need separate tests |
| Browser and extension tools | A client can contribute tools to a session | Tools depend on the contributing editor client | Attaching or closing a client can change executable authority |
| Independent implementations | Clients published for five language ecosystems | VS Code is the only listed reference server | Demand interoperability traces, not a one-line compatibility claim |
The practical lesson is simple: maintain a capability matrix with at least five columns—VS Code version, AHP version, client version, harness, and execution surface. Pin pre-1.0 versions. Check advertised capabilities. Contract-test unknown actions and metadata.
An “AHP 0.7 compatible” badge cannot tell a user whether Codex appears in the Agents window, whether a side chat is available, whether an extension tool survives disconnection, or how provider-specific tool risk is represented.
A connected viewer can change what the agent is allowed to do
The Agent Host architecture documentation describes the clean separation: the host owns session state, and clients are viewers and controllers that can come and go. Local communication uses a message port; remote AHP connections use JSON-RPC over WebSocket. A standalone host starts on localhost with a connection token, and --tunnel exposes it through a dev tunnel.
That architecture creates independent execution, but only in tiers.
Host-resident capabilities can continue when every editor disconnects, provided the Agent Host process itself stays alive. Client-contributed capabilities are different. Browser tools and extension tools can be advertised by an attached VS Code client and routed back to that client when called.
So a viewer is not always passive. Attaching a richly configured editor can expand the session's tool inventory. Disconnecting it can remove a capability during the same overall job.
This is a non-obvious security boundary. Products should distinguish:
- clients that may only observe;
- clients that may approve or cancel;
- clients that may contribute executable tools;
- clients that may submit prompts or mutate shared inputs.
A second boundary changes review semantics. The Agent Host writes edits directly into the session folder or worktree; the extension-host path can keep edits pending until the user chooses Keep or Undo. A remote reviewer may therefore be inspecting code that already exists on disk, even if it has not been merged.
Worktrees help isolate competing file changes. They are not sandboxes. They do not prevent commands, network access, credential use, or writes outside the worktree. Test rollback for untracked files and non-file effects, not only Git diffs.
Subscribe to session, chat, and changeset state. Keep it observer-first, add explicit approval roles, and advertise no tools unless the user deliberately enables them.
Surface waiting inputs, failed terminals, risky approvals, and ready changesets across hosts. Treat each endpoint like remote developer authority, not a notification feed.
Normalize common session state, but preserve adapter-specific metadata and golden traces for Copilot, Claude, Codex, and ACP-backed agents.
If schema churn or independent-server portability is a hard requirement, keep AHP behind an adapter until the protocol and conformance story mature.
Coordination is not authorization
The official AHP and ACP guide calls AHP a coordination layer. The host sequences actions, broadcasts authoritative state, and reconciles optimistic client changes. If two clients try to resolve one tool confirmation, the host decides which valid action wins.
That is concurrency control. It is not a complete authorization model.
A production host still needs to know which principal may subscribe to a session, read a terminal, attach another chat, approve a tool, cancel a turn, or contribute a browser capability. “Client A won the sequence race” is not the same statement as “Rohit was allowed to approve the deployment.”
The 1.132 governance change sharpens this issue. Microsoft's release notes say the ChatAgentHostEnabled policy is removed, so administrators can no longer centrally disable the Agent Host through that policy. Developers retain the chat.agentHost.enabled setting.
That narrow wording is important. It does not mean every enterprise control disappeared. It does mean teams should re-audit the effective control set instead of assuming the old dedicated kill switch still exists.
For remote hosts, bind every command and subscription to a transport-authenticated principal. Encrypt the path. Scope access per host and session. Log the principal, client, source state, accepted or rejected action, and resulting external effect. The replay buffer is useful for synchronization; it is not a compliance archive.
The adapter becomes the interoperability choke point
AHP is deliberately agent-agnostic. Clients see common session concepts instead of Copilot, Claude, Codex, or ACP-specific event vocabularies. The host adapter performs that translation.
This can reduce editor lock-in. A focused review client does not need four provider SDKs to render a changeset or a pending confirmation.
It can also create host lock-in.
The adapter decides which native semantics survive normalization: tool-risk labels, editable parameters, permission choices, terminal results, citations, reasoning summaries, usage data, cancellation behavior, and provider-specific errors. Two harnesses can produce valid AHP sessions while exposing materially different governance evidence.
That is why the official implementation inventory deserves a careful read. Microsoft lists client packages for Rust, TypeScript, Kotlin/JVM, Swift, and Go, plus AHPX and VS Code client code. It lists one reference server: VS Code Agent Host.
An open specification and several clients are meaningful. They are not yet proof of broad, independent server interoperability.
The right eval is a trace comparison. Run the same risky workflow through each harness and diff the resulting action stream. Ask whether tool ownership, risk, confirmation choices, provenance, exit state, changesets, cancellation, and failure details remain visible.
My expectation is that serious AHP buyers will ask for per-adapter semantic coverage and recorded conformance traces, not a generic compatibility logo.
AHP completes a two-plane agent stack
AHP does not replace MCP, and it does not replace ACP.
ACP handles a point-to-point conversation between one client and one coding agent. AHP coordinates many clients around authoritative session state. MCP connects the runtime to tools, resources, and prompts.
RohitAI's analysis of MCP 2026-07-28 argued that independently routable capability calls do not eliminate the need for durable work state. AHP supplies that other plane:
stateful work plane
sessions · turns · approvals · chats · terminals · changesets · reconciliation
|
v
capability plane
tools · resources · prompts · OAuth-protected services
This is also a useful contrast with Codex Remote Code Mode, which moves execution and extensibility boundaries out of a local terminal. AHP owns a different boundary: the synchronized, user-visible state shared by several clients.
The cloud analogue is AWS Bedrock AgentCore, where a running session becomes a managed infrastructure object with operations, security, and billing consequences. AHP approaches the same “session as resource” idea from an open client/host protocol and a VS Code reference implementation.
The likely stack is not one protocol winning. It is a stateful coordination layer above agent communication and independently routable tools.
The acceptance test I would run before depending on it
The release is ready for serious evaluation. It is not ready for assumption-driven deployment.
Three failure drills deserve special attention.
First, disconnect the only client contributing a browser tool while a turn expects to call it. The job should fail closed and explain what capability vanished.
Second, open a side chat early in a streaming turn, let the primary agent continue editing, and see whether the side surface makes its source point obvious. A correct answer to stale state can still cause a wrong decision.
Third, approve a risky call from one client while another cancels or denies it. The host should produce one authoritative result, and the audit record should explain who was authorized, what won, and whether an external effect occurred.
What happens next
Four product categories look likely.
Attention clients appear before replacement IDEs. A phone-sized approval surface, a changeset inbox, or a ten-host operations view needs only selected AHP channels. It does not need to recreate VS Code.
Compatibility becomes a matrix. Spec version, surface, harness, adapter, and execution location will matter more than a single protocol label.
Enterprise roles become explicit. Observer, reviewer, approver, executor, and tool-contributor are different authorities. Mature hosts will need policy and signed audit around them.
A scheduler emerges above AHP. Multi-client is not multi-agent orchestration. AHP serializes work within a chat and explicitly leaves agent-to-agent communication outside its scope. Parallel agents still need budgets, workspace leases, collision handling, and queue policy.
FAQ
Did VS Code 1.132 launch Agent Host Protocol?
No. VS Code 1.126 announced the adoption of AHP, and 1.129 introduced the dedicated Agent Host rollout. Version 1.132 extends that system with side chats, live activity indicators, browser annotations, and a policy change.
Is AHP stable for production integrations?
Not as a long-lived compatibility promise. Microsoft's AHP guide labels the protocol under active development and warns that wire types, actions, and state shapes can break. Prototype now, but pin versions and keep the integration behind an adapter.
Can an agent keep working after VS Code closes?
An active turn can continue with no client attached while the Agent Host remains running. That does not promise recovery across a host crash, upgrade, machine restart, or power loss. Browser and extension tools contributed by a disconnected client can also become unavailable.
Does Codex have the same Agent Host experience as Copilot and Claude?
No parity guarantee is published. Microsoft names Codex as an Agent Host harness, but the current Agents window supports a narrower set of agent types and limits multiple chats to Copilot and Claude. Verify the exact stable/preview path available to your account and VS Code build.
Does AHP replace MCP or ACP?
No. AHP coordinates many clients around shared session state. ACP handles one client-agent communication path. MCP supplies tools, resources, and prompts. A serious agent platform can use all three.
The editor becomes the console when work outlives the window
VS Code 1.132 is an incremental release with a large architectural consequence.
Side chats, activity pills, browser comments, cross-chat references, and shared windows are individually modest features. Together, they make the host-owned session visible. The unit of work is no longer the conversation inside the current editor. It is a continuing resource with state, subscribers, adapters, capabilities, and decisions.
That is why “agent control plane” is a useful interpretation even though it is not Microsoft's product name.
The control plane is still incomplete. Rollout is gradual. AHP is pre-1.0. Harness parity is uneven. Client tools complicate unattended work. Authorization and audit need stronger contracts. Independent-server interoperability remains early.
But the direction is clear: once agents work longer than a window stays open, the IDE cannot merely host their chat. It has to route attention, preserve authority, and tell a human exactly where intervention still matters.