VS Code 1.142 puts agent collaboration on a board: Canvases preview, chats that move, and tighter enterprise controls

The headline: the editor is becoming the place where you manage agents

Microsoft promoted Visual Studio Code 1.142 to the Stable channel on October 14, 2026. The headline is not a smarter autocomplete or a new color scheme, but three interlocking changes: first, Canvases in preview — a shared interactive surface where you and an agent collaborate, instead of only exchanging chat messages; second, chats that can move — a conversation can move to another folder or into a new Git worktree without losing history; third, tighter enterprise controls — finer Copilot Agent Host policies, while the Windows Sandbox integration is retired and sandboxed command execution moves to Agent Host sessions. Any one of these looks like a routine update; together they point in one direction: VS Code is positioning itself as the workbench and control plane for agents, not a text editor with an AI plugin bolted on.

One boundary first, because a previously published article covers a similar-sounding feature: this is not Cursor's cloud-agent Canvas. Cursor's canvas is a shareable board a cloud agent produces when it finishes a task — the emphasis is on "handing in the work." VS Code 1.142's Canvases are a two-way interactive surface inside the local editor, beside chat, and the emphasis is on "working together while the work is in progress." Same word, different product logic: one is a finished deliverable, the other is a collaboration plane for work in flight. Conflating them understates what this release actually changes.

What Canvases are: not a board plugin, a two-way collaboration surface

In Microsoft's release-notes wording, Canvases are "interactive interfaces to collaborate with an agent": a canvas opens beside chat, where you and the agent inspect and update the same artifact instead of coordinating solely through prompts. The official example is a Kanban board: you create and move cards yourself, while the agent breaks a feature into tasks, updates their status, and adds work it discovers along the way. Both sides edit the same board, rather than each maintaining a separate plan and spending chat turns reconciling them.

The operative word is "two-way." Until now, agent work was mostly one-way output: the agent changed code and wrote summaries, you watched, and then asked for changes in chat. Canvases turn that into two-way manipulation: the interface itself is shared state, you move something, it moves something, state stays in sync. For vibe projects, this matters most in the most tedious part of task management — plans that always lag reality. The old pattern was: the agent claims "three items done," you open the files and find its three items are not your three items, and then you reconcile item by item in chat. With a shared canvas, the reconciliation medium changes from "chat history" to "which column the card is in" — and a card's column is much easier to verify than a sentence buried in a chat log.

Two implementation details matter. First, Canvases are a preview, available in the VS Code desktop app for local sessions using the Copilot harness, enabled with the chat.canvases.enabled setting — not yet on by default for everyone. Second, every canvas is supplied by a canvas extension: you can build your own with the /create-canvas command or install a chat plugin with a canvas extension through the GitHub Copilot app, and the Awesome Copilot community already has sample extensions. In other words, Canvases are better understood as a platform for collaboration interfaces than as a single board Microsoft hands you: the board is the first example, and issue-triage boards, release checklists, dashboards, and document workspaces are the other shapes named in the documentation. Judging it by the first board alone misses the point; the question is whether your team will build a canvas for its own process.

Chats that move: from "new folder, new conversation" to "take the history with you"

The second change sounds small and will be felt constantly: a chat session can now move to another folder or into a new Git worktree without losing history. The old flow was: discuss a problem in one folder, realize implementation belongs in a worktree, start a new conversation, and re-explain everything. In 1.142, you ask the agent in the Agents window to move the current chat, and the history comes along. The official example prompt is plain language: "Continue this task in a new Git worktree of the current repository before implementing it."

Why does this deserve its own section? Because it fixes a real break in agent workflows: discussion and implementation happen in different places. A typical vibe-project rhythm is "discuss on the main branch, implement on a feature branch," or "validate in an experiment folder, land in the real project." Every crossing of that break used to require rebuilding context — precisely the moment when agents are most likely to drop information or hallucinate. A chat that moves turns "discussion context" from a consumable into an asset you can carry. For solo developers, that means you can trust the "discuss first, implement later" rhythm more: discussion does not have to rush into implementation for fear of losing context, and implementation does not have to crowd into the discussion folder to preserve it.

Alongside movable chats, note the Agents window session-management improvements and the redesigned model picker. The new picker separates Copilot models and bring-your-own-key (BYOK) models into tabs and lets you tune thinking level and context window per model. On the surface that is interface tidying; underneath it is infrastructure for "many models, many sessions in parallel": when several agent sessions run at once on different models, you need to see at a glance which conversation uses which model and which harness — and new chat titles now show the active harness (Copilot or Codex) for exactly that reason.

Enterprise controls tighten: "allow assisted, block allow-all"

The third change is for enterprise admins, and it is the easiest for individual users to skip — yet it says the most about direction. The 1.142 Copilot Agent Host policies allow finer-grained permission configuration: one repeatedly cited example is permitting "Assisted" operations while blocking "Allow All," giving developers the convenience of approvals without letting them bypass checks. Permissions stop being an on/off switch and become a spectrum cut by operation level. For enterprises, that means agent autonomy can be opened gradually by team, project, and risk level, instead of choosing between "do not use" and "fully open."

