Visual Studio Code 1.145, released by Microsoft on November 4, 2026, moves remote agent work closer to the local editor experience. The release adds remote application previews, remote canvases, mixed agent harnesses, cron-based local automations, chat display controls, attachment changes, MCP governance updates, file-exclusion exceptions, extension API work, and Local harness removals.

For CTOs and engineering leaders, the signal is clear: agent-first development is expanding beyond chat into remote execution, recurring automation, interactive interfaces, and policy-controlled tools. The opportunity is broader workflow coverage, but preview flags, sandbox dependencies, MCP precedence, and removed Local harness tools require deliberate validation before deployment.

1. VS Code 1.145 Ships Stable Builds

What it is

Microsoft lists downloads for Visual Studio Code 1.145.0 across Windows, macOS, and Linux on the release page. The available formats include x64 and Arm64 Windows builds, Universal, Intel, and Apple Silicon macOS builds, and common Linux packages.

This is a stable release, not an Insiders-only package.

Why it matters

Platform teams can begin controlled deployment using their existing editor distribution process. Preview and experimental labels still apply to individual capabilities, so installing the stable editor does not make every included feature production-ready.

Why this matters: Separate the editor upgrade decision from feature enablement. Deploy 1.145.0 through a pilot ring, then evaluate gated agent and governance features individually.

2. Remote Agent Browsing and Canvases

What it is

Microsoft says the integrated browser in the Agents window can now load pages through a remote agent host when workbench.browser.enableRemoteProxy is enabled. If an agent starts a development server on the remote machine, the developer can open that application inside the Agents window, inspect the result, and provide feedback without leaving the session.

Remote canvases build on the same connection. Enabling both chat.canvases.enabled and workbench.browser.enableRemoteProxy allows canvases hosted by a remote agent host to appear in VS Code.

Canvases can also be pinned to the left sidebar through the Add to Sidebar action. Microsoft labels remote browsing and remote canvases Preview, while sidebar pinning is Experimental.

Why it matters

Remote previews reduce the context switching that occurs when an agent changes code on another host but validation still happens through a separately configured browser. The routing change is also material: browser traffic can originate through the remote host rather than the developer workstation.

For regulated environments, that network distinction is non-negotiable. Your validation plan should confirm which host resolves destinations, what network resources become reachable, and whether remote application content is appropriate for display inside the Agents window.

Action: Test workbench.browser.enableRemoteProxy with representative SSH, WSL, and Dev Container workflows before enabling it broadly. Treat chat.canvases.enabled as a separate approval because canvases introduce interactive agent-provided interfaces.

3. Mixed Harnesses and the Copilot Transition

What it is

Nested sessions previously inherited the parent session’s harness. VS Code 1.145 can instead place chats using different harnesses inside one parent session when chat.agentHost.multipleChatProviders.enabled is enabled.

Microsoft gives the example of asking Claude to review a plan written in a Copilot chat or assigning the same task to Codex for a side-by-side result. Each chat keeps its own model, agent, permission levels, history, and selected harness when moved or forked.

The harness picker now identifies Copilot sessions, and Copilot harness sessions can continue in the background through the Agent Host. Microsoft also added a Local-to-Copilot harness transition guide covering customization compatibility, session continuity, organizational rollout, and verification.

Why it matters

Mixed harnesses make model comparison part of one working context rather than a set of disconnected sessions. This is not merely a UI convenience. It places provider selection, approval scope, and model behavior inside the same unit of work.

Organizations should decide whether side-by-side providers fit existing AI usage policies before enabling chat.agentHost.multipleChatProviders.enabled. A chat retains the permissions associated with its own harness, so reviewers must not assume that sibling chats share identical controls.

Why this matters: Harness migration is becoming an operating-model decision. Inventory Local harness customizations, validate Copilot harness compatibility, and confirm which alternative harnesses organizational policy permits.

4. Cron Schedules and Local Agent Automations

What it is

Local automations can now use a custom five-field cron expression when built-in schedule presets are not precise enough. Microsoft says the scheduling dialog validates the expression and describes the resulting schedule.

The feature applies only to local automations. Cron schedules are not available for cloud automations in this release.

