Skip to content
| Marketplace
Sign in
Visual Studio Code>SCM Providers>MultiReviewNew to Visual Studio Code? Get it now.
MultiReview

MultiReview

Minimal Effort Tech

|
1 install
| (0) | Free
Multi-project local code review for VS Code: per-project change trees, diffs against any base, out-of-tree comments, image annotation and a cross-repo date timeline.
Installation
Launch VS Code Quick Open (Ctrl+P), paste the following command, and press enter.
Copied to clipboard
More Info

MultiReview

Review changes across several git repositories at once, without leaving VS Code and without a pull request. MultiReview opens every project in the workspace as a section of one review sidebar - change trees with diff stats, branch and commit history, native diffs, and review comments that live outside the repositories so they can never be committed by accident. It is built for two jobs: diagnostics ("this worked Tuesday, what changed since - across all my repos?") and reviewing local AI-agent work (annotate an agent's working-tree changes like a PR, then export the verdict straight back into its next prompt). It only ever talks to local git: no forge APIs, no network.

Requires VS Code 1.106 or newer.


The review workbench: Changes, Comments and History in one sidebar, a diff, and an inline comment thread

Changes, Comments and History are three collapsible views in one column - the diff set, the notes on it, and where the code came from. Comments are written inline in the diff.

The Commit & Push panel: shared or per-project messages, per-project branch and push control

When the review is done, the Commit & Push panel closes the loop across every project at once - one shared message or one per project, and the per-project checkbox is the only granularity: a checked project is committed whole.

The Date Timeline: one shared date axis, a lane per project, commit dots, package diamonds and uncommitted rings

The cross-repo Date Timeline puts every open repository on one axis. Drag a range and the whole Changes view scopes to it; hollow rings are work that has not been committed yet.

Rendered review: Markdown with tinted changed blocks and an inline thread, images compared side by side

Markdown and images are reviewed as they render, not as text - hover any block for a + that files a normal comment on that block's source lines. The strip down the right edge marks every change and every thread at its share of the whole document.


What it does

  • Every project in one sidebar. Auto-expanded per-project trees with +/−, percent changed and status letters; collapse, filter, or hide generated churn with multireview.exclude (seeded with lockfiles, node_modules, build output).
  • Any base. Diff the working tree, a branch, a commit, or a date range. Renames are followed, so a moved file keeps its origin.
  • Comments that never touch the repo. Multi-range notes on any file - changed or not - stored in global storage, keyed per repository. Tick them off rather than delete them, so a round-by-round agent review keeps its record.
  • A review loop that closes. Ctrl+Alt+N marks the current file viewed and opens the next unviewed one; the activity-bar badge counts what is left and drains to zero; a review point marks "I have looked up to here".
  • Rendered review. Markdown and images open as they render. A slim overview ruler down the right edge of the Markdown panel marks added blocks, removed sections and every block carrying a comment, each at that block's share of the page - click it to jump there. Images gain arrow, text and freehand annotation, side-by-side and onion-skin compare.
  • Diagnostics timeline. Every repo on one date axis, with dependency changes as cross-project anchors and uncommitted work plotted at each file's save time. Scoping the review to a moment in history is one click, and so is coming back: click empty background, use the banner the Changes view puts up, or just hit Refresh.
  • Export. Markdown to file or clipboard, or Copy as AI Prompt - open comments as a ready-to-paste prompt with paths, line numbers, code excerpts and an instruction preamble you can customise.
  • Commit & Push. Commit across every project you reviewed, with per-project branch and push control. A checked project is staged whole (git add .) and the checkbox is the only granularity, so what lands is never a stale file list. Hooks always run; no force, rebase, reset or amend anywhere.
  • Store State. A commit-free copy of a project - gitignore respected, so no .pyc and no build output - kept outside the working tree, marked on the timeline, and restorable per file or whole (restoring stores the current state first). Works for folders that are not in git at all. A fallback for long-running agent runs: not version control, and not a reason to commit less often.

Quick start

Install the packaged extension:

code --install-extension multireview-<version>.vsix

Or run it from source:

npm install
npm run build
npm run demo     # optional: two throwaway repos + a workspace file to review them

Then press F5 for an Extension Development Host and click the MultiReview icon in the activity bar. npm run demo prints the path to a multi-root .code-workspace with both fixture repos in it, which is the fastest way to see a multi-project review with real history.

For developers

  • DEVELOPING.md - what the code does today: module map, data flow, storage layout, webview protocols, conventions and the test map.
  • DESIGN.md - why it is shaped this way: architecture, data model, UX and the requirement index R1–R23.
  • ADR-001 - the founding decisions as made at project start, and where the shipped product later diverged.
  • ADR-002 - stored states: why a fallback rather than version control, and why a folder with no repository may now be a project.
  • ADR-003 - the Markdown review's overview ruler: why a fixed overlay strip, why contributed opaque colours, and why paint is proved by a hit test rather than by a computed style.
  • TESTING.md - the manual regression checklist run before each release.

Gates: npm run build, npm run lint, npm run typecheck, npm run test:unit, and npm run test:integration (which needs a build first).

The overview images above are screenshots of the running extension, regenerated by npm run docs:images (scripts/capture-docs-images.mjs): it builds a throwaway two-project fixture, opens a real VS Code window on it with this extension loaded, drives each surface through the commands a reviewer uses, and captures over the Chrome DevTools Protocol at 2x in Dark Modern. They are PNG because vsce rejects SVG in a README.

Packaging

npm run package bumps the patch version on every build, so no two VSIX files ever share a version, and the current version is always the one in package.json. Pass an explicit version (npm run package -- 0.3.0) or --minor / --major for a release that is not a patch; an explicit version must be ahead of the one on disk. The built VSIX is written to the repository root and the superseded one is removed.

Pushing a vX.Y.Z tag whose version matches package.json runs .github/workflows/publish.yml, which re-runs the gates, packages the extension, publishes it to the Marketplace and cuts a GitHub Release with the VSIX attached.

License

MIT - see LICENSE.

  • Contact us
  • Jobs
  • Privacy
  • Manage cookies
  • Terms of use
  • Trademarks
© 2026 Microsoft