Do I need to install the Claude Code extension separately?

Usually not. Run the `claude` CLI inside VS Code's integrated terminal and the official extension typically auto-installs and connects on its own. If you prefer, you can grab it from the VS Code marketplace directly. Either way, if a terminal-launched session doesn't connect to the IDE automatically, run the /ide slash command inside Claude Code to link them.

What does the VS Code extension add over just running claude in a terminal?

Four things. Proposed changes open in VS Code's native diff viewer instead of scrolling past as terminal text. Your current selection and active file get shared as context automatically. Diagnostics — the lint and type errors VS Code already knows about — are shared with Claude. And Ctrl+Esc on Windows/Linux (Cmd+Esc on Mac) opens Claude Code focused on whatever file you're in.

Does Claude Code work in Cursor or Windsurf?

Yes. Cursor and Windsurf are VS Code forks, and the same extension mechanism works in them — run the CLI in the integrated terminal and connect the same way. The core experience carries over; just don't expect this guide to cover fork-specific quirks.

Do my CLAUDE.md, MCP servers, and slash commands still work inside VS Code?

All of it works identically. The extension is a window into the same agent, not a different product — your CLAUDE.md loads, your hooks fire, your MCP servers connect, and your skills and slash commands run exactly as they do in a plain terminal. Nothing you've configured needs to be redone for the IDE.

How to Use Claude Code in VS Code

Most people’s first Claude Code session is a terminal squinting contest: a multi-file diff scrolls past as text, you approve it half-read, and then you alt-tab into your editor to find out what actually changed. VS Code integration fixes exactly that. Here’s how to wire it up, what you actually get, and when the plain terminal is still the right call.

The mental model first: it’s the same agent

Get this straight before touching setup, because it saves you a bunch of confusion: Claude Code in VS Code is not a different product. The extension is a window into the same agent you run in a terminal. Your CLAUDE.md loads exactly the same. Your hooks fire. Your MCP servers connect. Your skills and slash commands all work. Nothing you’ve configured gets redone or duplicated — the IDE just gives that same agent better ways to show you things and better context about what you’re looking at.

Prerequisite: a working CLI

You need the Claude Code CLI installed and authenticated before any of this matters. If you haven’t done that yet — or you have, and the token meter is scaring you — the budget path is running it against the GLM models: full walkthrough in how to set up Claude Code with the GLM API. The plan I use for that is the z.ai GLM Coding Plan — disclosure up front: https://z.ai/subscribe?ic=BWTG6TRYYQ is a referral link, it helps fund our compute, and it’s the same plan you’d get without it.

Once claude runs in any terminal, you’re ready.

Setup: run claude in the integrated terminal

Here’s the whole install process:

Open your project in VS Code.
Open the integrated terminal.
Run claude.

That’s it. Claude Code auto-detects that it’s running inside VS Code, and the official extension typically auto-installs on its own the first time you do this. No marketplace hunting, no config file. (The extension does live on the VS Code marketplace if you’d rather install it directly — same result.)

The one detail that matters: the auto-detect and auto-install happen in the integrated terminal. If your session didn’t connect on its own, /ide (next section) is the fix.

If it didn’t connect: /ide

Sometimes a terminal-launched session doesn’t hook into the IDE automatically. There’s a slash command for exactly that. Inside your Claude Code session, run:

/ide

That connects the running session to VS Code. It’s the first thing to try any time the integration features listed below aren’t showing up.

What you actually get

Four concrete upgrades over a plain terminal, roughly in order of how much they’ll change your day:

Native diff review. When Claude proposes changes, they open in VS Code’s diff viewer instead of rendering as terminal text. This is the headline feature. A three-file refactor as side-by-side diffs you can scan properly is a different experience from the same refactor as a wall of +/- lines — you catch the wrong-but-plausible edit before accepting it, not after.

Your selection is context. Whatever you’ve selected, and whichever file is active, gets shared with Claude automatically. Highlight a gnarly function and ask “why does this leak?” — no pasting, no describing where the code lives.

Shared diagnostics. The lint and type errors VS Code already knows about are shared with Claude. So “fix the type errors in this file” works off the same red squiggles you’re staring at, instead of Claude re-deriving the problems from scratch.

A quick-launch shortcut. Ctrl+Esc on Windows/Linux, Cmd+Esc on Mac — opens Claude Code focused on your current file. It turns “I’ll ask Claude about this” from a context switch into a keystroke.

Feeding it context

Two habits worth building once you’re in the editor. You can @-mention files in your prompt to pull them in as context references, and you can drag files straight into the prompt for the same effect. Between those, the auto-shared selection, and the shared diagnostics, most of the “let me explain where everything is” preamble from terminal-only sessions just disappears.

This is also where your standing setup compounds. The IDE hands Claude situational context — what you’re looking at right now. Your CLAUDE.md hands it standing context — the commands, conventions, and do-NOTs that apply every session. And anything you’ve wired via MCP servers is available here too, because — same agent. The three layers stack.

The honest trade-off: when plain terminal wins

The extension is not a mandatory upgrade, and some good workflows skip it deliberately. If you live in tmux, you already have your own pane and session management and the IDE window is just in the way. If you’re working over SSH on a remote box, the plain CLI is the natural fit. Plenty of people run Claude Code as a pure terminal tool forever and lose nothing that matters to them.

Where the extension earns its keep is visual review: the moment Claude starts proposing multi-file changes you actually want to read before accepting, the native diff viewer stops being a nicety and starts being the reason you catch mistakes. If your sessions are mostly one-file edits and quick questions, the terminal alone is fine.

Cursor and Windsurf

Both are VS Code forks, and the same extension mechanism works in them — run the CLI in the integrated terminal, connect the same way. If your editor of choice is one of those, everything above carries over.

Where this fits

Editor integration is the visibility layer. The other half of getting real work out of the agent in your editor is what you feed it — and that’s economics plus instructions.

Economics: IDE workflows make it easy to hand Claude more context and bigger tasks, which burns more tokens. I keep the meter sane by running against the GLM Coding Plan — again, https://z.ai/subscribe?ic=BWTG6TRYYQ is our disclosed referral link, and the setup is in the GLM API guide.

Instructions: a better window into the agent doesn’t fix vague prompts. For the repeated stuff, can your workflows into a custom slash command so one keystroke plus one command runs the whole routine. And for writing instructions that actually steer — reusable, high-signal, testable — Meta-Prompt Architect is the pack I use so every token, cheap or not, does real work.

Wire it up, hit Ctrl+Esc, and stop approving diffs you haven’t read.