How to Use Claude Code: The Complete Guide

To use Claude Code, install it (curl -fsSL https://claude.ai/install.sh | bash), run claude inside a project directory, log in, and describe what you want in plain English. It reads your codebase, proposes edits, runs commands, and works with git — asking permission before it changes anything. You steer with a repeating loop: explore, plan, implement, verify.

That's the thirty-second version. The rest of this guide is the version you'll actually reference — written not from a summary of the docs, but from running a real operating system on Claude Code every day.

We're Facet Interactive, a boutique systems integrator that builds agentic operating models for our clients. Our own content pipeline, our development workflow, and a fair amount of our internal ops run inside Claude Code — subagents, hooks, MCP servers wired to Notion and Google Workspace, the whole apparatus. So when we say "we've seen this pattern," we mean we've hit the wall, found the fix, and codified it. This is the guide we wish we'd had.

Everything below is verified against the official Claude Code documentation. Where we cite a command or a config key, it's real and it works as described. Where we illustrate with an example from our own setup, we say so.

 

What Is Claude Code?

Claude Code is Anthropic's agentic coding tool. Per the official overview, it "reads your codebase, edits files, runs commands, and integrates with your development tools," and it's available "in your terminal, IDE, desktop app, and browser."

The word that matters is agentic. A chatbot answers a question and waits. Claude Code runs a loop: it reads files, forms a plan, executes tool calls (edits, shell commands, searches), reads the results, and iterates — autonomously working a problem while you watch, redirect, or step away. You describe the outcome; it figures out the path.

Three properties define how it actually feels to use:

  • It sees your whole project. You don't paste files into a prompt. Claude Code reads what it needs, when it needs it, walking your directory tree the way a new engineer would.
  • Its actions are explicit and visible. Every file edit, every shell command, every tool call surfaces in the transcript. Nothing happens off-screen. This is the single biggest trust difference between an agent and a black box.
  • It's stateful within a session, and can carry memory across them. During a session it remembers everything you've discussed. Across sessions, CLAUDE.md files and auto memory carry the durable context forward (more on both below).

If you've read HatchWorks' guide, you've seen Claude Code framed as a "harness" that has already solved the hard agent problems — the loop, tool access, context management, memory, and control. That's a useful mental model, and it's correct. But a mental model doesn't help you at 4pm when a hook is silently eating your edits. The rest of this guide is the operating manual.

 

Getting Started: Install and First Session

Install Claude Code

The recommended install is a single command. From the overview docs:

macOS, Linux, WSL:

 

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell:

 

irm https://claude.ai/install.ps1 | iex

Native installs auto-update in the background. If you prefer a package manager, Homebrew and WinGet both work:

 

# macOS (Homebrew) — note: Homebrew installs do NOT auto-update
brew install --cask claude-code

# Windows (WinGet)
winget install Anthropic.ClaudeCode

On Debian, Fedora, RHEL, and Alpine you can also install with apt, dnf, or apk (see advanced setup). Most surfaces require a Claude subscription (Pro, Max, Team, or Enterprise) or an Anthropic Console account with credits.

Start your first session

 

cd your-project
claude

On first launch you'll be prompted to log in through your browser. That's it — you're in. A few orientation commands, straight from the quickstart:

  • /help — list available commands
  • /login / /logout — switch or re-authenticate
  • /resume — pick up a previous conversation
  • /clear — reset the conversation context (you'll use this constantly)

Ask before you act

The most valuable first move in any codebase is not to make a change. It's to understand. Ask the way you'd ask a senior engineer:

what does this project do?
where is the main entry point?
explain the folder structure
how does authentication work in this codebase?

Claude Code reads the relevant files and answers. You don't add context manually — it fetches what it needs. We've seen this pattern pay off every time we onboard a new client repo: thirty minutes of asking questions front-loads the understanding that would otherwise leak out as bad edits later.

Make your first change

add a hello world function to the main file

Claude Code finds the file, shows you a diff, asks for approval, and makes the edit. It always asks before modifying files — you approve individually or enable "accept edits" mode for the session. Then git becomes conversational:

what files have I changed?
commit my changes with a descriptive message
create a new branch called feature/quickstart

You can also skip the interactive session entirely for one-offs:

 

claude "fix the build error"          # run a task, stay interactive
claude -p "explain this function"     # one-off query, print, exit
claude -c                             # continue the most recent conversation

 

The Core Workflow: How You Actually Drive It Day to Day

New users treat Claude Code like a vending machine — insert prompt, receive code. That works for typos. For anything real, the pattern that Anthropic's own teams and every experienced user converge on is a four-phase loop. From the best practices docs: explore, plan, code, commit.

1. Explore. Enter plan mode (press Shift+Tab to cycle permission modes). Claude reads files and answers questions without touching anything:

read /src/auth and understand how we handle sessions and login.
also look at how we manage environment variables for secrets.

2. Plan. Ask for an actual plan before any code is written:

I want to add Google OAuth. What files need to change?
What's the session flow? Create a plan.

You can press Ctrl+G to open the plan in your editor and tighten it before Claude proceeds.

3. Implement. Switch out of plan mode and let it build, verifying against the plan as it goes:

implement the OAuth flow from your plan. write tests for the
callback handler, run the test suite and fix any failures.

4. Commit.

commit with a descriptive message and open a PR

The docs are explicit that plan mode adds overhead and isn't always worth it: "If you could describe the diff in one sentence, skip the plan." Planning earns its keep when the approach is uncertain, the change spans multiple files, or you don't know the code yet.

The one habit that matters most: give it a way to verify

This is the highest-leverage thing in this entire guide, and it's the thing most people skip. From best practices: "Claude stops when the work looks done. Without a check it can run, 'looks done' is the only signal available, and you become the verification loop."

Give Claude a check that returns pass or fail — a test suite, a build, a linter, a screenshot diff — and the loop closes on its own. It does the work, runs the check, reads the result, and iterates until the check passes. Compare:

Weak prompt

Strong prompt

"implement a function that validates email addresses"

"write a validateEmail function. test cases: [email protected] → true, invalid → false, [email protected] → false. run the tests after implementing."

"make the dashboard look better"

"[paste screenshot] implement this design. take a screenshot of the result, compare to the original, list differences and fix them."

"the build is failing"

"the build fails with this error: [paste]. fix it, verify the build succeeds. address the root cause, don't suppress the error."

 

We learned this the hard way. Our content pipeline scores every draft against a rubric. Early on we let the agent self-report "done." Drafts drifted below threshold and nobody caught it until a human editor did. The fix was a deterministic gate — a script that scores the draft and refuses to advance it until the number clears 80. Now the loop grades itself. That's the difference between a session you babysit and one you walk away from.

 

Permission Modes and Safety

Claude Code asks before it does anything that could modify your system. You control how much it asks with four permission modes, cycled live with Shift+Tab. Per the settings docs:

Mode

Behavior

When we use it

 

default

Prompts for permission on each consequential action

Unfamiliar code, anything touching production config

acceptEdits

Auto-approves file edits and reads; still prompts for riskier actions like shell commands

Iterating fast on code you understand

plan

Read-only research and planning; makes no changes

The "explore" phase of every non-trivial task

bypassPermissions

Skips all permission checks — most permissive

Rarely, and only in a sandbox or throwaway environment

bypassPermissions is the loaded gun. It's genuinely useful in isolated, disposable environments (a CI container, a fresh worktree), and genuinely dangerous anywhere you'd mind an unattended rm. Treat it accordingly.

Permission rules: allow, ask, deny

Modes set the default posture. Rules give you surgical control. In settings.json, the permissions object holds three arrays:

 

{
 "permissions": {
   "allow": [
     "Bash(npm run lint)",
     "Bash(npm run test:*)",
     "Read(~/.zshrc)"
   ],
   "deny": [
     "Bash(curl:*)",
     "Read(./.env)",
     "Read(./.env.*)",
     "Read(./secrets/**)"
   ],
   "ask": []
 }
}

Rules are ToolName(pattern), with * and ** wildcards. Precedence runs deny → allow → ask → mode default, so a deny rule always wins. Allowlisting the handful of commands you run constantly (npm run lint, git commit) removes most of the interruptions; denying reads of .env and secrets/** keeps credentials out of context even in permissive modes. This pairs with the memory-vs-enforcement distinction below: rules are enforced by the client regardless of what Claude decides.

The settings hierarchy

Settings resolve across four scopes, highest priority first (settings docs):

  1. Managed policy — IT-deployed, cannot be overridden (e.g. /Library/Application Support/ClaudeCode/managed-settings.json on macOS)
  2. Local — .claude/settings.local.json (gitignored; your machine only)
  3. Project — .claude/settings.json (committed; shared with your team)
  4. User — ~/.claude/settings.json (your personal defaults across all projects)

The practical upshot: commit team-wide guardrails to the project scope, keep machine-specific tweaks local, and let an org enforce non-negotiable security policy at the managed layer where no individual can weaken it.

 

The Primitives: Slash Commands, CLAUDE.md, Subagents, Hooks

Claude Code out of the box is capable. Claude Code shaped to your project is transformative. Five primitives do the shaping. The art is knowing which one a given job wants.

Slash commands and skills

Type / to see everything available. Built-ins cover the essentials — /clear, /help, /init, /memory, /agents, /mcp, /permissions, /compact, /rewind. Beyond those, you define your own reusable workflows as skills: a SKILL.md file in .claude/skills/ that Claude loads on demand when relevant, or that you invoke directly. From the best practices docs:

 

---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Analyze and fix the GitHub issue: $ARGUMENTS.

1. Use `gh issue view` to get the issue details
2. Understand the problem described in the issue
3. Search the codebase for relevant files
4. Implement the necessary changes to fix the issue
5. Write and run tests to verify the fix
6. Create a descriptive commit message and open a PR

Save that and run /fix-issue 1234. The disable-model-invocation: true flag means it only fires when you call it — the right setting for anything with side effects. Our own pipeline is mostly skills: /write-article, /score-total, /autopilot-tick. Each encodes a workflow we'd otherwise re-explain every session.

CLAUDE.md: persistent project memory

CLAUDE.md is a markdown file Claude reads at the start of every session. It's where you write down what you'd otherwise re-explain: build commands, conventions, architecture, "always do X" rules. Generate a starter with /init (it analyzes your codebase and drafts one), then refine.

Files load by scope, per the memory docs:

Scope

Location

Shared with

 

Managed policy

/etc/claude-code/CLAUDE.md (Linux/WSL), platform equivalents elsewhere

Whole org

User

~/.claude/CLAUDE.md

Just you, all projects

Project

./CLAUDE.md or ./.claude/CLAUDE.md

Team, via git

Local

./CLAUDE.local.md (gitignore it)

Just you, this project

 

Two rules we'd tattoo on a new user's arm:

Keep it under ~200 lines. The docs are blunt: "Bloated CLAUDE.md files cause Claude to ignore your actual instructions." For each line ask, "would removing this cause a mistake?" If not, cut it.

  • Be specific enough to verify. "Use 2-space indentation" beats "format code properly." "Run npm test before committing" beats "test your changes."

You can split large instruction sets into path-scoped files under .claude/rules/ (which load only when Claude touches matching files) and pull in shared files with @path/import syntax. There's also auto memory — notes Claude writes itself across sessions about build commands and debugging insights, stored per-repo and surfaced via /memory. You write CLAUDE.md; Claude maintains auto memory.

Subagents: isolated context for side quests

A subagent runs a task in its own context window and returns only a summary. Use one when a side task — reading fifty files, a security sweep — would otherwise flood your main conversation with noise you'll never reference again.

Subagents are markdown files with YAML frontmatter in .claude/agents/ (project) or ~/.claude/agents/ (user). From the best practices docs:

 

---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling

Provide specific line references and suggested fixes.

Then: "Use a subagent to review this code for security issues." The tools field limits what the agent can touch; model lets you route cheap work to a faster model. Claude Code also ships built-in subagents — Explore (read-only codebase search) and Plan (research during plan mode) — that keep exploration output out of your main window automatically (subagent docs).

The pattern we lean on hardest: an adversarial reviewer running in a fresh subagent context. It sees only the diff and the criteria, not the reasoning that produced the change — so it grades the result on its own terms. The bundled /code-review skill does exactly this for correctness.

Hooks: instruction is not enforcement

Here is the distinction that separates people who understand Claude Code from people who merely use it: CLAUDE.md is advisory. Hooks are enforced.

CLAUDE.md content is delivered as context. Claude reads it and tries to follow it, but there's no guarantee of strict compliance — the docs say so plainly. If something must happen every single time with zero exceptions, don't write it in CLAUDE.md. Write a hook: a shell command Claude Code runs deterministically at a lifecycle event (hooks docs).

Hooks fire on events like PreToolUse, PostToolUse, UserPromptSubmit, Stop, and SessionStart. Here's a PostToolUse hook that auto-formats every file after an edit:

 

{
 "hooks": {
   "PostToolUse": [
     {
       "matcher": "Write|Edit",
       "hooks": [
         { "type": "command", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/format.sh" }
       ]
     }
   ]
 }
}

And here's the enforcement half — a PreToolUse hook that blocks destructive commands. The key mechanic: exit code 2 blocks the action and feeds stderr back to Claude:

 

#!/bin/bash
COMMAND=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$COMMAND" | grep -q 'rm -rf'; then
 echo "Destructive command blocked: rm -rf not allowed" >&2
 exit 2   # ← blocks the tool call
fi
exit 0     # allow

Exit 0 proceeds, exit 2 blocks, anything else is a non-blocking warning. This is your real guardrail. We run hooks that block writes to protected directories and that gate content from advancing until it's scored — things a suggestion in a markdown file could never guarantee.

Which primitive for which job?

You want to...

Reach for

 

Give Claude standing facts about the project

CLAUDE.md

Package a repeatable workflow to invoke on demand

Skill (/command)

Keep a noisy side task out of your main context

Subagent

Guarantee an action happens every time, no exceptions

Hook

Connect an external tool or data source

MCP server (next)

 

MCP Servers: Connecting Claude Code to Your Tools

This is where Claude Code stops being a coding assistant and starts being an operating system. Model Context Protocol (MCP) is an open standard for connecting AI tools to external data sources and systems. With MCP servers connected, Claude Code can read your Jira tickets, query your Postgres database, pull Figma designs, update Notion, or drive any custom tooling you build — directly, instead of you copy-pasting into chat (MCP docs).

The trigger to connect a server: when you find yourself copying data into chat from another tool. Once connected, Claude reads and acts on that system directly.

Adding servers

There are three transports and one command. HTTP is the recommended transport for remote/cloud services:

 

# Basic syntax
claude mcp add --transport http <name> <url>

# Real example: connect Notion
claude mcp add --transport http notion https://mcp.notion.com/mcp

# With a bearer token
claude mcp add --transport http secure-api https://api.example.com/mcp \
 --header "Authorization: Bearer your-token"

stdio servers run as local processes — ideal for custom scripts and tools that need direct system access. Note the -- separating Claude's flags from the server command:

 

# Basic syntax
claude mcp add [options] <name> -- <command> [args...]

# Real example: Airtable server with an env var
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
 -- npx -y airtable-mcp-server

(SSE is a third transport but is now deprecated in favor of HTTP.)

Scopes and the .mcp.json file

Servers install at one of three scopes: local (just you, this project), user (you, everywhere), or project (committed and shared with your team). Project-scoped servers live in a .mcp.json file at the repo root:

 

{
 "mcpServers": {
   "notion": {
     "type": "http",
     "url": "https://mcp.notion.com/mcp"
   },
   "airtable": {
     "type": "stdio",
     "command": "npx",
     "args": ["-y", "airtable-mcp-server"],
     "env": { "AIRTABLE_API_KEY": "YOUR_KEY" }
   }
 }
}

Commit that, and every teammate gets the same connected toolset. One gotcha the docs call out explicitly and we've hit ourselves: an entry with a url but no type is a configuration error — Claude Code reads a typeless entry as a stdio server and skips it. Always set type.

Managing and using servers

 

claude mcp list        # list all configured servers
claude mcp get notion  # details for one server
claude mcp remove notion

Inside a session, /mcp shows connection status and tool counts. Project servers from a cloned repo sit at ⏸ Pending approval until you trust the workspace — a deliberate guard, since a server that fetches external content is a prompt-injection surface. Only connect servers you trust.

How we actually use MCP: our content engine talks to Notion (pipeline status, comments, briefs) and Google Workspace (Drive docs, Sheets) through MCP servers wired at the project scope. An agent can pull a brief from Notion, read the source doc from Drive, draft, score, and post the status back — without a human shuttling data between five tabs. That's not a demo. That's Tuesday. The lesson we'd pass on: start with one server that removes one copy-paste loop, prove it, then expand. Ten half-configured servers are worse than one that works.

 

Beyond the Terminal: SDK, IDE, and CI

Claude Code is one engine behind many surfaces. Your CLAUDE.md, settings, and MCP servers work across all of them (overview).

  • IDEs. The VS Code extension (also works in Cursor) adds inline diffs, @-mentions, and plan review. There's a JetBrains plugin for IntelliJ, PyCharm, WebStorm, and the rest.
  • Desktop and web. A desktop app for visual diff review and parallel sessions, and claude.ai/code to run tasks in the browser with no local setup.

Headless / non-interactive mode. claude -p "prompt" runs without a session — the foundation for scripting and CI. Output as text, JSON, or streaming JSON for programmatic parsing:
claude -p "List all API endpoints" --output-format json
tail -200 app.log | claude -p "Slack me if you see any anomalies"

  • CI/CD. GitHub Actions and GitLab CI/CD integrations automate PR review and issue triage. For unattended runs, scope permissions tightly with --allowedTools.
  • The Agent SDK. When you want to embed Claude Code's loop inside your own product — your own orchestration, tool access, and permissions — reach for the Agent SDK. Same underlying engine, full programmatic control.

The rule of thumb: use the terminal for interactive work, headless mode for automation, and the SDK only when you're building a product on top of the agent rather than using it.

 

Claude Code Best Practices

Distilled from the official best practices and hard-won from daily use:

  1. Manage context like it's your scarcest resource — because it is. LLM performance degrades as the context window fills. Run /clear between unrelated tasks. Use /compact when a long session gets heavy. Delegate noisy research to subagents so it never touches your main window.
  2. Explore and plan before you code. Separate research from execution and you stop solving the wrong problem.
  3. Always give it a way to verify. Tests, a build, a screenshot diff. If you can't verify it, don't ship it.
  4. Be specific. Name the file, the scenario, the constraint, what "done" looks like. Precision up front beats corrections later.
  5. Course-correct fast. Hit Esc the moment it drifts — context is preserved, you redirect. Esc Esc or /rewind restores a previous state.
  6. After two failed corrections, /clear and restart with a better prompt that bakes in what you learned. A clean session almost always beats a polluted one.
  7. Install the CLIs it already knows — gh, aws, gcloud. They're the most context-efficient way to reach external services.
  8. Use the right primitive. Standing facts → CLAUDE.md. Must-happen-every-time → hook. Repeatable workflow → skill. Noisy side task → subagent.
  9. Prune your CLAUDE.md ruthlessly. If Claude keeps ignoring a rule, the file is probably too long and the rule is drowning.
  10. Add an adversarial review step for anything that ran unattended — a fresh subagent that sees only the diff.

 

Common Pitfalls and Troubleshooting

The failure modes are predictable once you've hit them. Here are the ones that actually cost people time.

The five classic failure patterns

  • The kitchen-sink session. You mix three unrelated tasks in one conversation; context fills with irrelevant junk and quality drops. → /clear between tasks.
  • Correcting in circles. Two, three corrections on the same issue, still wrong. The context is now polluted with failed attempts. → After two misses, /clear and rewrite the prompt.
  • The over-stuffed CLAUDE.md. So long that important rules get lost. → Prune. Convert must-happen rules to hooks.
  • Trust-then-verify gap. A plausible-looking implementation that fails on edge cases. → Always attach a verification check.
  • Infinite exploration. "Investigate X" with no scope; Claude reads hundreds of files. → Scope it, or hand it to a subagent.

Troubleshooting: symptom → fix

Symptom

Likely cause

Fix

 

Claude ignores my CLAUDE.md

File not loaded, or too long/vague

Run /memory to confirm it's loaded; make instructions specific; prune to <200 lines. Content is context, not enforcement — for hard rules use a hook

A rule must be enforced but Claude skips it

It's advisory in CLAUDE.md

Move it to a PreToolUse/Stop hook (exit code 2 blocks) — hooks docs

MCP server won't connect

.mcp.json entry has a url but no type

Add "type": "http" (or sse/ws); check status in /mcp

MCP server stuck at ⏸ Pending approval

Cloned repo, workspace not yet trusted

Run claude interactively in the folder and accept the trust dialog

Quality degrades late in a long session

Context window filling up

/clear between tasks, /compact mid-task, delegate research to subagents

Instructions "lost" after /compact

Given only in chat, or in a nested CLAUDE.md not yet reloaded

Put durable instructions in the project-root CLAUDE.md — it's re-injected after compaction

&& install error on Windows

You're in PowerShell, not CMD

Use the PowerShell installer: `irm https://claude.ai/install.ps1

Login code shown instead of redirect

Local callback unreachable (WSL2, SSH, containers)

Paste the code into the Paste code here if prompted prompt

Wrong account / auth failures

Stray ANTHROPIC_API_KEY overriding your subscription

unset ANTHROPIC_API_KEY, then check /status — authentication docs

A hook isn't firing

Matcher pattern or exit-code logic wrong

Run /hooks to inspect config; verify the matcher and that blocking hooks exit 2

A subagent isn't found

~/.claude/agents/ created mid-session

Restart Claude Code — a running session doesn't detect a newly created agents directory

When you're genuinely stuck, the fastest move is often to ask Claude Code about itself — how do I create a hook that runs on every commit? — or consult the official troubleshooting guide.

 

Claude Code vs. Cursor

The most common question we get from engineering leaders: "We already have Cursor — do we need this?" They're different tools with overlapping capabilities, and the honest answer is that many teams run both. Here's the architectural comparison.

Dimension

Claude Code

Cursor

 

Core paradigm

Terminal-native agent — you describe outcomes, it executes across files, runs commands, drives git

AI-augmented editor (VS Code fork) — you edit code, AI assists inline as you type

Primary surface

Terminal, with IDE/desktop/web/CI surfaces on the same engine

The Cursor IDE (graphical editor first)

Interaction model

Conversational; autonomous multi-step loops you supervise

Completions, inline edits, and an agent mode within the editor

Visual feedback

Diffs in the terminal or IDE extension; explicit tool-call transcript

Rich in-editor diff and file-tree visualization

Model access

Anthropic's Claude models (large context windows)

Multiple providers, including Claude, GPT, and others

Extensibility

CLAUDE.md, skills, subagents, hooks, MCP servers, Agent SDK

Rules files, extensions, and MCP support

Automation / CI

First-class headless mode (claude -p), GitHub/GitLab actions, SDK

Primarily interactive; less oriented to headless pipelines

Entry price

Starts at $20/mo (Pro); Console/API billing also available

Starts at $20/mo (Pro); higher tiers above

Best fit

Complex multi-file work, automation, agentic operating models, engineers comfortable in a terminal

IDE-first daily editing, engineers who want maximum visual feedback on every AI change

 

How to choose: if your work is IDE-centric — you live in the editor, you want to see every suggestion land in a familiar UI — Cursor's paradigm fits. If you're driving multi-file changes, wiring up automation, and building repeatable agentic workflows (hooks, subagents, MCP, CI), Claude Code's agent-first design is built for it. Plenty of teams pair them: Cursor for daily editing, Claude Code for the heavy lifting and the automation. The two aren't mutually exclusive — they're different points on the same spectrum.

(Pricing and tiers shift; check each vendor's current pricing page before you standardize a team on either.)

 

FAQ

What is Claude Code?

Claude Code is Anthropic's agentic coding tool. It reads your codebase, edits files, runs commands, and integrates with your development tools — available in the terminal, IDE, desktop app, and browser. Unlike a chatbot, it runs an autonomous loop: it explores, plans, executes, and verifies while you supervise or step away.

How do I install Claude Code?

Run curl -fsSL https://claude.ai/install.sh | bash on macOS, Linux, or WSL (irm https://claude.ai/install.ps1 | iex in Windows PowerShell). Then cd into a project, run claude, and log in through your browser. Homebrew (brew install --cask claude-code) and WinGet (winget install Anthropic.ClaudeCode) also work.

Is Claude Code free?

No. Using Claude Code requires a Claude subscription (Pro, Max, Team, or Enterprise) or an Anthropic Console account with API credits. The Pro plan starts at $20/month; see Claude pricing for current tiers.

What is the difference between Claude Code and the Claude app?

The Claude app (claude.ai) is a conversational assistant. Claude Code is an agentic coding tool that works directly in your development environment — reading and editing real files, running commands, and managing git in your actual project, not just chatting about code.

How do I use Claude Code to review code?

Ask it directly — "review my changes and suggest improvements" — or run the bundled /code-review skill, which reviews the current diff for bugs in a fresh subagent context and reports findings back. For a dedicated reviewer, create a subagent in .claude/agents/ with read-only tools and a review-focused system prompt, then say "use a subagent to review this code for security issues."

What is CLAUDE.md and where does it go?

CLAUDE.md is a markdown file Claude Code reads at the start of every session for persistent project context — build commands, conventions, architecture. It lives at your project root (./CLAUDE.md, committed to git), in ~/.claude/CLAUDE.md for personal defaults, or at the managed-policy path for org-wide rules. Generate a starter with /init. Keep it under ~200 lines.

What is an MCP server in Claude Code?

An MCP (Model Context Protocol) server connects Claude Code to external tools and data — Jira, Postgres, Figma, Notion, Slack, or your own custom tooling. Add one with claude mcp add --transport http <name> <url>. Once connected, Claude reads and acts on that system directly instead of you pasting data into chat.

What are the permission modes in Claude Code?

Four: default (asks before consequential actions), acceptEdits (auto-approves edits/reads, prompts for riskier actions), plan (read-only research, no changes), and bypassPermissions (skips all checks). Cycle them live with Shift+Tab. Layer allow/ask/deny rules in settings.json for finer control.

What's the difference between CLAUDE.md and a hook?

CLAUDE.md is advisory — Claude reads it and tries to follow it, but compliance isn't guaranteed. A hook is a shell command Claude Code runs deterministically at a lifecycle event; it executes regardless of what Claude decides. For anything that must happen every time (formatting, blocking a dangerous command), use a hook — a PreToolUse hook that exits with code 2 blocks the action outright.

Can Claude Code run in CI/CD or without a terminal session?

Yes. Headless mode (claude -p "prompt") runs non-interactively with text, JSON, or streaming-JSON output — the foundation for scripts, pre-commit hooks, and pipelines. There are first-class GitHub Actions and GitLab CI/CD integrations, and the Agent SDK for embedding the engine in your own product.

What are subagents used for?

A subagent runs a task in its own separate context window and returns only a summary — keeping noisy work (large codebase searches, security sweeps, adversarial reviews) out of your main conversation. Define them as markdown files with YAML frontmatter in .claude/agents/, with their own tool restrictions and model.

How do I stop Claude Code from making a change I don't want?

Press Esc to stop it mid-action (context is preserved, so you can redirect). Press Esc twice or run /rewind to restore a previous conversation or code state. Say "undo that" to revert changes. For changes that should never be possible, use a deny permission rule or a PreToolUse hook.

Claude Code vs. Cursor — which should I use?

Claude Code is a terminal-native agent built for multi-file work, automation, and agentic workflows (hooks, subagents, MCP, CI). Cursor is an AI-augmented IDE built for editor-first daily coding with rich visual feedback. Both start at $20/month, both support MCP and Claude models, and many teams run both — Cursor for editing, Claude Code for heavy lifting and automation.

 

Where This Goes Next

Most guides stop at "here are the features." That's the runtime. The real leverage is the layer above it — the methodology that turns a capable tool into a compounding operating advantage: which workflows you encode as skills, which guarantees you enforce with hooks, which systems you wire in through MCP, and how you close the verification loop so agents grade their own work.

That's the work we do every day, on our own systems and our clients'. Facet builds agentic operating models — not one-off automations, but the full apparatus of loops, guardrails, and integrations that lets a 10-person team operate like 100. If you're a technical leader evaluating Claude Code and want to skip the eighteen-month learning curve, our Agentic Engineering and Forward Deployed Engineering teams embed with yours, transfer the methodology, and leave you owning the capability — not dependent on us.

Install Claude Code today. Run /init, ask it three questions about your codebase, and make one change. Then come find us when you're ready to turn the runtime into a system.

Facet Interactive is a boutique systems integrator building agentic operating models for engineering and operations teams. We run our own content and development operations on Claude Code — the patterns in this guide are the ones we use.