How to Set Up Claude Code in VS Code (and Actually Use It)

What This Guide Actually Covers

Most Claude Code setup guides stop at "install the extension and authenticate." That is about 2% of knowing how to use it effectively. The other 98% is project configuration, permission modes, CLAUDE.md files that give Claude real context about your codebase, MCP servers for extended capabilities, and the prompting habits that separate "AI wrote some code" from "AI wrote code I can actually ship."

We use Claude Code every day at Modern Softworks. Not as a novelty. As part of how we build production applications. This guide is everything we wish someone had told us on day one, written in the order you will actually need it.

By the end, you will have Claude Code installed, authenticated, configured for your specific project, and set up with the workflow patterns that make it genuinely useful instead of just fast.

Prerequisites

Before you start, make sure you have:

• VS Code version 1.96 or later (check with code --version in your terminal)
• Node.js version 18 or later (check with node --version)
• An Anthropic account with API access or a Max subscription
• A project to work in. Claude Code is most useful when it has a codebase to understand. An empty folder will work for testing, but you will get more out of this guide with a real project.

If you are on a Max subscription, Claude Code is included. If you are on API billing, you will need credits loaded. Either works. The setup is the same.

Installing the VS Code Extension

Claude Code runs as a native VS Code extension. There is also a standalone CLI version available via npm, but the VS Code extension is the more integrated experience and the one we recommend for most workflows.

Open VS Code and go to the Extensions panel (Cmd+Shift+X on Mac, Ctrl+Shift+X on Windows/Linux). Search for "Claude Code" and install the extension published by Anthropic. Alternatively, run this from your terminal:

# Install the Claude Code extension from your terminal
code --install-extension anthropic.claude-code

Once installed, you will see Claude Code in the sidebar. Open it by clicking the icon or pressing Cmd+Shift+P and searching for "Claude Code: Open."

Authentication

The first time you open Claude Code, it will ask you to authenticate. You have two options:

Anthropic account (API credits): Select this option and follow the browser redirect. You will authorize VS Code to use your Anthropic API key. Usage is billed per token.

Claude Max subscription: If you have a Max plan, select this option instead. Same browser flow, but usage comes from your subscription rather than per-token billing.

Once authenticated, you should see the Claude Code chat panel ready to go. Type something simple to confirm it works:

Prompt: Verify your connection
What files are in this project?

If Claude responds with a file listing, you are connected. If you get an authentication error, check that your API key has active credits or that your Max subscription is current.

Your First Real Interaction

Before we get into configuration, it helps to understand what Claude Code actually does differently from a regular chat interface.

Claude Code has direct access to your project files. It can read them, edit them, run terminal commands, search your codebase, and create new files. It is not working from a code snippet you pasted into a chat window. It is operating inside your project directory with the same file access you have.

Try something practical:

Prompt: Ask Claude to read your project
Read my package.json and tell me what framework this project uses

Claude will use its file reading tool, analyze the contents, and give you an answer based on your actual project. This is the core difference: context is automatic. You do not need to copy and paste your code. Claude can see it.

Now try an edit:

Prompt: Ask Claude to make an edit
Add a comment to the top of my README explaining what this project does,
based on the package.json and any config files you can find

Claude will read multiple files, synthesize what it finds, and propose an edit. You will see the proposed changes and can approve or reject them. This approval step is important, and it leads directly into the next section.

Understanding Permission Modes

Claude Code has three permission modes that control how much autonomy it has. Getting this right matters more than most people realize.

Ask mode (default). Claude asks for permission before every file edit, terminal command, and potentially destructive action. This is the safest option and where you should start. You will approve a lot of prompts, but you will also see exactly what Claude is doing before it does it.

Auto-accept edits. Claude can read and edit files without asking, but still asks before running terminal commands. Good for when you trust Claude with code changes but want to control what runs in your terminal.

YOLO mode (full auto). Claude does everything without asking. Read files, edit files, run commands, all of it. We do not recommend this for most workflows. The name is accurate.

You can switch between modes using the permission controls in the Claude Code panel. Start with Ask mode. Once you have a feel for the kinds of actions Claude takes in your project, you can selectively loosen permissions.

Our recommendation: auto-accept edits with manual approval for terminal commands. You get the speed of automatic file changes with a safety net for anything that runs in your shell. If Claude wants to rm -rf something, you will know about it before it happens.

Configuring Your Project with CLAUDE.md

This is where Claude Code goes from "helpful" to "actually understands my project." CLAUDE.md files are markdown files that Claude reads automatically at the start of every conversation. They give Claude persistent context about your codebase, conventions, and preferences.

