VS Code 1.142 Gives Agents a Canvas, and It Changes What Reviewing Means

First, separate preview from shipped

Canvases are in preview. The setting is chat.canvases.enabled, and the scope is the VS Code desktop app for local sessions using the Copilot harness. Canvas extensions are also supported in the GitHub Copilot app.

While it is in preview, put the setting in workspace settings rather than user settings, so one repository can opt in without changing every project you open.

What a canvas is, in the release notes' own words: an interactive interface to collaborate with an agent, opened beside chat, where you and the agent inspect and update the same artefact instead of coordinating only through prompts. That sentence is the feature. The rest is implementation.

Why that is not a nicer chat bubble: a transcript is a log of intent that decays, while a board is state. Agents are bad at maintaining state they can only describe, and humans are bad at reading state out of prose.

// Canvas is a preview, so turn it on deliberately rather than discovering it.
// From the 1.142 release notes:
//
//   setting: chat.canvases.enabled
//   scope:   VS Code desktop app, local sessions using the Copilot harness
//   also:    canvas extensions are supported in the GitHub Copilot app
//
// Put it in workspace settings, not user settings, while it is in preview.
// That way one repository can opt in without changing every project you open.

// .vscode/settings.json
{
  "chat.canvases.enabled": true
}

// What "canvas" actually means here, in the release notes' own words:
// an interactive interface to collaborate with an agent, opened beside chat,
// where you and the agent inspect and update the same artefact instead of
// coordinating only through prompts.
//
// That sentence is the whole feature. Everything else is implementation.
//
// The canonical example is a Kanban canvas: you move cards, the agent breaks a
// feature into tasks, updates status, and adds newly discovered work. Both of
// you are editing one board, in the same place, at the same time.
//
// Why this is different from a nicer chat bubble: a chat transcript is a log of
// intent that decays. A board is state. Agents are bad at maintaining state
// they can only describe, and humans are bad at reading state out of prose.

Building one: the question is not layout

Every canvas is supplied by a canvas extension. You either install one or create your own with /create-canvas inside the chat.

When you build one, the question worth answering is: what is the smallest thing both parties can act on? A canvas that only displays agent output is a renderer. A canvas both sides edit is a tool.

The structure I want is split by responsibility: mechanical checks where the machine decides and a human skims failures, behavioural evidence where the machine produces proof and a human confirms it exists, and judgement calls where the human decides and the agent records the decision and the rationale.

A good canvas makes that third section short and visible, because that is where a person is genuinely required — and it deserves the screen space chat currently spends re-explaining what it just did.

One property of the Kanban example is worth copying: the cards move. Movement is cheap to observe, so when the agent marks something done you can see that it happened without reading a paragraph about it happening.

// Every canvas is supplied by a canvas extension. Two ways in: install one, or
// create your own with /create-canvas in the chat.
//
// The interesting design question when you build one is not layout. It is:
// what is the smallest thing both parties can *act* on? A canvas that only
// displays agent output is a renderer. A canvas that both edit is a tool.

// Shape of a canvas definition (per the extension API surface referenced in the
// release notes; check the official docs for the current schema):
{
  "id": "review-checklist",
  "title": "Review checklist",
  "sections": [
    { "id": "mechanical",  "label": "Mechanical checks", "items": [] },
    { "id": "behavioural", "label": "Behavioural evidence", "items": [] },
    { "id": "judgement",   "label": "Judgement calls", "items": [] }
  ]
}

// The three sections are not decoration. They map to who is responsible:
//
//   mechanical   machine decides, human skims the failure
//   behavioural  machine produces evidence, human checks it exists
//   judgement    human decides, agent records the decision and rationale
//
// A good canvas makes the third section short and visible. That is the part of
// review where a person is actually necessary, so it deserves the screen real
// estate that chat currently spends on re-explaining what it just did.

// The Kanban example from the release notes is worth copying for one property:
// cards move. Movement is cheap to observe, so if the agent marks something
// done, you can see it happened without reading prose about it happening.

The quiet fix that saves more time than the canvas

Also in 1.142: chats move across folders and new Git worktrees without losing conversation history.

Why that matters more than it sounds. The standard way to review a generated change is to create a worktree, inspect the branch there, then return to your main checkout. Until now the chat belonged to one folder, so the context you had built lived on the wrong side of that boundary.

The workflow this unblocks: create the worktree, open that folder in the same window, move the existing chat into it, and keep the conversation instead of starting a new one that has no idea why you are there. Then move it again into a fresh worktree for the next task.

Two habits to pair with it. One worktree per task, named with a date, deleted after merge. And do not move a chat into a worktree you intend to discard silently, because the history travels with the chat rather than the folder.

The second-order effect is the real gain: a persistent chat plus disposable worktrees matches how agents actually work far better than a persistent folder plus a disposable conversation. One of those two things should survive a task, and 1.142 finally lets you pick the right one.

// The quiet fix in 1.142 that will save more time than the canvas:
// chats move across folders and Git worktrees without losing history.
//
// Why this matters more than it sounds. The standard workflow for reviewing a
// generated change is: create a worktree, look at the branch there, then go
// back to your main checkout. Until now the chat existed in one folder, so the
// context you built up lived on the wrong side of that boundary.

# The worktree workflow this unblocks
git worktree add ../review-$(date +%Y%m%d-%H%M) -b review/agent-change origin/agent-change
cd ../review-*

# Now: open that folder in the same window, move the existing chat to it, and
# keep the conversation instead of starting a new one that does not know why
# you are there. Then, for the next task, move it again into a fresh worktree.

