VS Code Agents Window: Multi-Project AI Workflows, Git Worktrees and Claude/Codex Harnesses

In an October 15, 2026 commentary for XDA Developers, writer Anurag Singh detailed how spending a month with VS Code's dedicated Agents window eliminated his need to keep switching to Cursor. While that preference reflects one developer's workflow rather than an absolute feature-for-feature victory across every coding scenario, it highlights a major architectural shift in how Microsoft's flagship editor handles autonomous software development. Backed by Microsoft's underlying Agent Host architecture, the new Agents window separates high-level task delegation from hands-on code editing—giving developers a centralized mission control for multiple repositories, isolated Git worktrees, and competing AI harnesses without abandoning their established VS Code extension ecosystem.

From Sidebar Clutter to a Dedicated Command Center​

When you delegate a complex refactoring job or bug fix to an AI coding agent, your role shifts from typing syntax to supervising execution, answering clarifying prompts, and reviewing diffs. Historically, doing that across multiple projects in VS Code meant juggling separate editor windows, each tied to its own workspace and extension host process.

As Microsoft's Visual Studio Code documentation explains, the Agents window opens as a distinct window alongside your main editor, designed specifically for assigning work across several projects and tracking results in one place. Rather than replacing the traditional IDE interface, it complements it. In fact, Microsoft explicitly recommends sticking to the standard Chat view beside the editor when a task requires frequent manual editing, interactive debugging, or hands-on testing within a single project. When the goal is multi-project delegation and code review, the Agents window takes over.

On Windows and other supported platforms, developers can launch the environment through several native entry points:

• Clicking the Open in Agents button directly in the VS Code title bar.
• Running the Chat: Open Agents window command from the Command Palette (Ctrl+Shift+P on Windows and Linux).
• Launching code --agents from the terminal or command prompt.
• Right-clicking the VS Code icon on the Windows taskbar and selecting Agents Window from the Tasks jump list.
• Accessing the browser-based interface at insiders.vscode.dev/agents (which always requires GitHub authentication).

How the Agent Host Keeps Sessions Alive​

The reason this window feels like a genuine platform upgrade rather than a cosmetic UI skin comes down to what Microsoft engineers Rob Lourens, Connor Peet, and Brigit Murtaugh detailed in an August 26, 2026 Visual Studio Code blog post: the Agent Host and the open Agent Host Protocol (AHP).

Previously, VS Code ran local agent harnesses inside each editor window's extension host process. If you closed that specific folder or editor window, the runtime stopped dead in its tracks. The Agent Host moves session state, harness adapters, and baseline workspace operations into a self-contained background process.

Because the Agent Host owns the session rather than the individual editor window, an agent can keep working even after you close the folder where it started (provided VS Code itself remains running to manage the local host, or the host is running remotely as a standalone server). Both the main editor and the Agents window act as synchronized clients connected to that single host process. You can kick off a task in your regular editor, close the folder, check its progress in the Agents window, and jump back into the code without duplicating sessions or losing state.

Section Summary: The Agents window separates multi-project AI supervision from manual coding. Powered by the background Agent Host process, agent sessions persist across workspace changes and stay synchronized between the main code editor and the dedicated management window.

Multi-Project Workflows and the Git Worktree Caveat​

In his XDA Developers piece, Singh pointed out a common real-world scenario: assigning one agent to squash a bug in one repository while tasking a second agent with building a feature in another project—or even running both tasks simultaneously inside the exact same repository.

In the Agents window, sessions appear grouped by workspace in a central sidebar, displaying live progress indicators, change statistics, and alerts when an agent needs human input. Clicking a session makes it active, dynamically switching the window's Files, Changes, Terminal and Tasks, and integrated Browser views to match that specific project's context. If you want to watch two agents work at the same time, you can drag sessions into a two-dimensional split grid or navigate between panes using keyboard shortcuts (Ctrl+K Ctrl+Left/Right/Up/Down on Windows).

Code Isolation vs. Security Boundaries​

Running two agents on two different repositories is straightforward, but turning two agents loose on the same repository at the same time is a recipe for mid-air collisions if they share a working directory. Simply opening two separate chat tabs does not stop two agents from overwriting the same files.

To prevent this, the Agents window lets developers assign a workspace session to a New Worktree. Creating a separate Git worktree gives each agent its own isolated working copy based on a selected base branch, keeping experimental edits out of your primary active workspace until you are ready to review and integrate them.

However, Windows developers and enterprise administrators need to understand the exact technical boundaries of Microsoft's worktree implementation:

That distinction between code isolation and system security is critical. Microsoft's documentation explicitly warns that while a Git worktree protects your active working tree from conflicting file edits, it does not restrict the agent from running commands, accessing the network, or touching files outside the worktree. Furthermore, because worktree sessions use "Allow all" permissions rather than interactive manual approval prompts, developers working with untrusted code or sensitive environments must configure OS-level agent sandboxing or use Dev Containers rather than relying on Git worktrees as a security barrier.

Section Summary: Developers can monitor parallel tasks across projects in a unified sidebar or split-screen grid. When running parallel tasks in a single repository, Git worktrees prevent file collisions, though developers must remember that worktrees only isolate committed files and do not restrict system commands or network access.