There are three levels of CLAUDE.md files:

Project-Level CLAUDE.md

Create a CLAUDE.md file in your project root. This is the most important one. Here is a practical starting point:

<!-- Example: CLAUDE.md for a Next.js project -->
# Project Context
 
## Tech Stack
- Next.js 14 with App Router
- TypeScript (strict mode)
- Tailwind CSS for styling
- Prisma for database access
 
## Conventions
- Use named exports, not default exports
- Components use PascalCase file names
- All components go in src/components/ComponentName/
- CSS modules for component styles (ComponentName.module.css)
- Use "cn" utility for className merging
 
## Important Patterns
- Server components by default, "use client" only when needed
- Data fetching happens in page.tsx or layout.tsx, not in components
- All forms use react-hook-form with zod validation
- API routes in src/app/api/ follow RESTful conventions
 
## Do Not
- Do not use default exports
- Do not add console.log statements (use the logger utility)
- Do not install new dependencies without asking first

Customize this for your actual project. The more specific you are about your conventions, the more Claude's output will match your codebase. If your team uses a specific test structure, put it here. If there is a pattern for API calls, document it. Claude reads this file every session, so everything in it shapes every response.

User-Level CLAUDE.md

You can also create a CLAUDE.md at ~/.claude/CLAUDE.md for personal preferences that apply across all projects:

<!-- Example: ~/.claude/CLAUDE.md for personal preferences -->
# Personal Preferences
- Always use TypeScript, never plain JavaScript
- Prefer functional components over class components
- When writing tests, use describe/it blocks with clear test names
- Never commit directly to main

Directory-Level CLAUDE.md

For monorepos or large projects, you can add CLAUDE.md files in subdirectories. Claude picks these up when working in those directories:

<!-- Example: Directory-level CLAUDE.md for component conventions -->
# /src/components Context
- Every component has its own folder with index.ts barrel export
- Component folder contains: Component.tsx, Component.css, Component.test.tsx
- Props interfaces are defined in the component file, above the component

The hierarchy works like CSS specificity: project-level provides the base, directory-level adds specifics, and user-level adds personal preferences. More specific files take priority when there is a conflict.

Project Settings

Beyond CLAUDE.md, you can configure Claude Code behavior through settings files. Create a .claude/settings.json in your project root:

{
  "permissions": {
    "allow": [
      "Read",
      "Edit",
      "Write",
      "Glob",
      "Grep"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force)"
    ]
  }
}

The allow array specifies which tools Claude can use without asking. The deny array blocks specific dangerous commands entirely. This is how you set up the guardrails that make auto-accept modes safer.

You can also set user-level defaults at ~/.claude/settings.json for preferences that apply everywhere.

Effective Prompting Patterns

This is where experience matters more than documentation. After using Claude Code daily for over a year, here is what we have found actually works.

Be Specific About What You Want

This is the difference between useful output and a trip to the undo button.

Vague (wastes time):

Bad prompt: Too vague, no direction
Make this component better

Specific (saves time):

Good prompt: Clear task, location, and conventions
Refactor the UserProfile component to extract the avatar section
into its own AvatarDisplay component. Keep the same props interface.
Put the new component in src/components/AvatarDisplay/ following
our component folder pattern.

The specific version gives Claude a clear task, a clear location, and references a convention from your CLAUDE.md. The vague version gives Claude permission to do whatever it thinks "better" means, which is almost never what you meant.

Show It Your Patterns

When you want Claude to create something new, point it at an existing example:

Good prompt: Reference an existing pattern
Create a new API route for /api/projects that follows the same
pattern as /api/users. Read that file first, then create the new
one with the same error handling, validation, and response structure.

Claude is excellent at pattern matching. Give it a pattern to match. We keep reference components and API routes specifically for this purpose.

Scope It Small

Large, multi-step requests are where Claude is most likely to make mistakes. Instead of:

Bad prompt: Too broad, too many moving parts
Build me a complete authentication system with login, signup,
password reset, and email verification

Break it down:

Good prompt: One focused task with clear scope
Create the login form component with email and password fields,
using react-hook-form and our zod validation pattern. Include the
form submission handler that calls /api/auth/login. Do not create
the API route yet.

One piece at a time. Review each piece. Then move to the next.

Tell It What Not to Do

Negative constraints are surprisingly effective:

Good prompt: Negative constraints prevent unwanted changes
Add pagination to the ProjectList component. Do not install any
new packages. Do not modify the API endpoint. Use URL search params
for the page state, not React state.

Without those constraints, Claude might install a pagination library, restructure your API, and use useState for the page number. All reasonable choices. None of them what you wanted.

