Setting up Claude Code in 2026: install, CLAUDE.md, skills, hooks, memory

Setting up Claude Code properly takes about thirty minutes, and that half hour separates an agent you can trust with real work from one that merely has access to your files. This is the setup I’d give a colleague on day one: install, authenticate, /init, skills, hooks, memory, and the git discipline that makes all of it safe, with every step checked against the official quickstart as of July 2026.

One framing thought before the commands: most setup guides treat the install as the point. The install, however, takes two minutes; the configuration (instruction file, hooks, git habits) is what determines whether the agent works reliably. Most of the thirty minutes should therefore go there.

Step 1: Install the CLI

The CLI (command-line interface) ships as a native installer on all platforms, and it auto-updates in the background:

macOS, Linux, WSL (Windows Subsystem for Linux):

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

Windows PowerShell:

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

Windows CMD:

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

Package managers work too: brew install --cask claude-code, winget install Anthropic.ClaudeCode, and apt/dnf/apk on Linux, but note they don’t auto-update; upgrades become your responsibility. On native Windows, install Git for Windows first so the agent gets a real Bash tool instead of falling back to PowerShell.

A Windows pitfall the docs now call out explicitly: the PowerShell command fails in CMD and vice versa. If you see 'irm' is not recognized, you’re in CMD; if you see The token '&&' is not a valid statement separator, you’re in PowerShell. Match the command to the prompt (PS C:\ = PowerShell).

Step 2: Run it and authenticate

cd your-project
claude

First run prompts a browser login. You can authenticate with a Claude subscription (Pro/Max/Team/Enterprise, the recommended route), a Console account with prepaid API credits, or enterprise cloud providers (Bedrock, Google Cloud, Foundry). Credentials persist; /login inside a session switches accounts later.

Sanity-check the setup with a question, not a task:

what does this project do?

If it reads your files and answers sensibly, the setup works.

Step 3: /init generates your CLAUDE.md

Run /init in your project root. It analyzes the codebase (build system, test framework, conventions) and generates a starter CLAUDE.md, the instruction file the agent reads at the start of every session. If the repo already has an AGENTS.md (the cross-tool convention) or other agents’ configs like .cursorrules, /init reads and incorporates them.

Then edit it down. The generated file is a starting point, and the official guidance is strict: target under 200 lines; for every line ask “would removing this cause mistakes?” Keep the build/test commands the agent can’t guess, the facts that contradict appearances, and the rules with consequences. Cut everything derivable from the code. I’ve written a full guide on instruction files, but if you take one thing: a short file the agent follows beats a long one it ignores.

Step 4: Install skills and plugins

Claude Code’s plugin system is an app-store model: marketplaces are catalogs, plugins install individually. The official Anthropic marketplace is available out of the box, run /plugin and browse the Discover tab, or install directly:

/plugin install github@claude-plugins-official

What is worth installing on day one:

• A code-intelligence plugin for your language, pyright-lsp, typescript-lsp, rust-analyzer-lsp, gopls-lsp, etc. These wire a language server to the agent over LSP (the Language Server Protocol), and the payoff, as the plugin docs describe, is automatic: “after every file edit Claude makes, the language server analyzes the changes and reports errors and warnings back automatically”, the agent sees its own type errors and fixes them in the same turn. You need the language-server binary installed on your system.
• security-guidance, reviews each change the agent makes for common vulnerabilities, in-session.
• Your ecosystem’s integrations, github/gitlab, and the pre-configured MCP (Model Context Protocol) bundles (linear, sentry, figma, supabase, …) only for services you use.

The community marketplace adds third-party plugins (/plugin marketplace add anthropics/claude-plugins-community), each pinned to a vetted commit.

Two cautions from daily use. First, the docs’ own warning: plugins “can execute arbitrary code on your machine”, install from sources you trust, and review the Will install listing before confirming. Second, every installed plugin costs context tokens every turn: the install dialog now shows a per-plugin context-cost estimate, and recent versions flag plugins you haven’t used in two weeks. Don’t “install everything”: install what you’ll invoke, audit with /plugin occasionally, and uninstall the unused ones. My own config has shed more plugins than it’s kept.

