VS Code 1.136: Agent Merge and multi-root agent sessions

Visual Studio Code 1.136, released on September 2, 2026, focuses on finishing pull requests with agents and managing agent work across complex workspaces. The headline feature is Agent Merge in preview: it can work through review feedback, failed checks, and merge conflicts until a pull request is ready to merge. The release also adds experimental multi-root support for Copilot and Claude agent sessions, related chat hierarchies, and a redesigned session input.

For a production builder, the useful shift is not “let the agent merge everything.” It is giving an agent a narrower loop around an existing pull request: read the feedback, change the relevant files, run the checks, and present the next state for review. The official VS Code 1.136 release notes are the source for the release date, feature status, settings, and behavior described here.

What Agent Merge does in 1.136

Agent Merge is a preview feature for resolving review feedback, failed checks, and merge conflicts. Its target is the last mile of a pull request, where the implementation exists but the branch still has work before it can merge.

That target is valuable because the work is concrete. A reviewer may request a validation change, CI may report a failing test, or the branch may be behind its target and need conflict resolution. Each item can be represented as a checkable task rather than a broad instruction to “finish the PR.”

Use a request with explicit boundaries:

Review this pull request against the current comments and failed checks.

For each issue:
- identify the file and behavior involved
- explain the smallest safe change
- implement only issues supported by the review evidence
- run the focused check after each change
- do not merge or alter deployment configuration

Before stopping, show:
- changed files
- checks run and their exit status
- unresolved comments or conflicts
- any decision that still needs human review

The preview label matters. Treat Agent Merge as an assistant for a review loop, not as an approval authority. Branch protection, required checks, code ownership, and a human merge decision remain outside the model session.

The takeaway: Agent Merge is most useful when the pull request already has a visible definition of done.

How to turn review feedback into a bounded loop

Start with the pull request timeline, not the agent’s first interpretation. Separate comments into three classes:

1. Required change: the reviewer clearly asks for a behavior or code change.
2. Evidence request: the reviewer needs a test, log, screenshot, or explanation.
3. Decision: the reviewer is asking the owner to choose between valid approaches.

Only the first class should automatically become an edit. An evidence request may need a test run or a written reply. A decision should remain a human choice unless the repository already defines the rule.

A small issue record keeps the loop honest:

{
  "comment": "Reject duplicate payment events",
  "file": "server/events/payment.ts",
  "requiredBehavior": "replay does not create a second entitlement",
  "check": "payment-event-replay-test",
  "status": "open"
}

The agent can propose that structure in a scratch note or pull request comment. Your repository may use another format. The important fields are the requested behavior, the allowed area, and the check that proves the change.

After each edit, ask for the smallest relevant test. Do not wait until the end of a long Agent Merge session to discover that the first assumption was wrong. A focused check also makes a later conflict resolution easier to review because you know which behavior was already passing before the conflict.

The takeaway: review comments become safer work when every edit has a behavior and a check attached.

What multi-root agent sessions change

VS Code 1.136 adds experimental multi-root workspaces for Copilot and Claude agent sessions in the editor window Chat view. The relevant settings are:

chat.agentHost.copilotAgent.multiRootEnabled
chat.agentHost.claudeAgent.multiRootEnabled

Multi-root support is useful when one workspace contains related folders such as an application, a shared package, and deployment scripts. An agent can reason about the relationship between those folders without requiring you to open separate editor windows for each one.

There is an important scope boundary: the release notes state that agent hooks remain scoped to a single workspace folder. If hooks are detected in multiple folders, VS Code prompts you to select the primary folder from which to load them.

That means a multi-root workspace does not automatically create one shared policy surface. Decide which folder owns the hook configuration, and make the choice explicit in the repository documentation. If a check applies to every folder, run it from a higher-level CI or task entry point rather than assuming a folder-local hook will cover the entire workspace.

Before asking an agent to change a multi-root project, state the folder boundaries:

Workspace folders:
- apps/web: user-facing application
- packages/contracts: shared request and response types
- ops: deployment and environment configuration

Allowed changes:
- apps/web and packages/contracts
- do not edit ops without a separate review

After editing:
- run the focused application test
- run the contract typecheck
- report whether ops was read or changed

The takeaway: multi-root context helps the agent see relationships, but it does not remove ownership boundaries.

How chat sessions and side context help

