VS Code Agent Host and Agent Plugins 1.0 Explained: Claude, MCP, and Portable Agents
VS Code 1.135 changes the editor’s role in agentic development. VS Code is no longer only a place where one Copilot extension runs inside one editor window. It can now act as a client for persistent agent sessions, discover supported sessions started in other applications, and run different agent harnesses through a dedicated Agent Host.
At the same time, Agent Plugins 1.0 gives compatible clients a shared package format for skills and MCP server configuration. These are related developments, but they solve different problems:
- Agent Host and the Agent Host Protocol (AHP) standardize how clients connect to and control agent sessions.
- Agent Plugins 1.0 standardizes how reusable skills and MCP integrations are packaged.
- MCP standardizes how an agent connects to external tools and data.
None of this means every agent, session, plugin capability, or client is interchangeable. The useful change is narrower: VS Code now has an architecture for hosting several agent harnesses without flattening their provider-specific behavior.
What changed in VS Code 1.135
VS Code 1.135 is a stable release. Its headline agent change is the ability to show recent external sessions created by supported Copilot or Claude applications and continue them in VS Code.
The release also surfaces the Agent Host architecture more directly. The host runs supported harnesses in a dedicated process rather than tying the agent runtime to one editor window. That provides the foundation for sessions that can remain active while clients connect, disconnect, or move between windows.
The distinction between release status and architecture maturity matters. VS Code 1.135 is stable, but Microsoft’s Agent Host architecture documentation says Agent Host and AHP remain under active development. Individual settings and capabilities can still be experimental even when the surrounding release is stable.
What the Agent Host actually is
The Agent Host is a process that owns agent sessions independently of the VS Code window displaying them. VS Code becomes a viewer and controller; the host remains the source of truth for session state.
That process boundary enables four practical changes:
- Persistence across windows. A supported Agent Host session is not tied to the lifetime of one editor window.
- Multiple clients. More than one VS Code surface can observe the same session and stay synchronized.
- Remote execution. The host can run next to the workspace on another machine while a client connects through SSH or a development tunnel.
- Multiple harnesses. Adapters can map Copilot, Claude, Codex, or other supported runtimes into a common session model without replacing their internal agent loops.
This is a separation of control plane and runtime. The editor presents the session; the harness still decides how the agent reasons, manages context, requests permission, and calls tools.
Agent Host is not a universal agent runtime
The host does not make Copilot and Claude identical. According to the official architecture description:
- Copilot uses the GitHub Copilot SDK.
- Claude uses Anthropic’s Claude Agent SDK.
- Each adapter translates provider-specific events into AHP’s shared session representation.
Claude can retain slash commands, hooks, subagents, and its permission model. Copilot can retain its own SDK behavior and Copilot-specific capabilities. AHP standardizes the client-facing session, not the agent’s reasoning loop.
What the Agent Host Protocol does
The Agent Host Protocol is the interface between an Agent Host and its clients. It uses JSON-RPC and synchronized state channels for resources such as sessions, chats, terminals, and changesets.
The host sends a client an initial state snapshot followed by ordered actions. If the client disconnects and later reconnects, it can receive missed actions or a fresh snapshot. This is what allows a session view to move between windows without treating each window as a separate agent runtime.
AHP is described as open and agent-agnostic, but that is not the same as universal adoption. VS Code ships an implementation, and other applications can implement a compatible host or client. Developers should not assume that an arbitrary coding agent or IDE already speaks AHP.
How external session discovery works
VS Code 1.135 can discover supported local sessions created by Copilot CLI, the GitHub Copilot app, Claude Code, and Codex. The 1.135 release notes specifically highlight recent Copilot and Claude sessions in the Sessions list.
A discovered session initially remains external. Opening it lets you inspect its conversation. When you send a new message from VS Code, the Agent Host adopts the session and it becomes a VS Code-managed session.
There are important boundaries:
- Discovery applies only to supported applications and session formats.
- Copilot discovery is limited to repository-associated sessions within the documented recency window.
- A session’s available tools can change when it moves to another surface.
- Provider credentials, billing, permissions, and harness-specific capabilities still apply.
This is session continuation, not proof that every conversation can move between every agent client without loss.
Copilot sessions versus Claude sessions
Copilot and Claude both run as supported harnesses on the Agent Host, but their runtime and authentication paths differ.
Copilot
The Copilot harness uses the GitHub Copilot SDK and is tied to Copilot access and accounting. Its behavior aligns more closely with Copilot CLI and the standalone Copilot app than the older editor-only extension model.
Claude
The Claude harness uses Anthropic’s Claude Agent SDK. VS Code documents two authentication paths:
- a GitHub Copilot subscription with Copilot-routed models;
- Anthropic credentials through an API key or Claude Code OAuth token, billed by Anthropic.
The ability to open the Agents window without GitHub sign-in when Claude has Anthropic credentials is still marked experimental. The same applies to several Agent Host preference settings. Anthropic authentication support should therefore not be read as a guarantee that every signed-out or cross-client workflow is production-stable.
For a broader tool-level comparison, see Claude Code vs Cursor and the GitHub Copilot App guide.
What Agent Plugins 1.0 packages
Agent Plugins 1.0 is an open package format published with maintainers including AWS, Anysphere, Microsoft, OpenAI, Vercel, and later Google. Its portable component types are:
- Skills: instructions, scripts, and resources that an agent can load when relevant.
- MCP server configuration: definitions that connect an agent to external tools and services.
A conforming package uses a root plugin.json, a skills/ directory, and an mcp.json file where required. Compatible clients can discover the component types they implement from the same package.
The phrase compatible clients is essential. Agent Plugins 1.0 does not promise that every client understands every file in a plugin.
What stays client-specific
Custom agents, slash commands, rules, and hooks are not portable Agent Plugins 1.0 component types. VS Code and Copilot clients can place these under the com.github.copilot namespace. Other clients are expected to ignore namespaces they do not implement.
Existing Copilot and Claude plugin formats also remain supported. Agent Plugins 1.0 does not replace VS Code extensions, and it does not require every existing plugin to migrate.
Skills and MCP solve different layers
A skill teaches an agent how to approach a task. It can include a workflow, reference material, or scripts. MCP gives the agent a protocol for reaching tools and data.
For example, a deployment plugin might combine:
- a skill that explains the team’s release and rollback procedure;
- an MCP server that reads deployment status and triggers approved operations.
Packaging both together is useful because the instructions and the tool integration can travel as one unit. But the security boundaries remain separate. Installing a skill does not automatically make an MCP server safe, and configuring an MCP server does not guarantee that every client handles authentication or approvals identically.
Read the MCP complete developer guide for the protocol architecture, and the MCP security checklist before enabling third-party servers.
Why this changes VS Code’s position
VS Code used to be easy to describe as an editor with Copilot attached. That description is now incomplete.
The new architecture gives VS Code three roles:
- Editor client: code, diffs, terminals, review, and extension-provided tools.
- Agent control surface: session discovery, orchestration, handoff, and remote connection.
- Plugin consumer: portable skills and MCP configuration plus Copilot-specific extensions.
This makes VS Code a broader agent host surface, but not a fully vendor-neutral platform. Copilot remains deeply integrated, provider authentication differs, and client-specific plugin namespaces deliberately preserve product-specific features.
What remains experimental or incomplete
Developers should separate stable release capabilities from experimental switches and architectural work in progress.
As of VS Code 1.135:
- Agent Host and AHP are still under active development.
- The Rubber Duck second-opinion feature is experimental.
- Opening the Agents window without GitHub sign-in is experimental.
- Several Claude/Codex Agent Host preference settings remain experimental.
- Extension-provided client tools are available only while the contributing VS Code client is connected.
- Some MCP servers that require interactive input are not forwarded to the Agent Host.
- Multi-chat support and other session capabilities vary by harness.
These limitations are architecture constraints, not footnotes. A workflow that depends on a VS Code extension tool may behave differently after the editor disconnects, even though the underlying Agent Host session continues.
What developers should care about
The most durable takeaway is not that VS Code “supports more agents.” It is that agent state, agent packaging, and tool integration are becoming separate layers:
- Choose a harness for provider-specific behavior.
- Use the Agent Host to keep and control supported sessions independently of a window.
- Use AHP when building compatible host/client infrastructure.
- Use Agent Plugins 1.0 to package portable skills and MCP configuration.
- Use MCP for external tools and data, with explicit authentication and approval controls.
That separation can reduce duplicated configuration and make agent workflows easier to move between supported surfaces. It does not eliminate compatibility testing. Before standardizing on a plugin or session workflow, verify which components the target client supports, how credentials are handled, which tools remain available without a connected editor, and which features are still experimental.