What changed
Microsoft is progressively moving VS Code agent sessions into a dedicated Agent Host process. The host runs adapters for coding-agent harnesses such as Copilot, Claude and Codex and communicates with editor clients through the open Agent Host Protocol (AHP), a JSON-RPC protocol with synchronized session state. Unlike the older extension-host model, the Agent Host owns the session independently of any particular VS Code window: multiple clients can observe the same session, remote hosts can run beside the workspace, and active work can continue when no editor client is connected. VS Code 1.130 made the architecture a prominent rollout feature, and 1.132 continued the rollout while removing the `ChatAgentHostEnabled` enterprise policy that previously allowed administrators to centrally disable it.
Why it matters
The architecture changes what an IDE coding agent is. Instead of being a feature whose lifecycle is tied to one editor window, it becomes a long-running workspace service that clients can connect to and leave. That makes persistent and remote agent work more practical and lets multiple harnesses share common session concepts, but it also changes governance and extension assumptions. Agent work can continue after a window closes, edits occur directly in worktrees/session folders, extension-provided tools may exist only while a contributing client is connected, and administrators no longer have the removed central Agent Host policy as a blanket off switch.
The agent session now belongs to the host, not the window
VS Code documents the Agent Host as the source of truth for agent sessions. A client subscribes to session, chat, terminal and changeset state, receiving an initial snapshot followed by ordered actions. Because that state lives in the host, a developer can close one window, reconnect from another and keep the same session; an active turn can continue while no client is connected as long as the host keeps running.
AHP creates a common layer across Copilot, Claude and Codex
First-party adapters translate individual agent runtimes into the Agent Host Protocol’s common session model. AHP uses JSON-RPC and can operate locally or over WebSocket for remote hosts. That gives VS Code one client architecture for several harnesses instead of building separate lifecycle, reconnect and state-synchronization behavior around each agent implementation.
Remote hosting moves execution next to the code
The Agent Host can run as a standalone process beside a remote workspace. VS Code can reach it over SSH or a dev tunnel, while file edits and commands execute on the remote machine. The `code agent host` command can start a standalone host. This is closer to a persistent development worker than a normal chat extension and is relevant for long-running coding jobs that should continue without a laptop window remaining open.
Extension tools and MCP need a different mental model
The Agent Host is designed to be self-contained, but connected clients can contribute tools. Extension-provided tools are generally available only while an editor window running that extension is connected. MCP configuration also differs: the Agent Host reads harness-agnostic `.mcp.json` and user configuration, while VS Code forwards compatible servers configured through the client. Builders of extensions and team workflows should test which capabilities survive disconnects rather than assuming every editor extension follows the remote session automatically.
Enterprise control has shifted during the rollout
VS Code 1.132 removed the `ChatAgentHostEnabled` policy, explicitly stating that administrators can no longer centrally disable the Agent Host through that policy. Individual developers can still use `chat.agentHost.enabled` to choose whether agents run in the separate process. Organizations with AI-control requirements therefore need to review what other Copilot, agent, network and extension policies remain available instead of relying on the retired switch.