Choosing Your Harness: Why Copilot, Claude, and Codex Aren't Interchangeable​

One of the strongest arguments for returning to VS Code is avoiding single-vendor lock-in. As Singh noted in XDA Developers, the Agents window allows you to pick between GitHub Copilot, Claude, or Codex as the underlying session harness, rather than restricting you to Microsoft's own agent pipeline.

To get the most out of this setup, it helps to understand what Microsoft means by an agent harness. Selecting a Claude model inside the GitHub Copilot chat dropdown is not the same thing as selecting the Claude harness.

• Model Selection Inside a Harness: When you use the Copilot harness and pick an Anthropic model from the model picker, VS Code still uses the GitHub Copilot SDK, Copilot's agent loop, and Copilot's tool definitions.
• Switching the Harness: When you switch the session harness itself to Claude, the Agent Host loads Anthropic's official Claude Agent SDK. An adapter translates its events into the Agent Host Protocol so it renders cleanly in the VS Code UI, while preserving Anthropic's native agent loop, tools, permissions, slash commands, and hooks.

Similarly, users can configure project instructions (to enforce coding conventions or test suites) and tool approval rules per session, but because each harness relies on its own underlying SDK, configurations and permission rules do not necessarily behave identically across Copilot, Claude, and Codex.

Authentication, BYOK, and Offline Realities​

By default, launching the desktop Agents window uses your GitHub account to authenticate with GitHub Copilot. However, Microsoft has introduced experimental support for running the desktop Agents window without signing into GitHub if you already have configured credentials for another supported provider—such as a Claude API key, a ChatGPT sign-in for Codex, or a Bring Your Own Key (BYOK) language model.

While having multiple harnesses and BYOK support gives developers significant flexibility, it is not a complete divorce from Microsoft's cloud ecosystem unless you configure it carefully:

1. BYOK in Agent Host is Experimental: To use custom API keys or local models (such as Ollama via the official Visual Studio Marketplace Ollama extension, or Foundry Local via the AI Toolkit) inside Copilot harness sessions in the Agents window, users must enable the experimental chat.agentHost.byokModels.enabled setting. Microsoft notes that any BYOK model used with agents must support tool calling to appear in the picker.
2. Background Utility Models: Even when you pick a third-party or local model for your main agent chat, VS Code runs lightweight background models for utility tasks like generating session titles, writing commit messages, summarizing PRs, and detecting intent. If you run signed out of GitHub using only BYOK models, those built-in utility features stop working until you explicitly point chat.utilityModel and chat.utilitySmallModel (or chat.byokUtilityModelDefault) to one of your own configured models.
3. GitHub-Dependent Editor Features: Microsoft's language model documentation confirms that certain core AI features—specifically semantic search, inline code completions, and features relying on embeddings—still require a GitHub account, a Copilot plan, and an active internet connection. Moreover, in Copilot Business and Enterprise environments, IT administrators control whether BYOK or preview models are permitted at all via organization policies on GitHub.com.

Section Summary: The Agents window supports distinct harnesses—including Copilot, Claude, and experimental Codex integrations—allowing each provider to run its native SDK and tool loop. While experimental settings allow desktop use with API keys or local models without a GitHub sign-in, background utility flows and inline completions still require manual overrides or a GitHub Copilot connection.

Code Review, Diffs, and Current Limitations​

Once an agent finishes its run, the workflow pivots to verification. Instead of copying code snippets back and forth into a chat box to explain what an agent got wrong, you can open the Changes view in the Agents window to inspect branch changes, uncommitted edits, all changes, or just the edits from the last agent turn. Highlighting a specific range of lines inside the diff editor lets you leave targeted, inline feedback for the agent to address on its next turn.

For web developers, the Agents window also ties an integrated browser directly to the active session, keeping localhost tabs and page states scoped to that specific workspace while keeping HTML code diffs in the standard diff editor. From the same panel, you can trigger workspace build tasks, generate commit messages, create pull requests, or even enable an experimental Agent merge mode that watches a pull request and autonomously repairs review blockers or failing checks.

Still, before uninstalling competing editors, developers should weigh several documented limitations in VS Code's current implementation:

• Multi-Root Workspaces: Multi-root sessions are not yet supported in the Agents window, though you can attach additional folders or repositories as context or instruct an agent to work across projects within a single session.
• Editor-Only Harnesses: While the experimental Codex integration works in both the Agents window and the main editor, local-harness sessions and sessions originating from the standalone OpenAI Codex extension remain restricted to the main VS Code editor window.
• Cloud Repository Boundaries: Copilot Cloud sessions require GitHub-backed repositories, though standard Copilot harness sessions in the Agents window still work with non-GitHub projects.
• Plan Agent Access: The dedicated Plan agent does not currently appear in the Agents window dropdown, meaning users must invoke it manually via the /plan slash command inside a Copilot or Claude session.

For many developers, however, those trade-offs are minor compared to the friction of maintaining two separate IDEs. Cursor helped pioneer the idea that AI agents deserve a dedicated management console rather than a cramped chat sidebar. By building the Agent Host protocol and bringing multi-project orchestration, Git worktree isolation, and native third-party harnesses like Anthropic's Claude SDK directly into Visual Studio Code, Microsoft has given veteran VS Code users a compelling reason to stay right where they are.