Your AI Agent Now Outlives the Editor That Launched It
VS Code 1.133 moved agent sessions into a persistent Agent Host. Edits now land before review, and that changes your threat model.
Somewhere in the VS Code 1.133 release notes, between sticky chat scroll and an HTML preview that refreshes itself, the editor's relationship to AI agents changed shape. Agent sessions moved out of the extension host into a dedicated process called the Agent Host. Close every window, walk away, and the agent keeps working. Its edits land in your working tree whether you're watching or not.
Most coverage framed this as an architecture cleanup. I think it's a security redesign that shipped without the word "security" anywhere near it.
What actually shipped
The Agent Host runs sessions in their own process, separate from the extension host where Copilot Chat lived before. It speaks the Agent Host Protocol, AHP for short, open-sourced by Microsoft under MIT, and the repository was still taking commits this week. The protocol's own site places it "in the lineage of LSP and DAP," and that comparison carries more weight than it gets. LSP ended the era of every editor reimplementing language support. AHP wants the same spot for agent sessions: one host, many clients, any agent behind it.
The same release lets the Agents window open with a Claude API key and no GitHub sign-in, and you can mix Anthropic and Copilot models between turns. Microsoft's editor, Anthropic's agent, your key. Worth its own post someday; today I care about what runs underneath.
Two behaviors follow from the split, and the docs spell both out. A session survives its window: close VS Code, reopen it, pick the session up elsewhere, and while the host runs, an active turn continues with no client attached at all. The docs don't treat that as an edge case. It's the design.
The host can also live on another machine. code agent host starts a standalone server on localhost, guarded by a connection token, and the --tunnel flag exposes it through a dev tunnel. The Agents window reaches it over SSH, and when the host runs remotely, file edits and commands execute next to the workspace.
And then there's the change buried in a comparison table: edits apply directly.
The review checkpoint moved
On the old extension host, an agent's edits sat in a pending state until you kept or undid them. Human judgment happened before anything touched disk.
Agent Host sessions work the other way around. Edits land straight in the session folder or worktree, and you review the diff afterward, then commit, merge, or discard. The checkpoint still exists. It moved from before-write to after-write.
For a one-line rename, a nothingburger. For a twenty-minute agent turn that ran while you were in a meeting, the tree you come back to is already mutated, and your review is archaeology on a diff instead of a gate in front of one. Since sessions can outlive the client, edits landing with nobody watching isn't a failure mode. It's the advertised feature.
A quieter change rides along. The Agent Host reads customizations from ~/.copilot and ~/.claude, and MCP configuration from .mcp.json in the workspace plus ~/.copilot/mcp-config.json. Config that used to live inside the VS Code profile is now read by a process whose lifetime has nothing to do with the editor. Convenient if you hop between tools. It also means the blast radius of a poisoned config file no longer depends on whether VS Code is open.
A daemon with shell rights
Strip the branding and describe the artifact. A long-running local server that can read your files, write to your working tree, and run commands on whatever machine hosts the workspace. It accepts connections from other windows, from other machines over SSH, and from the internet through a dev tunnel. The guardrail named in the docs is a connection token.
I'm not calling this reckless. VS Code's remote development stack has run similar machinery for years, and tunnels carry plenty of legitimate work. But an agent that died with the window and a daemon that persists are different objects, and that difference deserved more than a row in a table. Persistence cuts both ways. It's convenient for you on Tuesday and convenient for whatever got a foothold on Wednesday.
The optimistic reading deserves its due, and I hold part of it. AHP orders every mutation into a single sequence-stamped broadcast, with immutable state and pure reducers keeping clients honest. That's an audit log by design. If security teams can subscribe to that stream from outside VS Code, agent actions become observable in a way extension-host chaos never allowed. Durability and recordability come from the same design choice. What's missing is tooling that subscribes, and defaults that say who may connect to a host which can edit files.
What I do before turning it on
I'm not switching any of it off. The direction is right, and interoperable sessions beat the current mess where every tool owns its own silo. But the defaults assume a level of trust in my machine that I don't share with it.
One worktree per agent session, so a detached turn can only mutate a branch I created to be mutated. Diffs read before anything merges, which the after-the-fact model still permits as long as I hold the merge button. The tunnel flag stays off until a reason shows up, because reachable-through-a-dev-tunnel is a state I want to opt into, not inherit. And those config files get treated like the small executables they effectively are.
The LSP comparison everyone reaches for is apt, with one amendment. LSP standardized a read-mostly service. AHP standardizes a write-capable one. When the protocol that wins is the one that can edit your files, the story stops being the architecture diagram and starts being who's connected while you're not looking.
Comments ()