How to use Claude Code: setup, context, and parallel work

The short version: install Claude Code, run claude inside a project directory, log in with a Claude subscription, and describe what you want in plain English. That takes about five minutes. Most guides on how to use Claude Code stop roughly there, and that is the easy half. The rest of this one covers what decides whether the tool is still earning its place a month later — context that survives a fresh session, permissions you can live with, and running several sessions at once without them stepping on each other.

Every factual claim below is checked against Anthropic's official documentation as of July 2026, and links to it where the detail matters. Claude Code ships often enough that specific flags move; where behaviour is version-dependent, trust the linked docs page over this one.

What is Claude Code?

Claude Code is Anthropic's agentic coding tool: a terminal program that reads your files, runs commands, edits code, and works through a task while you watch or step away. It is not autocomplete, and it is not a chat window with a copy button. You describe an outcome, and it explores, plans, implements, and reports back.

That difference matters more than it sounds. With autocomplete you stay the author and the tool speeds up your typing. With an agent you become the reviewer, and the skills that pay shift from writing code to specifying work and checking output. Most of the friction people hit in week one comes from driving it like the first thing while expecting the second. That shift is not specific to this tool — what changes in your day when you hand over a goal instead of a line is the general pattern, and what an agent actually is, and what it cannot do is the definition underneath it; this guide is the Claude Code specifics.

This guide covers the terminal CLI. The same agent also runs on the web, in a desktop app, in VS Code and JetBrains, in Slack, and in CI through GitHub Actions and GitLab — the quickstart lists every surface. The concepts carry across; the exact commands are terminal-specific. If you are choosing between this and an AI editor rather than adding it to one, the head-to-head with Cursor is the other half of that decision.

One constraint underpins nearly every practice here: Claude's context window holds the entire conversation — every message, every file it reads, every command output — and its answers get worse as that fills. Almost everything below is context management wearing a different hat.

How do you install Claude Code?

Run the native installer for your platform, then confirm it worked with claude --version. On macOS, Linux and WSL that is one curl command; Windows has PowerShell and CMD equivalents. Homebrew and WinGet packages exist too, but neither auto-updates, so upgrading becomes your job rather than the installer's.

# macOS, Linux, WSL
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

# confirm it landed
claude --version

Native installs update themselves in the background, which is the main reason to prefer them. Homebrew ships two casks — one tracking the stable channel, one tracking latest — and you upgrade either with brew upgrade. On native Windows, installing Git for Windows is recommended so Claude Code can use Bash as its shell tool; without it, it falls back to PowerShell.

Do you need an API key or a subscription?

A subscription is the cheaper path for sustained daily use, and it is where most people should start. Claude Code accepts a Claude Pro, Max, Team or Enterprise plan, a Claude Console account billed per token, or an enterprise cloud provider. Run claude, follow the browser prompt, and your credentials are stored locally.

The difference is structural rather than a matter of any particular price. A subscription is a flat monthly amount for whatever you do inside the plan's limits. Console access is metered per token, so a heavy afternoon is a bigger bill than a quiet one. If you intend to keep an agent working for hours a day — which is the premise of the second half of this guide — flat beats metered, and an API key is best kept as the fallback for automation that cannot use an interactive login. Which tier that means, and whether the $100 one pays for itself, is worth ten minutes of arithmetic before you upgrade.

To switch accounts or re-authenticate later, type /login inside a running session.

How to use Claude Code in your first session

Start Claude in the project root, ask it to explain something before you ask it to change anything, then give it a task with a check it can run. That check is the hinge between a session you must supervise and one you can walk away from: a test command, a build exit code, a screenshot to compare.

cd ~/code/your-project
claude

Anthropic's best practices page recommends a four-phase loop, and it holds up: explore, plan, implement, commit. Plan mode is what separates the first two from the second two — Claude reads files and proposes an approach without touching your source. Start a session in it with claude --permission-mode plan, or press Shift+Tab mid-session to cycle default → acceptEdits → plan.

Planning is not free, though, and the docs say so plainly: if you could describe the diff in one sentence, skip it. Plan mode earns its overhead when the change spans several files or you are unfamiliar with the code.

The other habit worth forming immediately is specificity. The gap between a mediocre session and a good one is usually the prompt:

Three session commands are worth knowing on day one. Esc stops Claude mid-action with the context preserved, so you can redirect instead of starting over. /rewind (or Esc twice) restores earlier conversation or code state. /clear resets the context window between unrelated tasks — and if you have corrected the same mistake twice, clearing and rewriting the prompt beats correcting a third time, because by then the context is full of the failed attempts.