VS Code 1.145 also lets a local automation use a custom agent from the selected workspace. Disabled automations move into a collapsed section so active schedules and run history remain prominent.

Why it matters

Cron expands automations from a preset-driven convenience into a more flexible recurring execution layer. That flexibility also creates operational questions about unattended agent activity, workspace state, credentials, and machine availability.

This is not a cloud scheduler. It is recurring work tied to a local Agent Host.

Action: Require ownership, an execution window, and a review procedure for every cron-based automation. Validate expressions in the editor, document the selected workspace agent, and confirm that the host will be available when the task is scheduled to run.

5. Working Sets and Required Sandboxing

What it is

Microsoft says the Experimental working set for Copilot harness sessions now opens files from WSL, Dev Containers, and SSH workspaces on the correct host. When parallel tool calls edit the same file, the working set tracks those changes and keeps inline review controls available after editing completes.

The release also improves the warning shown when an organization requires agent sandboxing but the machine cannot run it. The banner identifies why terminal commands are blocked, including a missing dependency, and directs the user toward troubleshooting.

Where supported by the account and organization, Microsoft suggests considering Experimental cloud sessions when local agent tools cannot run.

Why it matters

Correct host selection is essential when an editor window spans local and remote resources. Opening a file on the wrong side of that boundary can confuse review, obscure the origin of an edit, or direct remediation toward the wrong environment.

The sandbox warning is equally important because policy-required sandboxing fails closed. No compatible sandbox means blocked terminal commands, not silent execution without the required isolation.

Action: Add WSL, Dev Container, and SSH working-set scenarios to your agent acceptance tests. For managed sandboxing, document required dependencies and establish an escalation path for users who receive the blocking banner.

6. Chat Verbosity, Performance, and Attachments

What it is

The Experimental chat.persistentProgressVerbosity setting introduces three display modes:

  • Conversation: reasoning and tool calls appear in collapsed sections between response text.
  • Verbose: tool calls remain expanded without an internal scrolling limit on tool groups.
  • Compact: tool calls appear while running and then collapse into summary rows; this is the default.

Changing the mode affects presentation, not chat context or agent behavior. Users can switch modes without starting another session. The separate chat.progressBorder.enabled setting replaces the persistent progress indicator with an animated input border.

Microsoft also says long Copilot harness chats reopen more smoothly because VS Code reuses existing reasoning titles, renders restored terminal output when revealed, and reduces repeated progress updates and layout measurements.

The Experimental chat.inlineAttachments.enabled setting places attachment pills at the cursor. It is enabled by default in Insiders and disabled by default in Stable.

Why it matters

Verbosity is an observability control, not a capability control. Verbose mode can support troubleshooting and review, while Conversation mode reduces visual load for routine work.

Lazy rendering should make long sessions easier to reopen, but it does not reduce the importance of session governance or review. Meanwhile, inline attachments preserve the relationship between an instruction and its referenced context, which can reduce ambiguity in complex prompts.

Action: Standardize a recommended view mode by scenario. Use Compact or Conversation for routine work and Verbose when reviewing tool behavior, permissions, or unexpected outcomes.

7. External Attachments and Session Access

What it is

Users can now select Add Context and then Files to attach one or more files through the standard system dialog, including files outside the active workspace. This also works in a new chat without an open workspace.

Microsoft says cloud-session file choosers list only images. In sandboxed Copilot harness sessions, an attached path becomes readable for the rest of that session but remains non-writable, and the access is not saved to settings.

Under Manual permissions, the agent no longer asks before reading an explicitly attached file. If enterprise-managed settings define readable paths, attachments do not add themselves to that managed list.

Why it matters

The file dialog makes external context easier to add, but it also lowers the friction between desktop files and an agent session. The important boundary is explicit attachment: the selected path becomes readable during that session even when it sits outside the workspace.

This is session-scoped access, not a permanent policy change.

Action: Train users to treat attachment as a disclosure decision. Managed environments should test how external attachments interact with sandboxing, Manual permissions, cloud-session image limits, and enterprise readable-path controls.

8. MCP Apps and Enterprise Allowlist Precedence

