Claude Code Complete Guide 2026: From Install to Autonomous Coding Agents

Claude Code is not autocomplete — it is a coding agent that lives in your terminal. It reads your whole repository, plans changes across files, runs commands, executes tests, fixes its own failures and iterates until the job is done. Used well, it feels like delegating to a fast junior engineer who never sleeps. Used carelessly, it produces confident nonsense at impressive speed. This guide takes you from installation to genuinely autonomous workflows: CLAUDE.md project memory, MCP servers that give Claude tools, hooks that enforce your rules automatically, and subagents that parallelize real work — ending with a complete worked project.

Install and first run

Claude Code requires Node.js 18 or newer. Install it globally, verify, and launch it inside a project:

# Install (macOS, Linux, WSL)
npm install -g @anthropic-ai/claude-code

# Verify
claude --version

# Start it inside your project
cd my-project
claude

On first launch, Claude Code walks you through authentication: sign in with a Claude subscription (Pro or Max) or connect an Anthropic API key for pay-as-you-go billing. Teams usually prefer the API or a Teams plan for usage tracking. Two commands to learn immediately:

• /init — scans your repo and generates a starter CLAUDE.md.
• /clear — resets the conversation context. Use it whenever you switch tasks; a polluted context is the number one cause of weird behavior.

CLAUDE.md: the project's memory

CLAUDE.md is a Markdown file Claude reads at the start of every session. It is where you encode everything you'd tell a new hire on day one: stack, commands, conventions, and the landmines. Keep it short, factual and specific — vague advice gets ignored, precise facts get used. A solid starter:

# Project: Acme Storefront

## Stack
- Next.js 15 (App Router), TypeScript strict mode
- PostgreSQL via Prisma. Redis for sessions.
- Tests: Vitest + Playwright

## Commands
- Dev server: npm run dev
- Tests: npm run test (ALWAYS run before finishing a task)
- Lint: npm run lint
- Typecheck: npm run typecheck

## Conventions
- All money values are integer cents. Never floats.
- API routes live in src/app/api, services in src/server
- No default exports. Named exports only.

## Do not touch
- /prisma/migrations (append only, never edit old ones)
- .env files. If a task needs a new variable, tell me.

You can nest CLAUDE.md files in subdirectories for monorepos — Claude reads the ones relevant to the files it's working on. Your personal preferences (editor style, how verbose answers should be) belong in ~/.claude/CLAUDE.md, which applies everywhere.

The workflow that actually works

1. Plan before code. Ask Claude to explore and propose a plan first: "Read the auth module and give me a step-by-step plan to add password reset. Don't write code yet." Review the plan like a tech lead.
2. Execute in small steps. One commit-sized task per session: implement, test, review the diff.
3. Make tests the contract. "Done" means the test suite passes. If there are no tests for what you changed, ask Claude to write them first.
4. Review every diff. Autonomy is earned per repository. Until you trust the setup, read the changes line by line — that's also how you learn what to add to CLAUDE.md.

Slash commands you'll use daily

• /init — generate CLAUDE.md from the repo.
• /clear — wipe context and start fresh.
• /compact — summarize a long session to free context while keeping the essentials.
• /model — switch models (use the biggest model for hard planning, faster ones for routine edits).
• /cost — show token usage and estimated cost of the session (API billing).
• /review — review a pull request.
• /agents — manage subagents (covered below).
• /mcp — inspect connected MCP servers and their status.

You can also create your own commands: drop a Markdown file in .claude/commands/ and it becomes a slash command whose content is the prompt. Example — .claude/commands/fix-issue.md:

Analyze and fix GitHub issue $ARGUMENTS.

1. Read the issue and reproduce the problem.
2. Find the root cause. Explain it in two sentences.
3. Implement the smallest fix that resolves it.
4. Add a regression test and run the full suite.
5. Summarize the change and the files touched.

Now /fix-issue 123 runs that playbook every time, identically, for the whole team.

MCP servers: give Claude real tools

Out of the box, Claude Code can read files, edit them and run shell commands. MCP (Model Context Protocol) servers extend that: database access, GitHub operations, browser control, your own internal APIs. Configure project-scoped servers in .mcp.json at the repo root (commit it so the team shares it) or add them from the terminal:

# Filesystem + GitHub + Postgres, added from the CLI
claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ./src
claude mcp add github -- npx -y @modelcontextprotocol/server-github
claude mcp add postgres -- npx -y @modelcontextprotocol/server-postgres \
  "postgresql://readonly:secret@localhost:5432/acme"

The equivalent .mcp.json file:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./src"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres",
               "postgresql://readonly:secret@localhost:5432/acme"]
    }
  }
}

Note the details that matter: the Postgres connection above uses a read-only database user, and secrets come from environment variables, never hardcoded into a committed file. After adding a server, ask Claude something that requires it ("list orders from the last 7 days and compare with the code that calculates totals") and watch it chain tool calls. Run /mcp to debug a server that fails to connect.

