VS Code 1.146 Deprecates Local Agent Harness: Copilot Migration Due February 2027

Microsoft summarized the headline change this way: "Move to the Copilot harness before the Local harness is removed in February 2027." Most of the other changes in 1.146 build around that move: session triage, separate chat windows, extensions in the Agents window, model comparisons, tighter sandbox controls and new enterprise policy hooks.

The Local harness deprecation​

Some background first. The Copilot harness is Microsoft's latest agent harness and has been the default for new sessions since VS Code 1.143. It is built on the Copilot SDK, which several Copilot products share. Copilot harness sessions run through the Agent Host, so you can keep them running in the background and access them from both the VS Code editor window and the Agents window. Admins should note this line: "For organizations, the Copilot harness also enforces managed sandbox and permission policies that the Local harness doesn't."

The timeline:

• Now through February 2027: The Local harness still works but is "functionally frozen." New features go to the Copilot harness and may not work on Local.
• February 2027: The Local harness is removed, and the vscode.temporaryDefaultToLocalHarness enterprise-managed setting, introduced in VS Code 1.142 to keep the Local harness as the default, will also be removed.

Microsoft's product docs already reflect the change, and they show more about what moving actually involves than the release notes do. The "Use tools with agents" documentation says user-defined tool sets are deprecated and are not supported in the Copilot harness. If your workflow depends on them, you'll need to rework it, not just flip a switch. The same page says Copilot harness sessions use the built-in shell tool by default, and that the integrated-terminal controls it describes apply to Local harness sessions. Some terminal behavior you're used to may therefore change. One capability moves the other way: computer use is available for local Copilot harness sessions on macOS and Windows, and it isn't available for the Local, Claude, or Codex harnesses, Linux, or remote or cloud hosts.

The docs also explain that "Local" is just a label. It is a harness name, not the only way to run agents on your machine; other harnesses can also work with local files. Losing the Local harness doesn't mean losing agents that work on files on your own machine.

The switch hasn't been painless for everyone. In a public pull request, the maintainers of an open-source project called agent-cost-analyzer reported that their real-Copilot test suite broke on 1.146. Their note says that on 1.146, users' new chats default to the Copilot SDK harness. They also described a launch failure in which SDK-harness sessions kept VS Code from quitting, which disrupted their automated test runs. That's one project's experience, not a confirmed widespread bug. Still, if you run CI or end-to-end tests that drive VS Code with Copilot, it's worth checking that they still pass.

Migration checklist​

1. Check your harness. Start a new session and look for "Copilot" in the harness picker. Since Copilot is already the default, many users won't need to change anything.
2. Audit your customizations. Microsoft's Local-to-Copilot harness transition guide covers customization compatibility, continuing existing Local conversations, and organization rollout and verification. Look at tool sets and terminal-specific setups first.
3. Admins: If you used vscode.temporaryDefaultToLocalHarness to keep users on Local, plan to drop it before February 2027.
4. Test automation: Re-run any test suites that drive Copilot chat on 1.146.

Bottom line: For most individual users this is a deadline they can mostly ignore. Organizations with Local-era customizations or tooling have about three months to migrate.

Inbox mode and inline actions​

Inbox mode (Experimental) gives you one view of agent sessions across all your projects, so you don't have to check each workspace. To try it:

1. Enable sessions.list.inboxEnabled (off by default).
2. In the Agents window's sessions list, choose Grouping > Inbox Mode.

Sessions that need your attention appear at the top, above the Working, Ready to merge, On hold and Done groups. You can push a session aside with Dismiss from Inbox, Put on Hold or Snooze, and reverse it with Undo. Dismissing a session does not archive it. To archive, use Mark Session as Done.

Session list inline actions (Experimental), enabled with sessions.list.inlineActions (off by default), add buttons to the sessions list for fixing failing checks, addressing review comments, or both. Each action sends a background request to that row's session or nested session without opening it. Microsoft says the setting does not enable Agent Merge and does not change action permissions.

Chat windows (Preview)​

When several chats run in one Agents window, you end up flipping between them. Chat windows let you open a chat in its own window with its editors and terminals. The setting sessions.chatWindows.enabled is on by default in Insiders and off by default in Stable.

• Open one: Right-click a session or chat and choose Open in > New Window, or drag the chat out of the Agents window. Move to Main Window puts it back.
• Multiple chats per window: Pick another session from the title bar, drag a chat in from another window, or press Ctrl+N on Windows and Linux for a new session.
• Rearrange the layout: Drag parts by their grabbers, split them by dropping tabs on their edges, or drag an editor tab onto the chat input to attach it as context.
• Place the terminal: Put it under the editor, under the chat, or full width.
• Reset: Developer: Reset Chat Window Layout restores the original arrangement. Chat windows also come back with their chats and editors after a restart.

Extensions in the Agents window (Experimental)​