Setting Up MCP Servers

MCP (Model Context Protocol) servers extend Claude Code's capabilities beyond your local filesystem. They let Claude interact with external services like databases, APIs, documentation sites, and more.

What MCP Servers Do

Think of MCP servers as plugins. Each one gives Claude access to a specific external system. A GitHub MCP server lets Claude read issues, create PRs, and review code. A database MCP server lets Claude query your database directly. A documentation MCP server lets Claude search and reference docs.

Configuring MCP Servers

MCP servers are configured in your settings. You can set them at the project level in .claude/settings.json:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-filesystem"],
      "env": {}
    }
  }
}

Each MCP server runs as a separate process that Claude communicates with. The command field specifies how to start it, and args provides any necessary arguments.

Useful MCP Servers

Here are a few that we find genuinely useful in our daily workflow:

Filesystem server for extended file operations beyond what Claude Code provides natively.

GitHub server for interacting with issues, pull requests, and repository metadata without leaving your editor.

Fetch server for making HTTP requests, useful when Claude needs to check an API endpoint or download documentation.

To add an MCP server, update your settings and restart Claude Code. Claude will automatically discover the new tools provided by the server and can use them in your conversations.

Custom Hooks

Hooks let you run shell commands automatically before or after Claude takes specific actions. They are useful for enforcing workflows, running linters, or triggering builds.

How Hooks Work

Hooks are configured in your settings and fire on specific events:

{
  "hooks": {
    "postToolExecution": [
      {
        "matcher": "Edit|Write",
        "command": "npx eslint --fix $FILE_PATH"
      }
    ]
  }
}

This example runs ESLint with auto-fix after every file edit. Claude writes the code, the hook cleans it up to match your linting rules. You can also use preToolExecution to run checks before Claude acts.

Practical Hook Examples

Auto-format after edits:

{
  "hooks": {
    "postToolExecution": [
      {
        "matcher": "Edit|Write",
        "command": "npx prettier --write $FILE_PATH"
      }
    ]
  }
}

Run type checking after file changes:

{
  "hooks": {
    "postToolExecution": [
      {
        "matcher": "Edit|Write",
        "command": "npx tsc --noEmit 2>&1 | head -20"
      }
    ]
  }
}

Hooks keep your workflow consistent. Claude's output gets formatted the same way your manually written code does, without you having to remember to run the formatter.

Workflow Tips from Daily Use

These are the patterns that took us months to figure out. They are not in the official docs.

Start every session with context. Even with CLAUDE.md, Claude benefits from a brief orientation at the start of a conversation. "I am working on the user dashboard. The relevant files are in src/app/dashboard/ and the API routes are in src/app/api/users/." Two sentences that save ten minutes of Claude searching the wrong part of your codebase.

Use Claude for exploration before implementation. Before asking Claude to build something, ask it to analyze what already exists. "Read through the auth module and explain how session management works currently." Understanding the codebase through Claude's analysis is faster than reading every file yourself, and it ensures Claude has the context it needs for the implementation step.

Review AI output like a stranger wrote it. Because it did. We covered this extensively in our post about using AI in production code, but it is worth repeating: Claude's code looks intentional. It is not. It is statistically probable. Read every line, check the imports (Claude will import packages that do not exist), and test the unhappy paths.

Let Claude handle the boring parts. Boilerplate, test scaffolding, data transformations, regex, type definitions. These are the tasks where Claude saves the most time with the least risk. Save your review energy for the parts that matter: business logic, security boundaries, and architectural decisions.

Do not fight the tool. If Claude keeps getting something wrong after two or three attempts, write it yourself. Some things are faster to type than to explain. Knowing when to stop prompting and start typing is a skill that takes about a week to develop.

Verification

Let us make sure everything is working. Run through this quick checklist:

1. Extension installed: Claude Code appears in your VS Code sidebar
2. Authentication working: Claude responds to basic prompts
3. File access confirmed: Claude can read and describe files in your project
4. CLAUDE.md loaded: Ask Claude "What conventions does this project follow?" and it should reference your CLAUDE.md content
5. Permissions configured: Try an edit and confirm it follows your permission mode (asks for approval or auto-applies based on your setting)
6. MCP servers running (if configured): Ask Claude to use a tool from your MCP server

If any of these fail, the most common fixes are:

• Auth issues: Re-authenticate through the extension settings
• CLAUDE.md not loading: Make sure the file is named exactly CLAUDE.md (case sensitive) and is in the project root
• MCP server not connecting: Check that the command in your settings actually runs (try it manually in your terminal first)