VS Code 1.129 change AI Agent Sharing Across Multiple Windows

VS Code 1.129 just untethered AI agents from individual windows. That's a small line in the release notes and a big shift in how an agent is supposed to behave in an editor — and worth understanding for anyone who's spent the last year chasing tabs back to the window they started their agent in.

Until now, an agent session in VS Code was welded to the window you launched it in. Open a second window on the same repo to check a file? That second window knew nothing about the agent running next door. Close the original window, lose your place, or scroll back through chat history to recover context. For long-running agent work — refactors, multi-file migrations, "go fix all the failing tests" — the window-binding was an arbitrary constraint that made the agent feel like a tab state instead of a tool.

The 1.129 release breaks that link. Agents now run in a dedicated background process called the agent host, and any VS Code window can connect to it. You see the same conversation, the same in-progress diffs, and the same live status, regardless of which window you're looking at. The agent keeps going even if you close the one you started it in. The full release notes are on the official VS Code site.

That's a meaningfully different mental model. The agent isn't a chat panel anymore — it's a persistent identity with its own process, and the window is just the view. Once you see it that way, the rest of the release makes a lot more sense.

The agent host process, in plain terms

The agent host is a background process that owns the session. The window is now a client that connects to it. When the window closes, the host doesn't tear down — it just loses a viewer. When a new window opens on the same workspace, it asks the host "what's the state of session X" and renders it locally.

This is also why the rollout is gradual and opt-in. You turn it on with a setting and pick an agent from the harness dropdown — Copilot, Claude, or Codex. There's a real caveat for anyone on a managed machine: this setting is controlled at the organization level, so an admin has to enable it before you can flip it yourself.

Why the Copilot SDK alignment matters

For Copilot users specifically, there's a quiet knock-on improvement. On the agent host, the Copilot agent runs on the Copilot SDK. That's the same runtime behind the Copilot CLI, the standalone GitHub Copilot app, and the rest of GitHub's Copilot tooling. Before 1.129, the Copilot agent inside VS Code was a slightly different beast — same brand, different engine. Now it shares behaviour, prompts, and capabilities with the rest of the Copilot surface area, which means less drift between "what works in the CLI" and "what works in the editor."

For teams that have already standardised on the Copilot CLI or its standalone app, this is the update that closes the gap. Your editor agent stops being the one weird cousin.

Agents managing other agents

This is the genuinely new part of the release, and the bit that's worth paying attention to. Agents running on the host — Copilot, Claude, or Codex — now ship with a set of session-management tools baked in. An agent can:

• List your other sessions, with their current status and outstanding changes.
• Read what another session has been doing.
• Create a fresh session or chat to hand a sub-task off, instead of cramming everything into one giant thread.

That last capability is the interesting shift. A long-running refactor can spawn a child session for an investigation, hand it off, and keep the parent's context clean. A flaky-test pass can fork per file and report back. You stop fighting one monolithic thread that's trying to be a project manager.

The source article notes mid-thought that this is exactly the kind of thing that could get out of hand, so it's fair to expect Microsoft has shipped guardrails alongside the tools — but the article text doesn't go far enough to spell out what those guardrails are. Treat the safety model as "watch this space" rather than "this is solved," and don't put agents you don't trust in charge of spawning more agents.

How to turn it on today

The setup is straightforward, but worth doing in order so you don't get stuck on the org-managed-machine gotcha.

1. Update VS Code. Help → Check for Updates, or grab the installer from the VS Code site. You want 1.129 or later.

2. Make sure the AI extension for your harness is installed and signed in. Copilot, Claude Code, and Codex all ship as marketplace extensions; install the one you use and authenticate.

3. Enable the agent host. Either toggle it through Settings (search for "agent host"), or set it directly in your user settings.json:

   // settings.json — opt into the new agent host process
   {
     "chat.agentHost.enabled": true,
     // pick the harness your extension exposes
     "chat.agent": "copilot"   // or "claude" / "codex"
   }

4. If the toggle is greyed out, you're on a managed machine — ping your admin. The setting is controlled at the org level.

5. Launch an agent in one window. Open a second window on the same workspace. Both should show the same session, conversation, and status without any extra wiring.

There's nothing extra to install on the OS side; the host runs as part of the editor process tree. If session state doesn't show up in a second window, the most common cause is that the second window isn't pointed at the same workspace folder — the host scopes sessions to the workspace, not to the machine.

What this tells us about durable layers

Here's the part that doesn't change when the model does. The agent host is a durable process. The window is a view. The session outlives any one view of it. Once you internalise that shape, it shows up everywhere — in editor architecture, in agent runtimes, and in app frameworks that need to coordinate work across surfaces.

That last one is the angle we keep coming back to. When you ship an app to web, iOS, and Android, the same architectural decision shows up in miniature: is your business logic and session state bound to a single surface, or does it live in a host that every surface can connect to? The editors that get this right — and VS Code 1.129 just got a lot more right — ship the host as a first-class process, not as a side-effect of having a window open.

The agent frameworks above the host will churn. New models, new harnesses, new tool shapes every quarter. The pattern underneath doesn't. Build on the pattern, and you don't have to rebuild the app every time the editor or the model swaps out from under you. The session outlives the window; the behaviour outlives the harness. That's the durable layer worth betting on.

VS Code 1.129 is a clear win. Switch it on, pick the harness you already use, and let the agent out of its window.