How to Use Claude Code in Visual Studio Code

Install the Claude Code extension from the VS Code marketplace, or run the claude command in VS Code's integrated terminal from your project root. Sign in, open the repository folder, and start a session. Review every proposed change in the editor's diff view before accepting, and give the agent project context through an instruction file and indexed docs.

Step 1: pick the route

The extension. Search the VS Code marketplace for Claude Code and install the official extension from Anthropic. It adds a panel for conversations and shows proposed edits as diffs in the editor, which makes review faster than reading terminal output.

The CLI in the integrated terminal. Install Claude Code on your machine, open VS Code's terminal, and run claude from the project root. This is the same agent you would run in any terminal, and it suits developers who already live in the terminal or want identical behaviour across editors.

Both routes use the same underlying agent. The choice is about where you prefer to read and approve changes. Many developers use the extension for day-to-day edits and the terminal for scripted or long-running work.

Step 2: open the right folder and sign in

Open the repository root as your workspace, not a subfolder. The agent explores files relative to where it starts, and a session opened inside one package will miss shared configuration, scripts, and conventions that live higher up.

Sign in when prompted, using the account or API access your team has set up. If your organisation manages access centrally, follow that route rather than personal keys, so usage and billing stay visible.

Step 3: run a first task you can verify

Start with something small and checkable: add a test for an existing function, fix a lint warning, or explain a module. Watch how the agent explores the codebase, which files it reads, and what it proposes.

Review in the diff view. Each proposed edit appears as a change you can inspect. Read it the way you would read a colleague's pull request. Accept what is right, reject what is not, and say why, because the reason shapes the next attempt.

Keep permissions tight at first. Let the agent read freely, but approve commands and file writes until you trust how it behaves in this repository.

Step 4: give it context that lasts

Every new session starts without memory of the last one. That is the main reason the agent reinvents helpers, ignores conventions, or asks the same questions twice.

An instruction file in the repository root holds what the agent cannot infer: commands that actually work, conventions, and hard constraints. Keep it short, since it is read on every request.

An indexed knowledge source holds everything else: architecture notes, decision records, API contracts, and the codebase itself. Connect it through an MCP server so the agent searches it on demand. The agent pulls the three relevant chunks instead of reading forty files, which saves tokens and gets the details right.

Fitting it into a normal day

The agent is most useful when it slots into the way you already work rather than replacing it.

Branch per task. Create a branch before each agent task. If the result is wrong, you discard the branch instead of untangling edits from your own work.

Let it run the checks. Tell the agent which test and lint commands to run after each change, and expect it to report the results. A change that has not been run is a draft, however confident the summary sounds.

Use it for reading as much as writing. Asking the agent to explain a module, trace a request through the code, or find every caller of a function is often more valuable than generation, and carries no risk to the codebase.

Keep your own edits separate. Avoid typing in a file while the agent is changing it. Let a task finish, review the diff, then continue. Interleaved edits make reviews confusing and occasionally overwrite each other.

Common problems in the editor

  • The agent edits the wrong package. Check the workspace root, and name the target path in your request.
  • Sessions get slow and confused. Long sessions pile up stale context. Start fresh for each new task and commit at every working state.
  • It ignores team conventions. Add the rule to the instruction file if it is short and universal; otherwise index the style guide and ask the agent to search it first.
  • MCP servers do not appear. Server configuration is read at startup, so restart the session after adding one, and confirm the command runs on its own in a terminal.

Frequently asked questions

Is there an official Claude Code extension for VS Code?
Yes. Anthropic publishes a Claude Code extension in the VS Code marketplace. It runs the same agent as the command-line tool, with a conversation panel and in-editor diffs for proposed changes. Install the official listing rather than a lookalike, and check the publisher before granting it access to your workspace.
Should I use the extension or the terminal?
Use the extension if you want to review edits as editor diffs and keep everything in one window. Use the CLI in the integrated terminal if you prefer terminal workflows, run long or scripted tasks, or want identical behaviour across different editors. They share the same agent, so switching later costs little.
Can Claude Code in VS Code use MCP servers?
Yes. MCP servers configured for Claude Code are available whichever route you use. Add the server, restart the session so the configuration is read, and confirm the tools are listed. A retrieval server over your docs and codebase is usually the most valuable first addition, because it replaces pasted context.