Claude Code in VS Code and JetBrains: when the IDE extension wins and when the terminal does

Published 2026-05-11 by Owner

You open a terminal, run claude, and Claude Code starts editing files. It works. But then you install the VS Code extension, and suddenly there’s a diff viewer, a sidebar panel, a separate review flow. Two surfaces, same tool. The question worth answering is: which one should you actually be using, and when does it matter?

The answer isn’t “always use the terminal” or “always use the IDE extension.” It’s that the two surfaces are genuinely different in their ergonomics, and using the right one for the task at hand reduces friction in ways you notice immediately.

What each integration is actually for

The terminal CLI is the original surface. You run claude in a directory, give it a task, and it runs autonomously — reading files, editing, running commands. It doesn’t care about your editor. It works over SSH. It works in CI. It works in a tmux session while your IDE is open to something else entirely. The terminal is best when you want to hand off a task and not watch it.

The VS Code extension adds a diff viewer to that loop. When Claude proposes an edit, you see it as a side-by-side diff inside the editor, with inline accept/reject controls, before the change is written to disk. The review flow is visual and quick. It also gives you a sidebar chat panel so you don’t have to leave VS Code to talk to Claude. The extension is best when you’re the one deciding which proposed edits land.

The JetBrains plugin follows the same idea but is tuned for JetBrains’ diff tooling, which is generally richer than VS Code’s for viewing multi-file changes. If you’re on IntelliJ, Rider, or PyCharm and your workflow involves reviewing changes across several files in the same review pass, the JetBrains diff UI handles that more comfortably than VS Code’s file-by-file approach.

The broad split:

The terminal is author-oriented (Claude produces, you accept later). Both IDE extensions are review-oriented (you see each diff before committing). JetBrains adds better multi-file diff navigation and working-copy awareness on top of that.

Install and connect

VS Code extension:

Search “Claude Code” in the VS Code Extensions marketplace. The publisher is Anthropic. Install, then open the sidebar panel (the Claude icon in the activity bar). It connects to the same underlying claude binary; if you have Claude Code installed via npm install -g @anthropic-ai/claude-code or via the standalone installer, the extension finds it automatically. If the extension can’t locate the binary, it will prompt you to install it.

Once connected, you can start a conversation from the sidebar or use the command palette (Cmd+Shift+P → “Claude Code: Open Chat”). The diff viewer activates automatically when Claude proposes file changes.

One thing worth noting: the extension inherits your terminal’s claude authentication state. If you’re already logged in from the CLI, there’s nothing extra to do. If you’re starting fresh, the extension will open a browser OAuth window to authenticate through Anthropic’s console. After that, the session is shared across CLI and extension.

JetBrains plugin:

Open Settings → Plugins → Marketplace, search “Claude Code,” install the Anthropic plugin. After restarting the IDE, a Claude Code tool window appears in the bottom panel. Authentication shares the same mechanism as the CLI — if you’re already authenticated via the terminal, the plugin inherits that session. If not, it walks you through the same OAuth flow.

JetBrains users sometimes hit an issue where the plugin shows “connecting” indefinitely. The usual fix: make sure the claude binary is on your system $PATH and not just available in your shell profile (JetBrains launchers don’t always load shell profiles). Running which claude from a non-interactive shell is a reasonable check.

For both IDE integrations, the underlying model, API access, and billing are identical to the CLI. The extensions are presentation layers, not separate products.

The diff viewer and how it changes your review behavior

This is the part that actually changes your workflow, and it’s worth understanding what changes.

In pure terminal mode, Claude edits files and you find out by looking at git diff after the fact. If you’re watching the terminal, you’ll see filenames scroll by. But you’re not approving individual edits — you’re approving the overall task outcome.

With the VS Code extension’s diff viewer, each proposed file change appears as a visual diff before it’s applied. You can accept the whole change, reject it, or — and this is the useful part — accept it partially by editing the proposed content in the diff view. The loop becomes:

1. Claude proposes a change to foo.ts
2. The diff viewer opens inline in your editor
3. You read the proposed change in context
4. Accept, reject, or directly edit the proposed text before accepting
5. Claude moves to the next file

For code review use cases — where someone else will see your commits and you care about what exactly lands — this is significantly better than reviewing a git diff after the fact. You catch problems before they’re written to disk rather than after.

The ability to edit the proposed text inside the diff view is underused. I’ve started treating it as a way to make small corrections without breaking the Claude loop entirely — accept 90% of the edit, tweak a variable name, move on. Without the diff viewer, the alternative is to accept Claude’s full edit and then make a follow-up manual edit, which is more context switches.

The tradeoff: this mode is slower. You’re in the loop for every file. For a task that touches 30 files, that’s 30 review stops. If the task is well-defined and you trust Claude’s judgment on it, the terminal’s hands-off mode finishes faster.

When the IDE extension feels worse than the CLI

There are real cases where the extension is the wrong tool:

Long autonomous loops with many files. If you’re asking Claude to refactor a module that touches 15 files, the diff viewer becomes a queue of 15 approvals. This is the right model when each edit needs human review. It’s the wrong model when you’ve given Claude a well-scoped task and you just want it done. Use the terminal for the latter; switch to the extension for the review pass afterward using git diff.