What it is

MCP apps can now register tools that the language model can call in its next request. Microsoft uses a ShaderToy server as an example of an MCP app that lets the model iterate on shaders through an interactive interface.

For MCP servers started by VS Code, the enterprise-managed allowedMcpServers list now takes precedence over registry-only access. A server matching the managed list can run even when it is not published in the registry, while a registry server absent from the list is blocked.

Microsoft specifies several boundaries:

  • Empty list: [] blocks all MCP servers.
  • Absent list: registry-only restrictions apply as before.
  • User and workspace policy: these scopes cannot add servers to the enterprise list.
  • Denials: deniedMcpServers and disabling MCP still take precedence.
  • Scope: the change applies to servers started by VS Code, not servers managed by the Agent Host.
  • Matching: Microsoft recommends serverUrl and serverCommand rules over serverName.

Why it matters

MCP apps now combine interactive interfaces with callable tools. That expands what an approved server can expose to the model, so server approval effectively becomes tool approval.

The allowlist precedence change is the more immediate administrative issue. A managed list is now the authoritative set for VS Code-started servers, even when registry-only policy is also active.

Action: Re-evaluate allowedMcpServers before deploying 1.145. Confirm that every approved serverUrl and serverCommand is intentional, remove stale entries, and test that an empty list produces the expected block-all posture.

9. File Exclusions, Mermaid, and Required Plugins

What it is

The files.exclude and search.exclude settings now support exceptions prefixed with !. For example, a workspace can exclude node_modules while retaining visibility for !node_modules/@types.

Exceptions in files.exclude affect Explorer, Search, and Quick Open. Exceptions in search.exclude apply only to Search and Quick Open. Microsoft warns that broad patterns such as !**/node_modules/@types can make searches slower.

Mermaid rendering also changes in 1.145. Subgraph titles move when an edge would cross them, and the default VS Code Mermaid theme outlines subgraphs instead of filling them.

For agent plugins required through the managed enabledPlugins setting, VS Code now disables the Uninstall action. The restriction also applies to contributed prompts, skills, agents, hooks, and MCP servers, with an explanation available through hover and keyboard focus.

Why it matters

Exclusion exceptions solve a common workspace problem: hiding a large generated or dependency tree while retaining a specific portion that developers need to inspect. The performance warning means teams should prefer narrow patterns over depth-wide exceptions.

Required-plugin behavior now matches organizational intent. Users no longer encounter an uninstall action that can only fail.

Action: Review shared files.exclude and search.exclude configurations for broad negation patterns. For managed plugins, verify enabledPlugins entries and document why each required customization remains installed.

10. Pull Requests and the Finalized Timeline API

What it is

Version 0.176.0 of the GitHub Pull Requests extension expands the pull request overview timeline. Microsoft lists label, milestone, title, review request, review dismissal, draft, ready-for-review, force-push, branch-restore, auto-merge, and merge-queue events among the additions.

Pull request description templates can now use ${issueTitle}, ${issueNumber}, and ${issueNumberLabel} when the branch is associated with an issue through Start Working on Issue. Stacked pull request workflows also prompt users to disable auto-merge on a pull request in the stack when it is enabled.

Separately, Microsoft finalized the Timeline API. Marketplace extensions can register file and folder providers with workspace.registerTimelineProvider or workspace-wide providers with workspace.registerWorkspaceTimelineProvider. Setting TimelineItem.resourceUri to the resource state represented by an entry enables comparison through Compare Selected.

Why it matters

The extension update exposes more of the pull request lifecycle inside the editor, reducing the chance that reviewers miss state changes outside the code diff. Template variables can also improve consistency when branches originate from tracked issues.

The finalized Timeline API gives extension authors a stable integration point for domain-specific history. This is useful for audit, comparison, and change-explanation workflows, but extension teams should set their minimum VS Code compatibility deliberately.

Action: Update the GitHub Pull Requests extension to 0.176.0 in a test ring and review templates that can use the new issue variables. Extension owners should evaluate whether Timeline providers can replace proprietary history views.

11. Local Harness Tools Removed

What it is

