Zed's multibuffers for cross-file refactoring: an underused power feature

Published 2026-03-03 by Owner

Zed has a feature called multibuffers — a virtual buffer that contains selections from many files. You can edit them as if they were one document; changes propagate back to the source files. The feature is extremely useful for cross-file refactoring and rarely advertised.

I learned about it from a YouTube comment three months ago. It’s now part of my daily workflow.

What multibuffers are

A regular buffer is one file. A multibuffer is a stitched-together view of multiple files (or multiple sections of one file). You see all the relevant code in one place. Edits in the multibuffer write back to the source.

The shape:

[multibuffer view]

src/auth/login.ts:42-58
[lines 42-58 of login.ts]

src/auth/logout.ts:31-44  
[lines 31-44 of logout.ts]

src/auth/middleware.ts:12-28
[lines 12-28 of middleware.ts]

You see three sections from three files in one editor view. You can use Zed’s normal editing commands across the multibuffer. Changes save to the original files.

How to create one

Several entry points:

From search results. Run a project-wide search (Cmd+Shift+F). Click “Open in Multibuffer” at the top. The search results become a multibuffer with each match in context.

From references. Right-click a symbol → “Find All References” → “Open in Multibuffer.” The references become a multibuffer.

From diagnostics. Click on the diagnostics panel → “Open in Multibuffer.” All your project’s errors and warnings appear with the relevant code in context.

Programmatically. Zed’s command palette has “New Multibuffer.” You can manually add file ranges.

Where this changes my workflow

Cross-file rename. When LSP rename can’t handle a case (string keys, generated code), the multibuffer of search results is the next best thing. I see all matches at once; I can edit consistently; saves all files.

Refactor across similar files. A pattern I want to update in 10 places. Open all the matches in a multibuffer; edit them all in one view; consistent results.

Understanding scattered code. Authentication logic spread across 5 files? Open all the relevant sections in a multibuffer; read them as one document; understand the flow without jumping.

Reviewing AI-generated changes. When the AI proposes changes across many files, I sometimes open the changed sections in a multibuffer to review them as one unit rather than file-by-file.

The AI angle

Zed’s assistant panel works against the active editor. When the active editor is a multibuffer, the AI sees all the code from all the files at once.

This is the underrated combination. Asking the AI “refactor this pattern” with a multibuffer of all matches loads exactly the relevant code. The AI’s suggestions cover all the matches consistently because it sees them all.

Without the multibuffer, you’d ask the AI per-file. Each request loads less context. The suggestions might diverge across files because the AI doesn’t see the consistency requirement.

A specific example: I had to update error handling across 12 service classes. Each had a similar try/catch pattern that needed updating. I:

Searched for the pattern
Opened search results in a multibuffer
Asked the assistant: “update each of these try/catch blocks to use the new ErrorReporter pattern. Keep the existing logic intact.”
The assistant produced a single coherent update covering all 12 files

The same task without multibuffers would have been 12 separate AI requests, each loading less context, each potentially producing slightly different patterns.

Limits

Multibuffers aren’t a silver bullet:

Performance. Multibuffers with hundreds of file ranges slow down. For massive search results, you’ll hit responsiveness issues. Trim to relevant ranges.

Context cost. When the AI sees a multibuffer, it loads all the file content. Large multibuffers cost more in tokens. Keep them focused.

Conflict detection. If you edit a file directly while it’s also in an open multibuffer, you can get into states where the views disagree. Zed handles this but the experience is sometimes confusing.

Save semantics. “Save” on a multibuffer saves all the underlying files. Be sure that’s what you want.

A specific multibuffer pattern

For a refactoring session, my pattern:

Identify the change I need to make
Search for the pattern that needs changing
Open all matches in a multibuffer
Read through to confirm the matches are correct
Either edit by hand (for consistent simple changes) or ask the assistant (for varied changes)
Review the final state in the multibuffer
Save (writes to all files)

The whole flow stays in one view. I don’t lose context jumping between files. The AI sees the full scope of the refactor.

For comparison, the same workflow in VS Code/Cursor:

Search shows results in a sidebar
Each result opens a separate editor when clicked
I jump between files
AI sees one file at a time
Mistakes from inconsistency are easier to make

The multibuffer is a different shape of UI primitive. Once you have it, you wonder why other editors don’t.

What this taught me about Zed

Multibuffers reveal something about Zed’s design philosophy. The team built a primitive (a buffer that contains selections from many files) and let it compose with everything else (the AI panel, search, diagnostics, save mechanics). The result is a feature that’s useful in many scenarios because the primitive is general.

Most editors don’t have this. They have specialized tools for each scenario — a search panel, a refactor wizard, a diff view. Each is purpose-built but doesn’t compose with the others. Zed’s multibuffer is the kind of primitive that emerges when you build the editor with composition in mind.

For new Zed users: take the time to learn multibuffers. The investment pays off across many scenarios. Once you’ve internalized the concept, you’ll find yourself reaching for it in places where you used to grind through file-by-file work.

For users of other editors: this is a feature worth wanting. Mention it to your editor’s team if you’re using a tool that doesn’t have it.