How do you give Claude Code context that survives?

Write a CLAUDE.md at the project root. Claude reads it at the start of every session, so it is where build commands, conventions and non-obvious gotchas belong. Keep it under about 200 lines — the memory docs are explicit that longer files reduce adherence, because the rules that matter get buried.

Run /init to generate a starting file from your codebase, then refine it. The test to apply to each line is the one the best-practices page gives: would removing this cause Claude to make a mistake? If not, cut it. A bloated CLAUDE.md is worse than a short one, because it teaches Claude that most of the file is skippable.

These files can live at several scopes, and all of the ones on the path are concatenated rather than overriding each other:

Two details catch people out. First, Claude Code reads CLAUDE.md, not AGENTS.md. If your repo already standardises on AGENTS.md for other agents, do not duplicate it — create a CLAUDE.md that imports it with @AGENTS.md on the first line, or symlink the two files. Second, instructions are context, not enforcement. Claude reads CLAUDE.md and tries to follow it; there is no guarantee. For something that must happen every time without exception — a linter after every edit, a block on writes to a migrations folder — write a hook instead. Hooks run as shell commands at fixed lifecycle events and fire regardless of what the model decides.

When an instruction seems to be ignored, run /context and check whether the file actually loaded before you rewrite it. A rule in a file Claude never read is not a wording problem.

For larger repos, .claude/rules/ splits instructions into topic files, and a rule can carry a paths frontmatter glob so it only loads when Claude touches matching files. That keeps the always-on context small while the specific guidance still arrives when it is relevant.

How should you set up permissions?

Claude Code asks before it runs a Bash command or writes a file. Safe, and tedious fast — by the tenth approval you are not reviewing, you are clicking. The fix is not switching approvals off but allowlisting what you already trust: /permissions in a session, or a permissions block in .claude/settings.json you commit.

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "deny": ["Bash(git push *)"]
  }
}

Rules are evaluated deny, then ask, then allow, and the first match wins — specificity does not change the order. A broad deny cannot carry allowlist exceptions, so Bash(git push *) above blocks every push even if a narrower allow rule matches. The permissions reference covers the full pattern syntax, including the trap that the space matters: Bash(ls *) matches ls -la but not lsof.

Alongside rules there are modes, set per session or as defaultMode in settings:

That last one deserves the warning the docs give it: it skips prompts including for writes to .git, .claude, .vscode and similar directories, and Anthropic's guidance is to only use this mode in isolated environments like containers or VMs where Claude Code can't cause damage. A handful of circuit breakers still fire — rm -rf / and rm -rf ~ still prompt — but treat that as a backstop, not a safety net.

If you want fewer prompts without the blunt instrument, auto mode and OS-level sandboxing are the two middle options, and both keep a real boundary in place.

How do you run more than one Claude Code session at once?

Give each session its own git worktree so file edits cannot collide. Claude Code has this built in: claude --worktree feature-auth creates a worktree under .claude/worktrees/ on a new branch and starts a session inside it. Run the same command with a different name in a second terminal and you have two isolated sessions on one repository.

# terminal one
claude --worktree feature-auth

# terminal two
claude --worktree fix-flaky-test

The reason this is necessary is worth stating, because it is the thing most first-time parallel setups get wrong. Two agents in one checkout share one working tree and one HEAD. One of them runs git checkout or git stash and the other's uncommitted work moves under it. One runs the test suite while the other is mid-edit and gets a failure that belongs to neither of them. Nothing warns you; you just spend an afternoon debugging a phantom. A worktree is a separate working directory with its own files and branch, sharing the same history and remote, so the failure mode disappears by construction. If you have never used them outside this flag, the mechanics, the gotchas, and where to put them on disk are worth reading once — the tax is the gitignored files a fresh checkout does not carry.

Two practical notes from the worktrees docs. A worktree is a fresh checkout, so gitignored files like .env are not there — add a .worktreeinclude file (gitignore syntax) at your project root and Claude copies the matching gitignored files into every worktree it creates. And add .claude/worktrees/ to your .gitignore so the worktrees do not surface as untracked files in your main checkout.

On exit, Claude checks the worktree for changed files, untracked files or new commits, and prompts you to keep or remove it. Non-interactive runs with -p have no exit prompt at all, so those worktrees stay until you run git worktree remove.

