VS Code 1.129 agent host: the 6 settings platform teams must decide first
Summary. VS Code 1.129 shipped on 15 July 2026, followed by patch 1.129.1, and it rearchitected how agent sessions run. Agents no longer live inside the extension host. They run in a dedicated process called the agent host, which speaks the Agent Host Protocol (AHP) over JSON-RPC and hosts three first-party harnesses: Copilot, Claude and Codex. The consequence that matters for platform teams is not the multi-window rendering everyone is writing about. It is this line from Microsoft's own architecture doc, dated 15 July 2026: an agent session is not tied to the lifetime of the window for its workspace, and while the agent host is running, an active turn can continue with no client connected at all. An agent can keep editing your repository after the developer closes VS Code. The main lever, chat.agentHost.enabled, is managed at the organisation level, which means somebody on your team owns this decision whether they have made it or not. With GitHub Copilot Business at $19 USD per granted seat per month and Copilot Enterprise at $39, the licence cost is the easy part.
The alignment story is worth noting up front too: the agent host's Copilot agent runs on the Copilot SDK, so its behaviour matches Copilot CLI, which reached general availability on 25 February 2026, and the standalone GitHub Copilot app. Teams that standardised skills and prompts against Copilot CLI between February and July 2026 keep that work.
This is a rollout guide, not a feature summary. Below: what actually changed in the process model, the six settings and who should own each, the safety controls that are genuinely load-bearing, the one silent breaking change in this release, and a staged rollout order.
What actually changed
The Copilot Chat extension traditionally ran agent logic in the extension host, a process designed around extension lifecycles and APIs. Long-running autonomous work has different requirements, so VS Code moved session orchestration into a dedicated process.
| Property | Extension host model | Agent host model |
|---|---|---|
| Where agent logic runs | Inside the extension host | Dedicated agent host process |
| Session lifetime | Tied to the window | Independent of any client |
| Clients per session | One | Multiple, kept in sync |
| Transport | In-process extension APIs | AHP JSON-RPC, message port locally, WebSocket remotely |
| Blocked by a busy extension | Yes | No |
| Agent runtimes | Extension-specific | Copilot, Claude and Codex via adapters |
The agent host can run as a local utility process or as a standalone server on another machine. VS Code uses a message port for local IPC and AHP JSON-RPC over WebSocket for remote connections. First-party agent adapters run inside the agent host process, each translating its runtime into the common AHP session model.
AHP itself is an open, agent-agnostic protocol between a host and its clients. The host is the source of truth. Clients subscribe to URI-addressed channels for sessions, chats, terminals and changesets, receive an initial state snapshot, then ordered actions. If a connection drops, the client reconnects and gets missed actions or a fresh snapshot. The state model is immutable with pure reducers, which is why several windows can render one session without drifting.
The agent host's Copilot agent is powered by the Copilot SDK, so its behaviour aligns with Copilot CLI and the standalone GitHub Copilot app. If you have already standardised prompts and skills against Copilot CLI, that work carries over.
Three consequences that change your threat model
The multi-window demo is the least interesting part of this release. These three are what a platform team needs to reason about.
Sessions outlive the window
Agent sessions are not tied to window lifetime. You can close the window and reopen the session later from another window, and while the agent host remains running, an active turn continues without a connected client.
Read that as an operational fact rather than a feature. A developer who starts a long agentic refactor, closes VS Code and walks away has left a process editing the working tree with nobody watching. Approval prompts that would have gated a destructive action are only meaningful if a client is attached to answer them. Your rollout should establish, before enablement, what your approval defaults are and whether unattended turns are acceptable on repositories that matter.
Extension-contributed tools are scoped to the window
By default, tools from extensions are only available in chats in an editor window where that extension is running. Connected clients can also contribute tools, and the agent host routes a tool call back to the client that contributed it.
This breaks a common assumption. If your organisation ships an internal extension that provides tools for your deployment system, service catalogue or internal APIs, those tools do not follow the session. The same session viewed from a second window, or continuing with no client attached, does not have them. Inventory your internal extension-provided tools before enabling the agent host, and decide which ones need to become MCP servers instead so they attach to the host rather than a window.
The remote host is a network service
For remote sessions the agent host runs as a standalone process exposing AHP over WebSocket, reached through SSH or a dev tunnel. Developers can start one themselves with code agent host, which by default starts a server on localhost protected with a connection token, and --tunnel exposes it through a dev tunnel.
A developer-startable agent server, tunnel-exposable, authenticated by a connection token, running next to source code with file-edit and command-execution capability. That is a legitimate and well-designed feature, and it is also a new egress path that most network policies were not written to anticipate. Decide your position on --tunnel before someone discovers it, not after. Teams already thinking about isolation boundaries for coding agents should read our VM isolation guide for AI coding agents alongside this.
The six settings, and who should own each
| Setting | What it controls | Who should own it |
|---|---|---|
chat.agentHost.enabled |
Master switch for the agent host | Platform team, managed at org level |
chat.agents.claude.preferAgentHost |
Runs the Claude agent on the agent host | Platform team, after harness review |
chat.customizations.promptMigration.enabled |
Surfaces the Migrate Prompts flow | Platform team, during migration window |
sessions.layout.singlePaneDetailPanel |
Experimental docked editor panel in the Agents window | Individual developer |
workbench.experimental.modernUI |
Experimental modernised workbench UI | Individual developer |
workbench.diffEditorAssociations |
Which editor opens for matching diffs | Individual or team, see breaking change below |
Two notes that will save you a support ticket each. chat.agentHost.enabled is explicitly flagged in the release notes as managed at the organisation level, with users told to contact their administrator, so developers cannot self-serve this. And sessions.layout.singlePaneDetailPanel is read once at startup, so it needs a window reload to take effect; expect people to report it as broken before they reload.
The safety controls that are load-bearing
Agents on the agent host gained session-management tools. An agent can list your sessions with their status, workspace and changes, read another session's recent conversation, create a new session or chat to hand off a sub-task, and send a message to a session or chat it created.
That is a meaningful capability increase, and Microsoft shipped three constraints with it that deserve to be understood rather than skimmed:
- Sending a message to another session always asks for your confirmation first.
- An agent cannot message its own chat.
- A burst of sends is capped, so a single request cannot fan out into an unbounded number of sessions.
The third one is the real control. Without a cap, an agent able to create sessions and message them is one prompt-injection away from spawning work across your repositories. Rule two prevents the trivial self-reinforcing loop. Rule one keeps a human in the path for cross-session instruction, which is exactly where injected instructions would otherwise propagate. Archived sessions are excluded from listing unless explicitly requested, which limits incidental context exposure.
When a tool creates or targets a session, VS Code renders an Open Session pill so you can jump to it. That is your audit affordance during a pilot; use it.
Isolation: the worktree checkbox
The Agents window's new-session flow replaced the folder-versus-worktree dropdown with a single New Worktree checkbox. Checked, the session runs with Git worktree isolation and keeps the agent's changes in a separate folder until you review and merge. Unchecked, it uses folder isolation.
A checkbox that defaults to unchecked is a different default than a dropdown that forced a choice. For any repository where an agent can touch shared branches, make worktree isolation the expected practice and say so in your rollout note, because the interface no longer forces the decision. The new-session picker also remembers your last agent mode and approvals choices as defaults, which is convenient and means a permissive choice made once persists silently. Our guide to parallel agents and git worktrees covers the mechanics of running several isolated sessions at once.
GitHub Enterprise sign-in is finally unblocked
Previously the agent host's Copilot authentication only supported github.com: both the OAuth flow and the Copilot token request targeted github.com, so a GHE-backed Copilot subscription could not complete sign-in. As of 1.129, VS Code can authenticate Copilot against a GitHub Enterprise instance. You choose your GHE instance at sign-in, and VS Code runs the flow and requests Copilot access tokens from that host. It works in both the editor window and the Agents window, with both the Copilot and Claude agents.
The dependency is worth stating plainly: this requires chat.agentHost.enabled. If your organisation is GHE-backed and has been waiting for agent host support, the org-level setting is the gate, and enabling it is what unblocks your developers. That makes the rollout decision more urgent for GHE shops than for github.com shops.
The migration debt nobody has budgeted
Prompt files (*.prompt.md) describe custom slash commands, and they are only supported in the Local agent harness. Other harnesses express slash commands with skills. Microsoft's recommendation is direct: migrate all prompt files to skills for compatibility across harnesses.
With chat.customizations.promptMigration.enabled, selecting a harness on the agent host when you have migratable prompt files surfaces a Migrate Prompts entry in the AI Customizations overview. The interface shows prompt files from both workspace (.github/prompts/) and user data locations, and migrates selected files to skills.
Two practical points. First, this is real work with a real deadline shape: every prompt file your organisation has accumulated stops functioning the moment a developer switches off the Local harness. Second, the migration surfaces user-data-location prompt files too, which are personal and invisible to you. Inventory the workspace ones centrally, migrate them as a batch before enablement, and tell developers to run the migration on their personal ones during the pilot rather than discovering the gap mid-task.
The silent breaking change
This one is not in the headline list and will generate bug reports.
Custom editors now opt out of diff and merge editors by default. A file can continue to open in a custom editor while its diffs and merges open in the built-in text editors. If your developers previously saw a custom editor when opening a diff or merge, that behaviour changed in 1.129.
The fixes: use the Reopen Editor With submenu in the editor toolbar's ... menu for a one-off, or configure workbench.diffEditorAssociations to always use a specific editor for matching diffs. The proposed customEditorPriority API gives extension authors separate priorities for textEditor, diffEditor and mergeEditor, including a new never value that prevents automatic selection while keeping the editor available for explicit selection:
"priority": {
"textEditor": "default",
"diffEditor": "option",
"mergeEditor": "never"
}
If the text diff editor cannot display binary content, VS Code still falls back to a compatible custom diff editor. Teams shipping internal custom editors for proprietary formats should check this before their users do.
Also in 1.129
Chat messages prefixed with ! run their contents as terminal commands, in agent host sessions in both the editor and the Agents window. Treat this as a terminal, because it is one.
Bring Your Own Key models now work in the Agents window with the Copilot harness on the agent host, which matters for teams routing to their own model endpoints for cost or data-residency reasons.
The Agents window's redesigned editor panel, behind sessions.layout.singlePaneDetailPanel, docks the editor and detail area into one pane with a shared tab bar. It supports inline and side-by-side diff toggling, expanding or collapsing all files at once, a Create Pull Request action from the editor tab title, and per-session restoration of side-pane width, open editors, active editor and per-file collapsed state across session switches and window reloads.
The experimental workbench.experimental.modernUI setting previews a modernised workbench and is enabled by default in Insiders builds.
A staged rollout plan
Do not flip chat.agentHost.enabled organisation-wide on a Friday. This sequence front-loads the work that is cheap to do early and expensive to do late.
Stage 1, inventory, before you enable anything. List every internal extension that contributes chat tools, because those tools will not follow sessions across windows. List every *.prompt.md file in every workspace. Decide your position on code agent host --tunnel and write it into your network policy.
Stage 2, migrate. Enable chat.customizations.promptMigration.enabled for the pilot group and convert workspace prompt files to skills as a batch. Convert the internal extension tools you cannot lose into MCP servers so they attach to the host rather than a window.
Stage 3, pilot on isolated repositories. Enable chat.agentHost.enabled for a small group. Make New Worktree the expected default and say so explicitly, since the checkbox does not force it. Set conservative approval defaults, remembering the new-session picker will persist whatever the developer picks first.
Stage 4, observe. Watch the Open Session pills and the cross-session confirmation prompts during the pilot; they tell you how much session fan-out your developers actually generate. If you are instrumenting agent traffic, our OpenTelemetry GenAI conventions guide covers the span attributes worth capturing.
Stage 5, widen. Add chat.agents.claude.preferAgentHost once you have reviewed the Claude harness separately, since harnesses differ in behaviour even under one protocol. For GHE-backed organisations, this is also when Copilot sign-in starts working for everyone. Broader enterprise controls around Copilot in VS Code are covered in our enterprise rollout controls guide.
Enable the protocol before you have decided your approval defaults and you will have shipped autonomy without governance.
India-specific considerations
Two points for teams operating in India or serving Indian users.
Where the host runs decides where the code goes. The agent host lives next to the workspace, and when it runs remotely, file edits and commands run on the remote machine. If a developer in Gurugram connects to an agent host over a dev tunnel to a machine in another jurisdiction, source code and any data in that workspace are processed there. Under the Digital Personal Data Protection Act 2023 the obligations attach to the entity determining purpose and means of processing, so a developer's ad-hoc tunnel does not move accountability off your organisation. Decide where agent hosts are permitted to run, and treat --tunnel as a data-transfer decision rather than a convenience flag. Our DPDP Act engineering playbook covers how this maps to notice and purpose limitation.
Seat cost is the smaller number. Copilot Business is $19 USD per granted seat per month and Copilot Enterprise $39, but both plans bill AI credit usage on top, and GitHub moved organisations and enterprises to usage-based billing. Agentic sessions consume far more than completions, and the agent host makes long unattended turns easier to start. Budget the usage, not the seats. Our notes on Copilot AI credit pools for enterprise cost control cover the mechanics.
FAQ
What is the VS Code agent host?
The agent host is a dedicated process introduced in VS Code 1.129 on 15 July 2026 that runs agent harnesses including Copilot, Claude and Codex. It communicates with VS Code through the Agent Host Protocol over JSON-RPC, and owns agent sessions independently of the editor windows that display and control them.
How do I enable the agent host in VS Code?
Enable the chat.agentHost.enabled setting, then pick an agent host harness from the harness dropdown. The setting is managed at the organisation level, so individual developers cannot turn it on themselves and must contact an administrator. Enabling the Claude agent additionally requires chat.agents.claude.preferAgentHost.
Do agent sessions keep running after I close VS Code?
Yes. Sessions are not tied to the lifetime of the window for their workspace. You can close a window and reopen the session later from another window, and while the agent host is running, an active turn can continue with no client connected. Plan approval defaults with unattended execution in mind.
Can an agent start work in other sessions?
Within limits. Agents on the agent host can list sessions, read another session's recent conversation, create a session or chat, and message a session they created. Sending always asks for confirmation, an agent cannot message its own chat, and a burst of sends is capped so one request cannot fan out unboundedly.
What is the difference between worktree and folder isolation?
The new-session configuration shows a New Worktree checkbox. Checked, the session runs with Git worktree isolation, keeping the agent's changes in a separate folder until you review and merge them. Left unchecked, it uses folder isolation. The checkbox replaced the earlier dropdown, so the choice is no longer forced.
Does the agent host work with GitHub Enterprise?
Yes, as of 1.129. Previously the agent host's Copilot authentication only supported github.com, so GHE-backed subscriptions could not sign in. Now you choose your GitHub Enterprise instance and VS Code requests Copilot tokens from that host. It requires chat.agentHost.enabled and works with both Copilot and Claude agents.
Why did my custom editor stop opening diffs?
Custom editors now opt out of diff and merge editors by default in 1.129, so a file may open in a custom editor while its diffs open in built-in text editors. Use the Reopen Editor With submenu for a one-off, or set workbench.diffEditorAssociations to always use a specific editor for matching diffs.
Do I need to migrate my prompt files?
Microsoft recommends it. Prompt files are only supported in the Local agent harness, while other harnesses use skills for slash commands. Enable chat.customizations.promptMigration.enabled and a Migrate Prompts entry appears in the AI Customizations overview, covering both workspace and user data locations.
How eCorpIT can help
eCorpIT is a Gurugram-based, CMMI Level 5 and MSME-certified technology organisation founded in 2021, and a Microsoft and GitHub-ecosystem partner alongside AWS and Google. Our senior engineering teams run agent-tooling rollouts the way this guide describes: inventory and migration first, isolation defaults set deliberately, approval policy written before the switch is flipped, and telemetry in place so you can see actual session behaviour rather than guess at it. We also design the data-handling side to align with DPDP requirements when agent hosts run across jurisdictions. Talk to us about a staged agent host rollout for your platform team.
References
- Visual Studio Code 1.129 release notes (15 July 2026)
- VS Code Agent Host architecture documentation
- Agent Host Protocol documentation
- Agent Host Protocol source repository
- GitHub Copilot SDK on npm
- VS Code Agents window documentation
- VS Code Bring Your Own Key language models documentation
- Plans for GitHub Copilot, including per-seat pricing
- Usage-based billing for GitHub Copilot in organizations and enterprises
- VS Code 1.129.1 closed issues milestone
- Visual Studio Magazine, VS Code 1.129 Introduces Agent Host and Experimental Agents Window Editor
- Help Net Security, VS Code agent host runs Copilot, Claude, and Codex in a dedicated process
- VS Code agent security documentation
- GitHub Changelog, GitHub Copilot CLI is now generally available (25 February 2026)
Last updated: 21 July 2026.
Top comments (0)