Before 1.146, you had to go to an editor window to install an extension. Now the Extensions section of Agent Customizations can search the Marketplace and show each result's publisher, install count and rating. You can install and uninstall extensions there, and a dropdown next to Install lets you pick a pre-release version. VS Code warns you up front if an extension contributes views, debuggers, status bar items or walkthroughs without declaring support for the Agents window. If an extension is blocked, for example by organization policy, it shows the reason. On Windows, press Ctrl+Shift+X or run Extensions: Manage Extensions to open the section.

Model comparison, canvases and MCP skills​

Compare Models (Preview) runs the same prompt across several models, has a "judge" model evaluate the results, and can use a "synthesizer" model to combine the best parts. New in 1.146:

• You can judge and synthesize chat-only responses without selecting a workspace. Synthesis creates a new chat and leaves the original attempts unchanged.
• Copilot Fusion and its effort tiers can be used as an attempt, the judge or the synthesizer.
• With sessions.chat.compareAgents.tools.enabled (experimental, off by default, requires Compare Models), agents can discover models, launch comparisons and summarize the results themselves.

Canvases (Preview) are shared, interactive surfaces where you and Copilot work on plans, dashboards and similar artifacts. In Copilot harness sessions, canvas extensions now ask for approval before turning on privileged capabilities such as hooks. Canvases also restore when you return to an inactive session, without needing another prompt.

Skills over MCP (Preview), enabled with chat.agentHost.mcpSkills.enabled, adds support for SEP-2640, which lets MCP servers supply skills to the model. The first time you connect to such a server, VS Code asks permission before adding its skills to the model's context. You can then see them on the Skills tab of the Agent Customizations editor.

Security changes​

These are the changes Windows admins should read closely.

• Narrower permission prompts. Before 1.146, the default answer when the Copilot harness wanted to fetch a URL was "Allow in this Session," which let the model access any URL for the rest of that session. Defaults are now scoped to specific domains, commands and directories.
• Masking environment variables. chat.agent.sandbox.credentials.envVars hides chosen environment variables from sandboxed agent tools. The tools see placeholders, and the real value is filled in only for outgoing HTTPS requests to hosts listed in injectHosts. Enter variable names in this setting, never the secret values. On Windows, masking requires local-network access, and on Windows and macOS you must trust the sandbox CA certificate for tools that rely on the operating system's certificate trust.
• Sandbox status at a glance: When terminal sandboxing is on, the empty chat input shows "(sandbox enabled)."

Enterprise changes​

• Proxies: Copilot sessions now follow VS Code's proxy configuration, including PAC files and Kerberos authentication, when running locally, in WSL or in a local Dev Container. This should help with Copilot sessions failing behind corporate proxies.
• Help links for blocked users: Set communication.support.url in managed settings to a valid absolute HTTP or HTTPS address. Supported policy blocks, such as disabled Agents or models your organization has turned off, then show a "Contact Admin" link to your internal help page.
• Canvas governance: strictPluginOnlyCustomization now also blocks standalone canvas extensions. You can set it to true, or to a list drawn from "skills", "agents", "hooks", "mcp" and "extensions". Be aware that VS Code's boolean-only ChatStrictPluginOnlyCustomization policy does not control canvas extensions. You need the Copilot-managed setting for that.

Smaller changes​

• Copilot CLI to VS Code: Type /code (or /code-insiders) in the Copilot CLI to move a session into VS Code. It keeps its conversation history, model, reasoning effort, mode and permissions. This needs Copilot CLI 1.0.107 or later with experimental features enabled. Permissions that apply only to the CLI process, such as --allow-tool, don't carry over.
• Configure computer sharing (Experimental): You can share your machine with other clients through GitHub Environments or Dev Tunnels, or turn sharing off.
• Virtual repositories: VS Code supports virtual workspaces, allowing you to do things like viewing a GitHub repository without having to clone it. The Copilot harness now works in them too.
• Other updates: Mermaid 12 rendering, including use-case diagrams. You can now copy the file:// address of a local HTML file in the Integrated Browser, and the Welcome page shows a visible keyboard focus outline. Ctrl+Enter sends a message in the background, and you can rebind it.
• Metrics fix: Agent edit metrics in GitHub Copilot usage reporting no longer count unchanged text between edits as added or deleted code. If your dashboards showed suspiciously high agent output, this may be why.

Analysis​

Coverage at NT Compatible framed this release as a consolidation step rather than a single marquee feature, cementing VS Code's shift from editor into an agent orchestration platform. That's fair. Note how much of 1.146 is labeled Experimental or Preview, though. The one firm commitment is a removal date, and the new features arrive as opt-in previews.

For Windows organizations the release has two sides. On the plus side: managed sandbox policy, narrower default permissions, environment-variable masking and PAC/Kerberos proxy support. The cost is a migration deadline, and some Local-era workflows, like user-defined tool sets, won't come along. Three months isn't long for a large organization to retest its developer tooling.

What to do now: confirm you're on the Copilot harness, check your customizations against the transition guide, and turn on the narrower permission settings and secret masking before February 2027 arrives.