Hooks: rules Claude cannot forget

Prompts are requests; hooks are enforcement. Hooks are shell commands Claude Code runs automatically at lifecycle points — before a tool executes, after a file is edited, when a session stops. Configure them in .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command",
            "command": "npx prettier --write \"$CLAUDE_FILE_PATH\" 2>/dev/null || true" }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command",
            "command": "python3 .claude/hooks/block_dangerous.py" }
        ]
      }
    ]
  }
}

The first hook auto-formats every file Claude edits, so style stays consistent without nagging. The second calls a guard script before any shell command; if the script exits with code 2, the command is blocked and Claude is told why. A simple guard:

import json, sys

data = json.load(sys.stdin)
cmd = data.get("tool_input", {}).get("command", "")

BLOCKED = ["rm -rf /", "DROP TABLE", "git push --force", "--prod"]
if any(b in cmd for b in BLOCKED):
    print("Blocked by project policy. Propose a safer alternative.",
          file=sys.stderr)
    sys.exit(2)  # exit 2 = block the tool call
sys.exit(0)

Subagents: parallel specialists

Subagents are separate Claude instances with their own context and instructions, defined as Markdown files in .claude/agents/. The main agent delegates to them — a reviewer that only reviews, a researcher that only reads, a test-writer that only writes tests. Because each has a clean context, they stay focused, and several can run in parallel.

---
name: code-reviewer
description: Reviews code changes for bugs, security issues
  and convention violations. Use after any significant change.
tools: Read, Grep, Bash
model: sonnet
---

You are a strict code reviewer for this repository.

For every change set you are given:
1. Run `git diff` and read the full diff.
2. Flag: security issues, money-handling bugs,
   missing tests, and CLAUDE.md convention violations.
3. Report findings as a numbered list, most severe first.
   If you find nothing, say so plainly. Do not edit files.

Typical high-value subagents: a test-writer that turns a feature description into failing tests first, a docs-researcher that reads documentation and returns summaries (keeping raw docs out of your main context), and a security reviewer like the one above. The pattern that changes everything: implementer in the main session, reviewer subagent after each milestone, fixes, then tests.

Worked example: an autonomous build, start to finish

Goal: add a "forgot password" flow to a small Node API. Watch the loop — plan, build with tools, verify with hooks, review with a subagent.

# 1. Fresh session, plan first
claude
> Read the auth module and the users table schema.
> Give me a step-by-step plan for password reset with
> expiring tokens. No code yet.

# (review and adjust the plan)

> Implement the plan. Write tests first, then the code.
> Run the suite after each step.

# Claude edits files; the Prettier hook formats each one;
# the Bash guard would block anything destructive.

# 2. Verify independently
> Run the full test suite and the typecheck.
> Show me the git diff summary.

# 3. Subagent review
> Use the code-reviewer subagent on this diff.

# 4. Ship it yourself, informed
git add -A && git commit -m "feat: password reset flow"

Total human effort: one plan review, one diff review. Everything mechanical — writing, formatting, testing, first-pass review — was delegated and verified, not trusted blindly.

Costs, limits and honest expectations

• Cost: subscription plans cap usage by time windows; API billing scales with tokens. Big refactors on large repos cost real money — /cost keeps you honest.
• Context is finite. Monorepos overflow it. Work package by package, keep CLAUDE.md tight, and lean on subagents for research so raw material never floods the main session.
• It still makes mistakes. Confident, plausible, wrong ones. Tests, hooks and diff review are not optional ceremony — they are the product.
• Start supervised. Earn autonomy repo by repo: read-only exploration first, then small edits, then delegated features with review.

Master these pieces — CLAUDE.md as memory, MCP as hands, hooks as law, subagents as team — and Claude Code stops being a fancy autocomplete. It becomes a development workflow you direct, where your job shifts from typing code to reviewing outcomes. That's the actual skill worth learning in 2026.

Headless mode: Claude Code in scripts and CI

Everything above also runs non-interactively. The -p flag sends one prompt, streams the result and exits — which makes Claude Code a building block for automation: changelog generators, PR summaries, migration checks, overnight refactoring jobs.

# One-shot question about the codebase
claude -p "List every API route that lacks auth middleware"

# Pipe-friendly JSON output for scripts
claude -p "Review this diff for security issues" \
  --output-format json < diff.patch > review.json

# Restrict autonomy for unattended runs
claude -p "Run the test suite and fix flaky tests" \
  --allowedTools "Read,Bash(npm run test:*),Edit"

The --allowedTools flag matters most in automation: grant exactly the tools the job needs (read files, run tests, edit code) and nothing else — no unrestricted shell, no writes to production systems. Combine headless mode with your guard hooks and you get agents that can work overnight on a branch and hand you a reviewed, tested pull request in the morning. Start those jobs on throwaway branches, measure how often their output survives your review, and expand their permissions only as the evidence justifies it. Autonomy in production is a dial you turn slowly, not a switch you flip once.