# Two habits worth pairing with it:
#   1. one worktree per task, named with a date, deleted after merge
#   2. never move a chat into a worktree you intend to throw away silently,
#      because the history moves with the chat, not with the folder

git worktree list
git worktree prune

# The second-order effect is the important one: a persistent chat plus disposable
# worktrees is a much better match for how agents actually work than a persistent
# folder plus a disposable conversation. One of those two should survive a task.
# 1.142 lets you choose correctly, which was not previously possible.

Cards move. Movement is cheap to observe and hard to fake.

The enterprise controls decide whether this is adoptable

Admins can enforce agent sandboxing and permission policies, and control which permission modes developers are allowed to use. In plain terms: the organisation sets the ceiling and an individual cannot raise it. For a regulated team that is the difference between agents being unusable and agents being usable inside defined limits.

Three rules I would not ship an agent without.

Deny first, then allow. A default-allow terminal for an agent is a remote shell with extra steps. Start from nothing and add commands as they are needed.

Secrets need read protection, not just write protection. An agent that can read .env can put its contents into a diff.

Applied migrations are write-denied. That is the one class of change where "looks fine" and "is fine" diverge permanently.

Also note the redesigned model picker, which switches between Copilot and BYOK contributed models and manages effort levels and context windows. Enterprise policy, model choice and context budget form the triangle that decides what a session costs, and seeing all three in one place is unglamorous and extremely useful.

// The enterprise controls are the part that decides whether any of this is
// adoptable. Admins can enforce agent sandboxing and permission policies, and
// control which permission modes developers may use.
//
// Read that as: the organisation can set the ceiling, and an individual cannot
// raise it. For a regulated team this is the difference between "we cannot use
// agents" and "we can use agents inside these limits".

// Illustrative policy shape for an agent permission ceiling. Use the official
// policy names from Microsoft's documentation; the structure is the point here.
{
  "agent.permissions.allowedModes": ["readOnly", "workspaceWrite"],
  "agent.sandbox.enforced": true,
  "agent.sandbox.networkAccess": "deny",
  "agent.terminal.allowList": ["npm test", "npm run lint", "git status", "git diff"],
  "agent.terminal.denyList": ["git push", "npm publish", "curl", "ssh"],
  "agent.fileSystem.writeDeny": ["**/.env*", "**/secrets/**", "**/migrations/applied/**"]
}

// Three rules I would not ship an agent without:
//
// 1. Deny, then allow. A default-allow terminal for an agent is a remote shell
//    with extra steps. Start from nothing and add commands as they are needed.
// 2. Secrets are read-protected, not just write-protected. An agent that can
//    read .env can put its contents in a diff.
// 3. Applied migrations are write-denied. It is the one class of change where
//    "looks fine" and "is fine" diverge permanently.
//
// Also note the redesigned model picker: it switches between Copilot and BYOK
// contributed models, and manages effort levels and context windows. Enterprise
// policy plus model choice plus context budget is the triangle that decides
// what an agent session costs. Being able to see all three in one place is
// boring and extremely useful.

A two-week rollout, and the one question to verify

Everything in 1.142 that is not preview, in the order I would adopt it. The Markdown editor improvements are discussed least and will be touched most: pasting images, renaming file links, breadcrumb navigation.

A reasonable two-week sequence. Day one, the Markdown improvements: zero risk, immediate benefit. Day two, moving chats across worktrees: this changes your review workflow. Day three, decide the shape of your enterprise policy even on a small team. Day five, enable chat.canvases.enabled in exactly one repository. Day ten, review whether the canvas replaced a meeting or a document; if it did not, turn it off, because an unused preview feature is technical debt.

The Copilot harness detail explains observed behaviour: sessions run through the Agent Host, so they can continue in the background and be reached from both the editor window and the Agents window. Microsoft says it is progressively rolling the Copilot harness out as the default for new sessions based on feedback, and that Ask has been reintroduced as a built-in read-only agent in that harness.

The one question I would verify before trusting a canvas workflow: when the agent moves a card to done, is there a diff and a test behind it? A board that is easy to update is also easy to update dishonestly. The canvas makes state visible. It does not make state true. Keep the mechanical gates and let the canvas carry judgement only.

// Everything in 1.142 that is not preview, plus the order I would adopt it in.
// The Markdown editor improvements are the least discussed and will be touched
// most: pasting images, renaming file links, breadcrumb navigation.
//
// A sensible two-week rollout:
#
//   day 1   Markdown editor improvements. Zero risk, immediately used.
//   day 2   Move chats across worktrees. Changes your review workflow.
//   day 3   Decide the enterprise policy shape, even on a small team.
//   day 5   Turn on chat.canvases.enabled in ONE repository.
//   day 10  Review whether the canvas replaced a meeting or a doc. If not,
//           turn it off. A preview feature nobody uses is technical debt.
//
// The Copilot harness detail is worth knowing because it explains behaviour:
// sessions run through the Agent Host, which lets them continue in the
// background and be reached from both the editor window and the Agents window.
// Microsoft says it is progressively rolling the Copilot harness out as the
// default for new sessions based on feedback, and that Ask has been
// reintroduced as a built-in read-only agent in that harness.

cat > .vscode/settings.json <<'JSON'
{
  "chat.canvases.enabled": true,
  "chat.defaultAgent": "ask"
}
JSON

// The one thing I would verify before trusting a canvas-based workflow:
// when the agent moves a card to done, is there a diff and a test behind it?
// A board that is easy to update is also easy to update dishonestly. The canvas
// makes state visible; it does not make state true. Keep the mechanical gates
// from the previous article and let the canvas carry only judgement.

The organisation sets the ceiling. Individuals cannot raise it.