Step 5: Wire your first hooks

Instruction files are advisory; hooks are not. The docs draw the line cleanly: hooks are for “actions that must happen every time with zero exceptions”, they run as shell commands at fixed lifecycle points regardless of what the model decides.

You don’t need to learn the config format, the agent writes its own hooks. Try, verbatim:

Write a hook that runs our linter after every file edit

Write a hook that blocks any edit to the migrations folder

Then run /hooks to see what’s configured. My rule for what deserves a hook, from the practices guide: every time the agent violates a written rule with real consequences, convert that rule into a hook. Day one, two hooks are plenty, a post-edit formatter/linter and a block on whatever directory must never be touched. The rest accumulate from experience.

Step 6: Understand the two memories

Claude Code carries knowledge across sessions in two ways, and knowing which is which saves confusion:

• CLAUDE.md, instructions you write (step 3). Loaded every session, versioned in git, shared with your team.
• Auto memory, notes the agent writes itself: build commands it discovered, debugging insights, your corrections. On by default, stored per-project in ~/.claude/projects/<project>/memory/, plain markdown you can read, edit, or delete.

Run /memory to see both, every instruction file loaded in the session, plus a browser for the auto-memory folder. When you tell the agent “always use pnpm, not npm,” that lands in auto memory automatically; when you want something in CLAUDE.md instead, say “add this to CLAUDE.md.”

The practical habit: audit your auto memory occasionally. The agent’s notes are usually good, but it records what it believed at the time, a stale memory (“tests are flaky on CI”) outlives the fix unless you prune it.

Step 7: Git discipline

This is the step beginner guides skip, and it’s the one that lets you give the agent real autonomy. Two layers:

Layer 1: checkpoints (built in). Every prompt creates a checkpoint; Esc Esc or /rewind restores conversation, code, or both to any previous point. This is what makes trying the risky approach cheap: if it doesn’t work, rewind. Checkpoints, however, only track changes made by Claude, not external processes, and the docs state plainly that they are not a replacement for git. Your own edits, script side effects, and generated files are all invisible to checkpoints.

Layer 2: git (the real safety net). Work inside an existing git repo, always, if the project isn’t one, git init before the first agentic session, not after. Then three habits:

1. Branch before nontrivial agent work. Ask the agent itself: create a branch called feature/x and work there. Rollback becomes git checkout main instead of a file-by-file reconstruction.
2. Commit at every green state. The moment tests pass, commit (the agent writes decent commit messages, just ask). Frequent small commits turn “undo the last 40 minutes” into git reset --hard HEAD~1.
3. Never let a session end dirty. Uncommitted work in a repo an agent touches is work that can be silently overwritten, by the next session, by another agent, by you. I lost work to this once, and my repos now enforce it with a hook (step 5).

Git operations themselves are conversational, what files have I changed?, commit my changes with a descriptive message, show me the last 5 commits, so the discipline costs almost nothing to keep.

The 30-minute checklist

□ Install CLI (native installer; Git for Windows if on Windows)
□ claude → authenticate (subscription or Console)
□ /init → edit CLAUDE.md down to what's load-bearing
□ /plugin → code-intelligence for your language + security-guidance
□ Two hooks: post-edit lint, block-the-untouchable-directory
□ /memory → confirm what's loaded; know where auto memory lives
□ git repo confirmed; branch-per-task habit; commit at green

From here, the leverage moves from setup to practice, which is its own guide: verification loops, plan mode, and context discipline are the next techniques to put in place.

---

Changelog: 2026-07-01: first published. 2026-07-05: register pass; expanded CLI, WSL, LSP and MCP at first use, reworked the opening and the close. No factual changes. 2026-07-06: attached inline sources to three quoted doc passages, de-pitched the opener, de-idiomed the git note.