CodePeel VS Code Extension: Inline Review Walkthrough

The CodePeel VS Code extension moves the review to the moment before you push: you select what counts as "the change," send it for review, and read the findings as diagnostics, inline comments, and a findings tree inside your editor — then apply or delegate fixes without opening GitHub. This walkthrough follows one review cycle end to end, with the mechanics of each step: how the diff is assembled, what the review request contains, how findings are rendered, and what happens when you click a fix.

Install and sign in

Install CodePeel from the VS Code Marketplace (extension ID codepeel.codepeel-vscode), or sideload a .vsix if you prefer. The extension contributes a sidebar view, a set of commands, code actions, and context-menu entries.

Signing in happens once: authenticate through the browser flow (or paste an API token if your setup prefers static credentials). The session is stored locally and refreshed automatically; sign-out from the sidebar clears it. Your plan's review allowance is shared across GitHub, editor, and MCP reviews — the sidebar shows your remaining balance so a review never surprises you at the quota wall.

Choosing what gets reviewed: the four diff modes

Everything starts with a unified diff. The extension builds it locally with git, and the mode you pick determines the commands used:

The working-changes mode is the closest approximation of "what a PR would see": it concatenates the branch diff with your uncommitted work, so a review catches the whole change set, not just today's edits. The comparison branch is detected from your repository (with a manual override in the sidebar when you want to compare against something other than the default).

Diffs are capped at 500 KB before upload; anything larger is truncated and marked, so you always know when a review covered only part of the change. For very large branch diffs, reviewing in staged or uncommitted slices is usually more useful than one truncated pass.

Running the review

Click Review in the sidebar. The extension posts the assembled diff to CodePeel's review endpoint (the URL is a user-configurable setting, which matters if your team routes requests through a proxy). The response is a structured findings list — each finding carries a file, a line in the new file, a severity, a category, an explanation, and, when one exists, a problemCode/fixCode pair showing the exact replacement.

While the review runs, the sidebar streams progress and lets you stop it mid-flight. Completed reviews are kept in a local history, so yesterday's findings stay inspectable after you have pushed.

The review that answers is the same engine a pull-request review uses — deterministic checks first, then the model analysis — so editor findings and PR findings agree in kind, differing only in context (the PR has conversation and CI context; the editor has your exact diff). For what the security layer of that engine looks like, see How CodePeel's OWASP Security Scanning Works.

Where findings appear

Findings render in three coordinated places:

• Problems panel and editor squiggles. Each finding becomes a VS Code diagnostic on the exact line. Severity maps directly: critical → Error, high → Warning, medium → Information, low → Hint. Filtering the Problems panel by severity therefore filters the review.
• Findings tree. The sidebar groups findings by file with severity badges; selecting one opens the file at the reported line.
• Inline comments. Findings can be pinned as threaded comments on the line, with the explanation, the problematic code, and the suggested fix visible in context.

One detail that saves real time: stale-finding detection. After you edit code, the extension re-checks whether each finding still applies to the current text and marks the ones whose anchor has drifted, so you are not chasing diagnostics that describe code you already changed.

Acting on a finding

Each finding offers up to four actions:

• Apply Suggested Fix — writes the fixCode snippet into the file directly. This is a plain local edit: saved to your working tree, reviewable in the diff, undoable with Cmd/Ctrl+Z.
• Fix with AI — routes the finding to an AI coding agent installed in your editor (Claude Code, Copilot, and other supported agents are detected automatically). The extension hands the agent a structured prompt: the file, the issue description, the problematic code, and the target line — so the agent fixes with full editor context rather than a bare snippet.
• Fix All Issues — iterates the fixable findings in bulk instead of one at a time.
• Copy Suggestion — puts the suggested code on your clipboard for manual placement.

Quick fixes also surface through the standard code-action lightbulb on diagnostic lines, and right-clicking a selection offers a review action — the extension deliberately meets you inside the editor's existing muscle memory instead of adding a parallel UI.

A full cycle, concretely

Say you have just written a new endpoint and have not committed anything:

1. You pick Uncommitted and click Review — the extension diffs working tree plus index and posts it.
2. The review returns a critical security finding at line 42: user input concatenated into a SQL string, with a parameterized query as the suggested fix — the same class of issue described in the security scanning article.
3. The line shows a red squiggle; the Problems panel lists it; an inline comment shows the vulnerable code and the fix side by side.
4. You click Apply Suggested Fix. The file now contains the parameterized query; the diagnostic clears on the next pass because the text no longer matches the finding.
5. You re-run the uncommitted review. The security finding is gone; one medium-severity bug remains, which you route to Fix with AI to clean up in context.
6. You commit, push, and open the PR. The PR review now starts from a diff where the obvious issues are already fixed — and the pre-merge quality gates enforce the rest before merge.

That last step is the point of the editor workflow: by the time a pull request opens, the review conversation is about architecture and trade-offs, not about a missing null check.

Configuration and tips

The extension honors your repository's CodePeel configuration (including expert rules and learnings), so custom patterns enforced on your PRs are enforced here too. A few habits that make editor reviews more useful:

• Review in slices on big changes — staged and uncommitted reviews give precise, untruncated feedback where a whole-branch diff might hit the size cap.
• Set the comparison branch explicitly when working against something other than the default, so the working-changes mode computes the base diff you actually mean.
• Use review history to re-read findings after a push — the same results stay available locally.
• Prefer Apply for mechanical fixes, Fix with AI for contextual ones. A parameterized query applies verbatim; a refactor that touches three regions of a file benefits from an agent with the whole buffer.

For installation details, settings, and agent-integration specifics, see the VS Code extension documentation. To review straight from an agent without the editor, the MCP server walkthrough covers that surface; for the pipeline that turns remaining findings into a fix PR on GitHub, see How Auto-Fix PR Generation Works End to End.