Across five releases this summer — v1.123 through v1.127, spanning June and July 2026 — Microsoft quietly rebuilt how VS Code runs AI agents. The headline change is a dedicated "agent host": a separate process, built on what Microsoft calls the Agent Host Protocol (AHP), that runs agent harnesses like Copilot, Claude, and Codex outside the editor's own process. Because the session now lives somewhere else, the same running agent session can be connected to and rendered from multiple VS Code windows at once. Alongside it, VS Code shipped the ability to run agent sessions side by side, an experimental docked editor panel for reviewing agent-generated diffs in the Agents window, general availability for agentic browser tools that let an agent navigate, screenshot, and validate a running web app, and a public preview letting that browser's HTTP(S) traffic route through a remote connection. GitHub published its own June 2026 Copilot-in-VS-Code changelog on July 8 covering the same window. None of this is a single feature drop — it's a coordinated re-architecture, and it's worth understanding why.
The agent host is an admission about where agents actually belong
For the last two years, AI coding assistants in VS Code have effectively been features bolted onto the editor's UI thread — a chat panel, a set of inline suggestions, a sidebar that shared memory and lifecycle with everything else in the window. That model works fine for a single back-and-forth conversation but falls apart the moment you want an agent to keep working after you close the window, or you want to check on it from a laptop while it was started on a desktop. Pulling the agent session into its own process, addressable over a protocol rather than owned by a specific window, is Microsoft acknowledging that long-running agent work doesn't behave like editor state. It behaves like a service.
That distinction matters more than it sounds. Editor state is transient and single-owner: you close the window, the state goes away. A running agent task — refactoring a module, chasing down a flaky test, migrating a config format — has a lifecycle that outlives any one window's attention span, and often outlives the developer's attention span too. By decoupling the session from the window that spawned it, VS Code is explicitly designing for the case where you start a task, walk away, and reconnect from somewhere else — the same pattern that made tmux indispensable for long shell sessions, just applied to agent work instead of terminal state. It's also the same instinct behind headless and cloud-hosted agent execution that's been showing up elsewhere in the AI coding tools space (see our earlier piece on autonomous agent execution for the broader trend). What's new here is that Microsoft is building the multiplexing primitive directly into the flagship editor rather than leaving it to third-party orchestration layers.
Side-by-side sessions change the unit of work from "conversation" to "portfolio of tasks"
The second piece — running agent sessions side by side, keeping separate tasks visible and active at once — is the more immediately practical change for day-to-day engineering. In the sessions list you can now select "Open to the Side," drag a session into the sessions view, or hold Alt and click a session to pop it open next to another. Multiple sessions can be visible simultaneously, though VS Code is careful to note only one is "active" at a time — the Terminal, Files, and Changes views still track whichever session currently has focus.
That caveat is the tell. This isn't multitasking in the sense of the editor juggling several live execution contexts identically; it's a UI for keeping several background agent tasks within eyeshot while you steer one of them directly. But even that shallower form of parallelism is a real shift in how engineers work with AI tools. The pair-programming mental model — one human, one assistant, one shared cursor — assumes the bottleneck is the conversation itself. Side-by-side sessions assume the bottleneck is the human's attention, and that attention should be allocated across several agents running different tasks: one cleaning up test coverage on a legacy module, one drafting a migration script, one investigating a bug report, all visible in the same window without three separate VS Code instances open. It's the same shift server-side infrastructure went through decades ago, moving from one process per request to worker pools — except here the "workers" are AI agents and the queue is a human occasionally checking in on each one.
Browser tools reaching GA closes a loop that used to require a separate tool
The most concrete, immediately useful change in this cycle is that agentic browser tools moved from experimental to general availability, alongside per-site permission controls for the integrated web view. In practice this means an agent inside VS Code can open a page, click, type, hover, drag, handle dialogs, read page content, capture console errors, and take screenshots of a running web app — all without the developer switching to a separate browser, writing a Playwright script, or asking a human tester to eyeball the result. Tabs stay private by default; a page only becomes visible to the agent once you explicitly select "Share with Agent," and that access can be revoked at any time.
For teams building or maintaining web applications, this closes a feedback loop that has historically needed either manual QA or a standalone browser-automation framework wired into CI. An agent that changes a component and can then navigate to the affected page, confirm the layout didn't break, and paste back a screenshot as evidence is meaningfully different from an agent that can only tell you the code compiles. It shortens the verification step from "trust the diff, run the test suite, hope someone eyeballs it in staging" to "the agent already looked at the rendered result before handing you the change." The same release cycle added a public preview for routing that integrated browser's HTTP(S) traffic through a remote connection when the workspace itself is remote — useful for anyone doing this work against a devcontainer or a cloud-hosted workspace rather than local infrastructure, since without it the browser would be reaching out from the wrong network entirely.
That capability cuts both ways, though, and it's worth being deliberate about the tradeoff rather than treating GA as a green light to enable it everywhere by default.
What browser access means for security posture, and for code review
Give an agent the ability to navigate and read arbitrary web pages inside your editor and you've also given it a plausible path to reach internal systems, internal dashboards, or authenticated sessions it shouldn't touch — especially once remote proxying is involved and the browser's network path is no longer just "whatever the developer's laptop can see." The per-site permission model and the "Share with Agent" opt-in are the right defaults, but they're defaults, not policy. Any organization enabling this for a team should be treating it the same way they'd treat a new class of CI runner with network access: What's on the allowlist? Can the agent's browser reach the internal ticketing system, the staging environment with real customer data, the VPN-gated admin panel? Those are network policy questions, not editor settings, and the answer shouldn't be "whatever the browser happens to be able to resolve."
The parallel-sessions and browser-GA changes also land squarely on code review practice. If an agent can run several tasks side by side and validate each one visually before handing it back, the natural failure mode is a developer accepting a batch of agent-authored diffs on the strength of "it looked right in the screenshot" rather than reading the actual change. The new experimental editor panel in the Agents window — which lets you review agent-generated files and diffs in a docked editor rather than a side chat bubble — is clearly Microsoft's answer to that risk, making the diff review a first-class, full-width activity instead of an afterthought squeezed into a narrow panel. But a UI affordance doesn't substitute for a review norm. Teams adopting this workflow should be explicit that agent-authored PRs get the same line-by-line scrutiny as human ones, and that a passing visual check from the agent's own browser tool is evidence, not a substitute for that scrutiny — the agent validated its own understanding of "correct," which is exactly the case where an independent human read matters most.
Practical takeaways for teams adopting this now
If you're an engineering lead deciding whether to roll v1.123-1.127's agent tooling out to your team, a few concrete steps make the transition safer and more useful:
- Scope browser-tool access before enabling it broadly. Decide which environments the integrated browser is allowed to reach — local dev servers only, or staging too — before turning GA browser tools on for the whole team, and document it the way you'd document a new CI runner's network access.
- Treat the remote-proxy preview as preview. It's public preview, not stable; test it against a non-production remote workspace first, especially if that workspace can reach internal network segments.
- Update PR review norms explicitly, not implicitly. State in writing that agent-authored diffs get the same review depth as human-authored ones, regardless of what the agent's own browser validation reported.
- Use side-by-side sessions for genuinely independent tasks, not one big task split awkwardly. The UI rewards parallel, unrelated work — bug triage next to a refactor next to a test-coverage pass — more than it rewards splitting a single feature across sessions that will need to merge back together.
- Pilot the docked diff-review panel with your most diff-heavy reviewers first. It's still experimental; the people doing the most review volume will surface its rough edges fastest and can tell you whether it actually beats the existing chat-embedded diff view.
None of this requires a new tool purchase or a new framework — it's a settings and process conversation layered on top of an editor most teams already run. But the underlying signal is bigger than the settings screen: VS Code isn't adding an AI feature this cycle, it's re-platforming around the assumption that agent sessions are long-lived, multi-window, and plural by default. Editors that don't make the same move are going to look, within a year or two, like they were built for a world where you talked to one assistant at a time.