In the same batch comes a retirement: the Windows Sandbox integration is deprecated. Microsoft's reasoning is that Windows Sandbox was built to isolate unfamiliar executables, not to govern autonomous agents with broad codebase access; policy-based controls that directly scope what an agent may do replace it. The practical effect: Windows users who relied on Windows Sandbox to isolate local agent sessions should move to sandboxed command execution inside Agent Host sessions. The direction matches Canvases and movable chats: all agent activity converges on the Agent Host runtime, rather than scattering across windows, sandboxes, and extensions.

For solo developers, enterprise controls sound remote, but the underlying idea translates directly: grade your agent's permissions. Many vibe-project incidents happen not because the agent is too weak but because it started with "allow all" — read every file, run every command, reach the network, change configuration — and one misoperation then does real damage. The 1.142 enterprise policy translates into a personal practice: give the agent minimum necessary permissions for routine tasks, temporarily widen them for sensitive operations, and narrow them again afterwards. Treat "Allow All" as an exception that needs a reason, not the default. Enterprises implement that with policy files; individuals implement it with habits and checklists. Same principle.

Smaller changes worth noticing: Markdown, Python, background shells

Version 1.142 also ships less headline-grabbing improvements you will meet daily. The Markdown editor is stronger, with outline and breadcrumb integration and a copy button on code blocks on hover — small seconds saved daily for anyone writing docs or agent instruction files in Markdown. On Python, the Python Environments extension fixes environment discovery, interpreter selection, and terminal activation, including uv-managed installations. Copilot sessions gain a "Background Shells" indicator listing running commands, with an option to stop just one of them instead of everything. The common thread is observability for long-running agent sessions: while working with an agent, you need to see what it is running in the background and stop one thing without stopping everything — not just see the final result.

Taken together, 1.142's portrait is complete: Microsoft is not adding features to an editor, it is filling in infrastructure for "life with agents inside the editor" — a collaboration surface (Canvases), session continuity (movable chats), control (Agent Host policies), observability (background shells, harness labels in chat titles). Infrastructure has a specific character: each item alone looks unexciting, but together they decide whether daily work with an agent feels smooth. For anyone deciding whether to upgrade, the test should not be "is there one feature that wows me" but "is my daily workflow blocked anywhere these pieces unblock" — if yes, the payoff is daily; if no, waiting for the next version costs nothing.

Canvases' limits: preview means do not treat it as a productivity promise yet

The limits deserve equal billing, or this becomes a re-read of the release notes. First, Canvases are a preview, limited to desktop, local sessions, and the Copilot harness — remote sessions, web, and other harnesses cannot open the same board yet, so a team split across remote and local development does not share one surface. Second, canvases depend on the extension ecosystem: the first board is a sample, and the triage board or release checklist you actually need must be built with /create-canvas or awaited from the community — building a good canvas is itself work, not something a toggle delivers. Third, shared state is not shared understanding: an agent moving a card does not mean it understands the business meaning behind the card; card states can align while the implementation still drifts. A canvas replaces the "plan alignment" step, not code review and testing.

A minimal trial checklist for the curious: first, enable chat.canvases.enabled and run one real small task end to end on the sample board — splitting, executing, and verifying a feature with the whole flow on the canvas — and check whether the agent's card operations match your expectations. Second, deliberately create a conflict: move a card yourself while the agent updates another, and observe how shared state resolves and who wins. Third, assess maintenance cost honestly: is this a board you will open daily, or a display nobody looks at after three days? If the latter, your process does not need a canvas yet; chat plus a task list is enough. A tool's value is not what it can do but what you will use daily, and previews especially reward that honesty.

Verdict: upgrade now, or wait

Upgrade now if you are in one of three groups: people who constantly switch folders and worktrees, for whom movable chats directly remove context-rebuilding time; teams already using Copilot agents who need to tell management what agents may and may not touch, for whom Agent Host policies supply a writable internal standard; and people curious about Canvases who will build a board for their own process, for whom entering during preview means knowing how to use it by the time it is on by default.

Waiting is fine for two groups: people whose workflow lives entirely in one folder on one model and who are happy with it — 1.142's infrastructure is "useful later," not "missing now"; and Windows users heavily dependent on Windows Sandbox isolation for agent sessions, who should first confirm their Agent Host migration path works before upgrading, rather than discovering on upgrade day that the isolation model changed. Whichever group you are in, one cheap precaution applies before any major editor upgrade: close out or record your running agent sessions first, because the continuity of a session across an editor upgrade is never guaranteed — closing out first is the cheapest insurance available.

A closing observation about direction. The cadence itself — VS Code 1.135 on August 26, 1.141 on October 7, 1.142 on October 14 — is a signal: the editor is moving at near-monthly speed, weekly on Insiders, toward an "agent-first workspace." Rivals Cursor, Windsurf, Zed, and JetBrains AI Assistant each play differently, but VS Code's play is clear: not a smarter model, but more complete agent infrastructure — collaboration surface, sessions, permissions, observability, one piece at a time. For vibe-project authors, that frames a choice: keep treating VS Code as "the place you write code, with an AI chat on the side," or start treating it as "the place you manage agents, with code as one of the things agents produce." Version 1.142 does not force the choice, but it paves the second road considerably flatter.