Monorepo navigation across packages. Claude Code navigates the filesystem as a whole, but the VS Code extension’s diff viewer presents changes in terms of files open in the current workspace. If your task spans packages in different workspace roots, the diff viewer gets confused about context — changes in packages/api/ and packages/web/ may be shown without the surrounding file context that makes the edit legible. The terminal doesn’t have this problem because it’s just operating on the filesystem.

This is the case where I most strongly prefer the terminal. Open the VS Code extension with a monorepo task that touches 4 different packages and you’ll spend half the review session clicking through files without understanding their relationship. The terminal lets Claude work the filesystem cleanly; I’ll review the changeset with git diff --stat to get the scope, then git diff file by file if needed.

Multi-file refactors that revisit the same file multiple times. Claude sometimes edits a file, then comes back to it two turns later to add something it missed. The diff viewer shows each pass as a separate review event, which means you review the same file twice. In the terminal, you just see the final state in git diff. This isn’t the extension’s fault — it’s faithfully showing you what’s happening — but it can feel like unnecessary overhead on long refactors with iteration.

Anything where you want Claude running in the background. The extension’s diff viewer is a blocking UI. If you’re writing something else in VS Code and Claude is working on a background task, the diff notifications interrupt your flow. For background tasks, run the CLI in a separate terminal.

Context window exhaustion in the sidebar. For very long sessions, the VS Code sidebar chat accumulates context and can hit the model’s limit mid-task. The CLI handles this slightly more gracefully — it’s easier to start a fresh claude session in the terminal and pass it the current state of git diff as context than to manage a long conversation thread in the sidebar. Not a dealbreaker, but worth knowing if you run long exploratory sessions.

A workflow that uses both at once

The pattern worth having in your toolkit: CLI for autonomous execution, IDE extension for human review.

Start a task in the terminal. Let it run without watching it:

claude "refactor the payment module to use the new Stripe SDK — see STRIPE_MIGRATION.md for the target API"

Let it run. When it finishes (or when you check back), you have options:

• Use git diff --stat to see the scope of changes
• Use git diff directly to review the whole diff at once
• Open VS Code and let the extension walk you through each changed file with the diff viewer

The last option is the most structured, but it’s also the slowest. Pick based on how much you trust the task scope. A tightly-constrained task (“update this one API client”) probably doesn’t need the full diff viewer walk-through. A task that touched 8 files in ways you didn’t fully anticipate probably does.

The point is that the autonomous loop ran without interruptions, and you review the output as a batch rather than file-by-file.

This separation is useful because it respects what each surface is good at. The terminal is good at unsupervised execution. The IDE extension is good at structured human review. They don’t have to be the same session.

Another variant of this: use the CLI in --print mode (which prints a plan without executing) to get a sense of what Claude intends to do before committing to a full autonomous run. Then if the plan looks right, run it properly and use the extension for review. This is roughly the same idea as Cline’s Plan/Act split, but assembled manually from two surfaces.

For shorter tasks where you want to stay in the loop — “add error handling to this function,” “write a test for this edge case” — start the conversation in the VS Code sidebar and let the diff viewer show you each edit. Fast, surgical tasks benefit from the immediate review cycle; the overhead is proportional to the task size.

A rough heuristic I’ve settled on: if the task touches more than 5 files, use the terminal for execution and review with git diff afterward. If it touches 1–5 files, stay in the IDE extension and review each change inline. The boundary is fuzzy but the idea holds up.

One thing I got wrong early

I assumed the JetBrains plugin was just a port of the VS Code extension with a different UI coat. It’s not quite that. JetBrains’ native diff tooling handles three-way merges and can show you the merge base alongside the proposed change, which matters when Claude is editing a file you’ve also edited manually since the last commit. VS Code’s diff viewer shows a two-way diff; if you have uncommitted changes to a file Claude is also modifying, the VS Code diff is showing you Claude’s version versus HEAD, not versus your working copy. You can end up accepting an edit that silently reverts your uncommitted changes.

In JetBrains, the diff viewer is aware of the working copy. This is a non-obvious reason to prefer the JetBrains plugin for projects where you frequently have mixed Claude + manual edits in-flight simultaneously.

For pure “let Claude do it, I haven’t touched these files” workflows, VS Code is fine. When your working tree is messy with manual changes, JetBrains handles the collision better.

The practical implication: if you’re the kind of developer who constantly has half-finished edits sitting in the working tree alongside Claude’s work, the JetBrains plugin pays for itself in avoided merge headaches. If your working tree is usually clean before you hand off to Claude, VS Code’s simpler two-way diff is enough.

The terminal has neither problem — it edits files directly, and the working tree is just the working tree. If you’re in a messy state, git status before running Claude tells you what you need to know.

The broader point: the “right” integration depends less on editor preference and more on what phase of the work you’re in. Exploration and autonomous execution belongs in the terminal. Human-in-the-loop review belongs in the IDE. Matching the surface to the phase is the habit that makes Claude Code noticeably less frustrating to use over time.

One last thing: both IDE integrations are actively developed and their behavior shifts between releases. The VS Code extension in particular has changed its diff UX several times. If something in your version doesn’t match this description, it’s likely been updated — the core split between “terminal for autonomous execution, IDE for structured review” is stable even if the specific UI gestures change.