Microsoft removed several tools and commands from Local harness sessions:

  • Extension installation: #installExtension is no longer available. Agents instead add required extensions to .vscode/extensions.json for user review and installation.
  • Command execution: #runCommand is no longer available. Built-in workflows now ask users to run required commands, such as Developer: Chat Diagnostics, themselves.
  • Workspace creation: #newWorkspace, its previous name #new, and the /new command are removed.
  • Project setup: the Generate New Workspace link and dedicated project-setup skills are removed.

Microsoft also removed github.copilot.chat.newWorkspaceCreation.enabled, github.copilot.chat.newWorkspace.useContext7, and github.copilot.chat.useProjectTemplates. Notebook creation is unchanged.

To create a project, users now open an empty folder and describe the project in an agent session. The agent uses standard tools to create files, run scaffolding commands, and configure tasks.

Why it matters

Custom agents and prompt files that reference the removed identifiers will no longer work as designed. These are migration tasks, not optional cleanup.

The extension change also restores a review point: agents recommend project extensions through .vscode/extensions.json rather than installing them directly. Removing #runCommand similarly shifts command invocation back to the user.

Action: Search custom agents, prompt files, workspace templates, and internal documentation for #installExtension, #runCommand, #newWorkspace, #new, /new, project-setup-info-local, and project-setup-info-context7. Remove or replace every reference before standardizing on 1.145.

12. Reliability Fixes and Policy Persistence

What it is

Microsoft identifies two policy-related fixes with direct enterprise relevance.

Issue #345207 affected users whose organizations disabled the Claude or Codex agent after those users had selected it. New Chat, New Chat Editor, and new windows could open a read-only chat with no input. VS Code 1.145 now falls back to the default harness and carries over an unsent prompt; the previous choice becomes available again if policy permits it later.

Issue #344895 affected registry-only MCP access when a GitHub Copilot policy refresh failed because of a network error or rate limiting. VS Code now retains the last known registry policy and clears it only when GitHub reports that no registry applies.

The release also includes fixes for terminal auto-reply memory use in PR #336022, task readiness races in PR #342418, remote port rule handling in PRs #344185 and #344764, and Server-Sent Events byte-order-mark handling in PR #344094.

Why it matters

The MCP fix closes a fail-open interval in which a transient refresh failure could remove the registry restriction until the next successful update. Retaining the last known policy is the correct enterprise posture.

The disabled-agent fallback also reduces a deployment hazard when administrators change harness availability. Users receive a working default rather than a stranded read-only session.

Action: Include failed policy refreshes and disabled-agent transitions in your rollout tests. Verify that registry controls persist through simulated connectivity loss and that new chats fall back to the organization’s permitted default harness.

13. Blobby Jump Game

What it is

Microsoft included an Experimental platform-jumping game featuring Blobby, the VS Code pet. Entering /vscode-pet in chat displays Blobby, and the new-session screen in the Agents window provides a Play Jump Game action.

The spacebar charges a jump, arrow keys aim toward the next platform, and the game stores a high score on the device.

Why it matters

The game has no material enterprise workflow implication. It is optional and Experimental.

For managed environments, it belongs in release awareness rather than rollout planning. Teams should focus validation effort on remote routing, agent permissions, automation, attachments, and MCP policy.

The Bottom Line

VS Code 1.145 expands the Agents window into a control surface for remote previews, canvases, provider-specific chats, recurring local tasks, and MCP-backed tools. Agent-first is not a trend here; it is the direction of the editor’s workflow design.

  1. Pilot remote routing first. Validate workbench.browser.enableRemoteProxy and chat.canvases.enabled against representative hosts and network boundaries.
  2. Govern recurring execution. Treat five-field cron automations as unattended local workloads with named owners and review procedures.
  3. Reconcile MCP policy. Audit allowedMcpServers, deniedMcpServers, registry restrictions, and the distinction between VS Code-started and Agent Host-managed servers.
  4. Migrate Local harness customizations. Remove references to tools, commands, skills, and settings deleted in 1.145.
  5. Test failure states. Confirm required sandbox behavior, policy persistence, disabled-harness fallback, and attachment access before broad deployment.

Happy Coding!