Worktrees are one of several parallel approaches, and they solve exactly one problem:

Subagents deserve a specific mention, because they solve the other half of the parallelism problem. When Claude explores a large codebase it reads a lot of files, and all of them land in your context. A subagent explores in its own context window and reports back a summary — use a subagent to investigate how our auth system handles token refresh — so your main conversation stays clean for the implementation.

What breaks when you go from two sessions to ten?

Not the agent — the process around it. Worktrees solve file collisions and nothing else. At two sessions you hold the whole picture in your head. Past about four, the expensive part is knowing which terminal is blocked on a question, what each was asked to do, and which branches are waiting on a review.

This is where we should be honest about our own position, because the ground moved. Worktree isolation used to be the differentiator for tools in our category; it is now a flag on Claude Code itself, and the desktop app gives every new session its own worktree without being asked. If per-session isolation is all you need, you do not need us — use --worktree and stop reading.

What is still unsolved is the layer above it. Six terminals is six mental stacks. There is no shared view of which work is in flight, no place a plan and its acceptance checks live next to the branch that implements them, and no path from "the agent says it's done" to a reviewed, merged pull request that does not run through your short-term memory. Every one of those is a coordination problem, not a code-generation problem, and coordination is the thing that stops scaling first.

Fredrin is the bet that this layer is worth building as a product: a desktop kanban where a ticket owns its branch, its worktree, and one agent session, and where the loop ends at a merged PR with CI status on the card rather than at a diff on your laptop. You bring the agent — Claude Code, Codex, Cursor or Copilot on a subscription you already pay for. We wrote up the reasoning in more detail in cmux solved spawning; Fredrin solves shipping, and the context argument in the unified context layer. If your day is mostly one deep session in an editor, Cursor is a better fit and we say so on the comparison page.

How do you review what Claude Code produces?

Read the diff, not the transcript. The transcript records how the model got there; the diff is what you are shipping. Ask for evidence rather than a claim — the command it ran and what it printed — and have a fresh session review the change, so the thing that wrote the code is not grading it.

The evidence habit is the one that pays back fastest. "Tests pass" is an assertion. The test output pasted into the conversation is a fact you can check in three seconds, and it works for sessions you were not watching.

For the second opinion, a reviewer in a fresh subagent context sees the diff and your criteria but not the reasoning that produced the change, so it evaluates the result on its own terms. The bundled /code-review skill does this for correctness; for a plan-conformance check, write the prompt yourself and name what counts as a finding. Every reviewer in that category comments rather than blocks, deliberately — what the bots catch, and what they leave to you is the longer version.

One caveat the docs are refreshingly blunt about: a reviewer asked to find gaps will usually find some, whether or not they are real, because that is the job you gave it. Chasing all of them produces defensive code and tests for cases that cannot happen. Tell the reviewer to flag only what affects correctness or your stated requirements, and treat the rest as optional.

Finally, keep git in the loop. Claude's checkpoints snapshot files before each edit, but they only track changes made through its own file-editing tools — anything done through a Bash command or an external process is not captured. Checkpoints are an undo button, not version control.

FAQ

Is Claude Code free? No. It requires an account: a Claude subscription (Pro, Max, Team or Enterprise), a Claude Console account billed per token, or access through a supported enterprise cloud provider.

Do I need to know how to code to use Claude Code? Not to get output, but yes to ship it. The agent writes and runs code from a plain-English description; the part you cannot delegate is judging whether what came back is correct and safe to merge.

Why does Claude Code forget what I told it earlier? The context window fills, and long conversations get compacted into a summary. Anything you want in every session belongs in CLAUDE.md rather than in chat, and /clear between unrelated tasks keeps the window from filling with work that is already done.

How do I stop Claude Code from making a change I did not ask for? Press Esc to interrupt it with context intact, /rewind to restore the previous conversation or code state, or start in plan mode so nothing touches disk until you approve. For a hard boundary, add a deny rule in .claude/settings.json — rules are enforced by Claude Code itself, not by the model.

How many Claude Code sessions can I run at once? There is no fixed limit. The practical ceiling is your machine and your attention: worktrees stop the sessions from colliding on files, but nothing stops you from opening more terminals than you can review.

Fredrin is in closed alpha on macOS. BYOS — Claude Code, Codex, Cursor, and Copilot runtimes, on the subscription you already pay for. If you are already running several Claude Code sessions a day and the reviewing is what hurts: fredrin.com.