Ahab

Posted on Sep 9 Originally published at indieseek.co

VS Code 1.136 Agent Merge PR Recovery Checklist

VS Code 1.136 Agent Merge: a safe PR recovery checklist for review, CI, and conflicts

Quick answer

VS Code 1.136 introduces Agent Merge in public preview. It can monitor the pull request attached to an agent session, ask the agent to address selected review feedback, fix failed required checks, update a branch that is behind, resolve merge conflicts, and optionally merge or enqueue the pull request after a fresh readiness check.

It does not replace human merge policy. Agent Merge starts agent turns, changes and syncs the PR branch, consumes model requests, and switches the session to Autopilot with Assisted permissions. Start with maintenance only: keep automatic merging at never, enable one blocker class at a time, and require human verification.

Who this is for

This checklist is for maintainers using pull requests from the VS Code Agents window, especially when a PR cycles through review comments, CI failures, and conflicts.

For merge-gate authority, use the separate Copilot code review approval checklist. This guide covers PR maintenance after feedback arrives.

What changed and what did not

VS Code 1.136 exposes Agent Merge through chat.agentMerge.enabled. Each maintenance action has its own control:

Setting	Default	Safe first rollout
`chat.agentMerge.addressReviews`	`true`	Allow only on routine, unambiguous feedback
`chat.agentMerge.fixCI`	`true`	Limit to required checks with reproducible local commands
`chat.agentMerge.resolveConflicts`	`true`	Require a post-resolution diff review
`chat.agentMerge.mergePullRequest`	`"never"`	Keep `never` until maintenance behavior is proven
`chat.agentMerge.mergeMethod`	`"auto"`	Pin a method if repository history requires it
`chat.agentMerge.replyAttribution`	`true`	Keep attribution visible

It waits for required checks, rechecks readiness before merge, turns off after a branch or PR switch, and does not support forks in the PR picker.

A maintenance-first rollout

1. Prove the session and pull request identity

Create the session from the PR in a local GitHub-backed workspace. Record its base branch, head branch, number, and current head SHA. The session uses an isolated Git worktree.

If the VS Code branch differs from the PR head, stop instead of asking the agent to infer around the mismatch.

2. Freeze the merge action

Leave chat.agentMerge.mergePullRequest at never. For the first canary, use a reversible PR with deterministic tests and no security-sensitive or schema-migration comments.

3. Classify each blocker before repair

Use a small ledger:

pr: 1842
head_sha_before: 9f3c...
blocker: required-ci | review-thread | behind-base | conflict
owner: agent | human | platform
verification: npm test -- workspace-name
stop_if: secret, permission, schema, flaky-infra, ambiguous-review

Agent-owned blockers need a local reproduction and objective exit condition. Product intent, security, migrations, access policy, and conflicting instructions remain human-owned. Runner outages and inaccessible reruns are platform-owned.

4. Let one repair cycle finish

Enable Agent Merge and note which blocker triggered the turn. A current VS Code issue reports that some users cannot rerun checks or resolve comments through the available gh CLI surface; hand off tool limitations instead of calling them fixed.

After each cycle, capture the head SHA. If it changed, rerun validation and review the complete diff.

5. Verify the terminal state

Use this acceptance matrix before declaring the PR ready:

Scenario	Required evidence
Review feedback addressed	The thread is resolved or the maintainer explicitly accepts the reply and diff
Required CI fixed	The required check is terminal and green on the current head SHA
Branch updated	The expected base commit is incorporated and the PR still targets the intended base
Conflict resolved	Conflict markers are gone, both sides' intent remains, and focused tests pass
Merge queue selected	The queue entry exists and repository rules still apply
Automatic merge selected later	A fresh readiness check occurs immediately before merge
Session switches branch or PR	Agent Merge disables and requires explicit re-enablement
Platform or permission limitation	The ledger records `blocked`; no success is claimed

Pending checks, green agent status, a new commit, or an unresolved automated reply are not terminal success.

6. Expand only after a bounded canary

Expand only after several low-risk PRs complete cleanly. Add one permission at a time: reviews, CI, then conflicts. Consider automatic merge only with a reliable audit trail.

Decision tree

Is the Agents window session attached to the intended open PR?
  no  -> stop and recreate or reattach the session
  yes -> is this a fork PR?
          yes -> use the normal GitHub workflow; the picker does not support it
          no  -> classify the blocker
                  human or platform owned -> hand off and record blocked
                  agent owned -> keep auto-merge=never and run one repair cycle
                                  head SHA changed?
                                    yes -> review full diff and rerun required validation
                                    no  -> verify whether the blocker actually changed
                                  all required checks terminal on current SHA?
                                    no  -> wait or hand off; do not claim ready
                                    yes -> human verifies readiness, then merge or enqueue

Common mistakes

Calling Agent Merge generally available when VS Code labels it Preview.
Enabling automatic merge in the same first canary as automated repair.
Treating a green session indicator as proof that every required check is terminal.
Letting the agent interpret security, permission, or schema feedback without a human owner.
Reviewing only the failing file instead of the complete diff after the head SHA changes.
Retrying platform-owned CI failures as if they were code defects.
Assuming a reply means the review thread was accepted and resolved.
Forgetting that branch or pull-request changes disable Agent Merge.

Building something? Turn your product page into a show people want to watch with PromoFast—hosted, embeddable, and ready to export.

FAQ

Does Agent Merge bypass branch protection?

It waits for required checks and rechecks readiness before merge. Keep repository rules authoritative and verify behavior in a disposable canary.

Should I turn on automatic merging?

Not initially. The default is never. First prove that repairs produce auditable diffs and terminal checks on the current head SHA.

What if the agent cannot rerun a check or resolve a comment?

Record the limitation and hand the blocker to a human or platform owner. Do not loop model requests or mark the PR ready merely because the agent attempted the action.

Sources

Originally published at IndieSeek.

DEV Community