Copilot Edits multi-file preview: the diff view most reviewers miss

Published 2026-05-11 by Owner

When Copilot Edits touches four files at once, there’s a moment between “Copilot finishes generating” and “the changes land in your editor” where the full diff sits in a review panel. Most people never stop there. The default UX has a large Apply All button at eye level, and a smaller Files changed path that requires one extra click. The result: reviewers apply edits they haven’t read, then undo the ones that break something.

The preview panel is not a minor feature. It’s the point in the loop where you can see cross-file inconsistency before it gets into your working tree.

This guide covers:

• How to open the preview (including the keyboard shortcut that isn’t labeled)
• What the preview lets you catch that post-apply review misses
• The selective apply workflow for accepting good files and re-prompting bad ones
• How Copilot’s preview compares to Cursor Composer’s
• The specific failure mode the preview was designed to catch

How to open the multi-file preview

Copilot Edits generates a response in the chat panel. At the bottom of that response, there’s a small toolbar with two distinct actions: Apply All (prominent) and a Files changed counter that functions as a clickable badge — for example, “4 files changed.”

Clicking the files badge — not Apply All — opens the preview panel. The keyboard shortcut when focus is inside the Edits panel is Cmd+Shift+I on macOS or Ctrl+Shift+I on Windows and Linux. The shortcut is not surfaced in the toolbar tooltip, which is why most users don’t know it exists.

The preview panel looks like a standard VS Code diff view. Left side: your current file content. Right side: the proposed change, with additions in green and removals in red.

What makes it distinct from a single-file diff is the left sidebar file list: every file Copilot touched appears there, with color indicators.

• A red dot next to a filename means deletions are present
• A green dot means additions
• Both dots together mean both types of changes

Clicking a filename in the sidebar updates the diff pane without closing and reopening the panel. The navigation is fast and doesn’t require scrolling.

That file list is the key difference from reviewing changes file-by-file after applying. When you apply first and review via git diff or the SCM panel, you’re still looking at files one at a time. The preview sidebar lets you jump between api/handler.ts and tests/handler.test.ts in the same session and check that what changed in one matches what changed in the other.

That cross-file comparison is the thing the post-apply flow can’t give you without extra navigation.

What the preview lets you spot before applying

Cross-file inconsistency is the class of error that single-file review misses. The preview gives you enough context to catch several patterns quickly.

Type signatures out of sync. If Copilot updated a function signature in lib/parser.ts and also updated a call site in api/routes.ts, the preview lets you check that the argument order and types match. Copilot occasionally produces the definition and the call site in slightly different order — especially with optional parameters. Both files look reasonable in isolation; the mismatch only appears when you compare them.

Test coverage gaps. If Copilot added a new code path in the implementation file, check whether the test file has a corresponding test. The preview lets you look at both files by clicking between them. If the implementation adds an error branch and the test file doesn’t, the absence is visible before you apply. After applying, you’d only catch this if TypeScript coverage reporting or your test suite was already configured to flag the branch.

Import changes that don’t ripple. Copilot sometimes renames an export in one file without updating all the import sites. Scanning through the file list in the preview surfaces “this export changed but this importer wasn’t included in the edit” faster than TypeScript errors after applying.

Inconsistent style across files. Copilot doesn’t always apply the same style uniformly across every file in a multi-file edit. One generated file might use async/await throughout; another in the same edit might use .then() chaining. Both work; mixing them in one commit is noise that future reviewers have to parse.

Here’s a concrete example. Say you prompted: “Add a validateSlug function to lib/validation.ts and use it in api/posts.ts and api/pages.ts.” Copilot generates changes across three files. In the preview:

lib/validation.ts   🟢  (new function added)
api/posts.ts        🟢  (import + call site added)
api/pages.ts        🟢  (import + call site added)

Opening lib/validation.ts in the preview shows the new function signature:

// lib/validation.ts — proposed addition
export function validateSlug(slug: string): boolean {
  return /^[a-z0-9-]+$/.test(slug);
}

Clicking api/posts.ts shows the import and call site. Clicking api/pages.ts shows the same pattern. If Copilot had gotten the import path wrong in one of the route files — say '../../lib/validation' instead of '../lib/validation' — the mismatch would show up here as a diff inconsistency, before you apply anything.

None of these require deep analysis. A 20-second pass per file in the preview catches the majority of issues before they reach your working tree.

The selective apply workflow

The preview panel has per-file controls. Each file in the sidebar has a checkbox. Unchecking a file excludes it from the apply operation. The flow:

1. Open the preview (Cmd+Shift+I)
2. Review each file in the sidebar
3. Uncheck any files that need more work
4. Click Apply — only checked files are written to disk
5. Switch back to the Edits chat and add a follow-up prompt scoped to the excluded file

That follow-up in step 5 should be narrow. Something like: “The handler implementation looks right, but the test file needs to cover the new error branch. Only edit tests/handler.test.ts.” The scope constraint prevents Copilot from re-touching files you already accepted.

This pattern is faster than applying everything and then undoing the problematic file. Undo works in simple cases, but it’s a linear rollback. If the bad file had previous changes interleaved with the Copilot changes, a single undo step rolls back more than you want. The selective apply path avoids the rollback entirely.

The narrower re-prompt also tends to produce a better result than the original broad prompt did. Copilot has fewer degrees of freedom when the target is a single file with explicit instructions about what to add. The original prompt might have said “update the handler and add tests”; the re-prompt says “add a test for the error branch in the handler function we already updated.” The second prompt is harder to misread.

One thing to watch: after selective apply, the Edits session still shows the original full-set response. If you re-apply that response without going through the preview again, the excluded files come back. It’s not a footgun because Apply All prompts for confirmation, but it’s worth knowing so you don’t accidentally redo the work you just excluded.

Cursor Composer comparison

Cursor Composer has the same pre-apply review stage. It’s worth understanding where the two implementations differ, because the differences affect which tool you reach for on a given task.

Cursor’s preview is more visual. File diffs render inline in the main editor area, with green and red highlighting filling the full viewport width. The change is immediately legible as a spatial pattern — you can see block structure, indentation, and relative line counts at a glance. Copilot’s preview is more text-dense, closer to a git diff aesthetic with a smaller preview pane.

The practical implication: Cursor’s layout makes it easier to scan diffs that involve significant code reorganization, where the visual shape of the block matters. Copilot’s layout is more compact and navigable with a keyboard when there are many files.

Both support per-file accept/reject. Cursor uses a per-file Accept button at the top of each diff; Copilot uses the checkbox model. Cursor’s approach is more explicit — once you click Accept for a file, that file is done and visually marked as resolved. Copilot’s checkbox model is more batch-oriented — uncheck what you don’t want, then apply the rest in one shot.

One gap where Copilot’s implementation is faster: Cursor Composer doesn’t show a file list sidebar by default. Diffs are stacked sequentially; finding a specific file means scrolling past already-reviewed diffs. With more than five or six files in scope, Copilot’s sidebar makes random-access review meaningfully faster. Click api/routes.ts, review it, click lib/parser.ts, review it — no scrolling required.

Summary of the comparison:

The honest answer is that neither tool’s preview is obviously superior. The difference that matters is whether the visual Cursor approach or the text-heavy Copilot approach fits how you think when reviewing code.

The failure mode the preview is there to catch

Copilot Edits occasionally makes logically correct changes in the wrong location. The clearest example: a utility function that belongs in src/lib/utils.ts gets inlined into src/components/Button.tsx instead. The code is correct. The function does what it should. But the location violates the project’s module structure, and now the same logic exists in two places if someone later adds it to utils properly.

This kind of error doesn’t fail the build. It doesn’t produce a type error. It slips through code review because the diff for Button.tsx looks reasonable in isolation — reviewer sees a new function, it makes sense given the component’s usage, approved. The reviewer doesn’t think to ask whether that function should have gone elsewhere.

The multi-file preview surfaces this because you see the complete set of touched files together. “Copilot touched Button.tsx and added a formatDate helper. Did it also touch utils.ts? No — utils.ts isn’t in the file list.” That absence is visible in the preview sidebar. It isn’t visible in the diff for Button.tsx alone.

The preview doesn’t catch this automatically. It requires asking a question that isn’t obvious: not “are these diffs correct?” but “is the set of changed files complete?” Looking at the sidebar file list and thinking for two seconds about what’s missing catches the wrong-location pattern more reliably than any automated check currently available in either Copilot or Cursor.

The habit worth building: before clicking Apply, spend five seconds on the file list with two questions.

First: is every file that should have changed represented? A missing file means Copilot left a call site unupdated or a test file untouched.

Second: is any file listed that shouldn’t have been touched? An unexpected file in the list means Copilot drifted outside the scope of the request — possibly touching a shared module that other features depend on.

Both questions take less than half a minute. The first catches missing changes; the second catches unintended scope creep.

Copilot Edits is a fast loop. The preview is the one moment in that loop where slowing down for thirty seconds gives you the full picture. Most of the time, the full picture confirms the edit is right. Occasionally, it shows you something worth fixing before it gets into your working tree.