The August release coverage described chat organization features such as related chat sessions and side conversations. Version 1.136 continues that direction with a session hierarchy that helps you organize related chats and see which ones need attention.

Use one primary session for the pull request and keep unrelated investigation elsewhere. A security question, a product decision, and a test failure may touch the same code but should not automatically share the same instruction history. A clean session boundary reduces the chance that an old assumption becomes an invisible requirement.

A practical naming pattern is:

PR-482 / implementation
PR-482 / review feedback
PR-482 / failing integration test
PR-482 / product decision: invoice state

The labels are for humans; the agent still needs the current repository state and explicit task. When moving between sessions, summarize the decision and link to the artifact that proves it. Do not paste an entire conversation into every new prompt.

The same rule applies to the new ability to navigate a workspace by project name. A convenient name is useful, but if multiple workspaces have the same name, the release notes say the agent reports possible matches instead of silently choosing one. Keep that behavior. Ambiguity is safer when it stops the operation than when it picks a plausible folder.

The takeaway: session organization is a control for context, not a replacement for a written task boundary.

How to use the integrated browser for UI feedback

The 1.136 release also adds an integrated browser workflow for agent-assisted page review. You can comment on several HTML elements and provide targeted UI feedback that the agent can address in a batch. Local HTML files can reload automatically when they change, and the integrated browser can be configured as their default editor.

For a UI review, describe the visual defect and the acceptance condition separately:

Review the checkout preview.

Feedback:
- the error message is below the fold on a narrow viewport
- the disabled button is difficult to distinguish from the background
- the summary column shifts when the error appears

Acceptance:
- error text is visible without scrolling after submit
- disabled state remains distinguishable
- summary position is stable in success and error states
- run the existing UI checks and report the viewport used

Selecting several elements is better than sending a vague “fix the layout” request because each comment maps to a visible target. Still, the agent needs a check for behavior that the browser cannot establish, such as form submission, authorization, or persistence.

Use AI app security checklist for the non-visual boundary around inputs, model calls, tools, database writes, and user-visible output. The browser can show that a button is present; it cannot prove that the action behind it is authorized.

The takeaway: visual feedback accelerates UI iteration when it is paired with functional checks.

How to review model and token usage

Version 1.136 adds token-usage visibility by model in chat. The response footer exposes input, cached input, and output token usage for each model in a chat turn. That gives a builder a better way to inspect the cost and context shape of a long agent session.

Use the data diagnostically:

Turn: review checkout PR
Input tokens: record from the session footer
Cached input: record from the session footer
Output tokens: record from the session footer
Files changed: count from the diff
Checks: command and exit status

Do not optimize for the smallest token count by removing the acceptance criteria. Compare useful output: valid changes, successful checks, review turnaround, and the number of corrective turns. A short response that misses the second workspace folder is not a saving.

LLM observability covers the broader production practice of connecting a request to model calls, tool calls, latency, cost, and the final outcome. Editor-level usage is one signal; application-level traces are needed once the feature runs for real users.

The takeaway: token visibility is useful when measured beside correctness and review effort.

What to adopt now and what to keep behind a gate

Adopt the workflow pieces that are already easy to make explicit: name the pull request, list allowed folders, turn review comments into bounded issues, run focused checks, and record unresolved decisions. Try Agent Merge and multi-root sessions in a non-critical branch first because both are marked preview or experimental in the release notes.

Keep these controls outside the agent:

• branch protection and required checks
• deployment approval
• secret access
• database writes with irreversible effects
• code ownership decisions
• production rollback authority

OTF’s paid full-stack kits fit this kind of workflow by shipping owned application code with CLAUDE.md, .cursorrules, and 20+ tested AI prompts. That gives an agent a known project contract to extend while the editor supplies review and session tools. Cursor agent best practices covers the complementary inspect-plan-edit-check loop, and web app template covers the repository foundation that should exist before an agent starts extending an app.

VS Code 1.136 is a useful release for teams moving from one-off agent prompts to managed work. Agent Merge addresses the review loop, multi-root sessions address related project folders, chat hierarchy addresses context, and browser feedback addresses UI iteration. Use each feature with a narrow task and a visible check. The result is not autonomous merging; it is a shorter path from an evidenced change to a human-approved pull request.

Sources

• Visual Studio Code 1.136 release notes — Microsoft

For an owned application foundation that an AI coding agent can extend, browse OTF templates.