Chapter 1 was about the mental model. This chapter is about doing. There is one goal—getting your first instruction through, against your own repository.
The commands you type come to a few lines. The rest of the time goes into understanding what you are approving. Skip that, and you will be rewinding to it later.
There are five ways in — pick your entry point
Claude Code usually gets introduced as "a terminal tool," but there are five ways in. The thing inside is the same. Only the wrapper changes.
The real thing. Type claude and that is it. This course assumes it.
Lives inside the editor. You read diffs in the view you already know.
Goes into the IntelliJ family. If you develop there, you never leave.
Use it without opening a terminal. You pick the mode from the selector beside the input box.
Reachable even with no dev environment at hand. Same selector for switching modes.
For the first hour, use the terminal. Not because it is more comfortable, but because it tells you more. When something jams, you see the raw message, and the fixes people write down assume the terminal. For how Claude Code sits next to editor-embedded tools such as Cursor or GitHub Copilot, see Chapter 1 of the AI Coding course.
Installing it
The standard route is npm. With Node.js already installed, one line does it (if node -v prints a version, you are ready). The -g means "install it so you can call it from any folder."
npm install -g @anthropic-ai/claude-code
claude
Where a proxy or a regional restriction blocks npm, you can install from a package manager instead.
brew install --cask claude-code # macOS / Homebrew
winget install Anthropic.ClaudeCode # Windows / WinGet
Settle on one install method. Install with npm and then again with Homebrew, and you get Multiple claude installations found. Not knowing which one is running makes every piece of diagnosis after this harder. Requirements differ by environment, so when in doubt go to the official documentation.
Signing in — account or API key
On the first launch you choose how to log in. With a Claude account, a browser opens, and once you sign in and grant access you are authenticated. What you spend is your plan allowance, and it shows up as limits and reset times. An API key runs on a balance rather than an allowance, and stops when it runs out. Personal use points to the first, CI and automation to the second.
Which of the two is available to you depends on your contract, so this is not a rule. There is only one thing to hold on to.
An API key in your environment takes priority over your subscription login. If you once put ANTHROPIC_API_KEY in a shell config for testing and forgot about it, your correct login gets ignored in favor of that key. Most "I am paying for a plan and it says my balance is low" reports are this.
Which credentials you are running on right now is what /status answers. Look before you suspect.
/status # which credentials am I running on
env | grep ANTHROPIC # is a key still sitting in my environment
unset ANTHROPIC_API_KEY # if it is, drop it. remove it from the config file too
/login # sign in again, then confirm with /status
What happens on the first run
Once you are authenticated, move into the folder you want to work in first, then launch. Claude Code treats "the folder you are in" as the target, so get it wrong and it starts reading somewhere unrelated.
cd my-project
claude
The prompt waiting for input is the door into the conversation. Here, do not ask for a rewrite straight away. Make your first move a request that ends in reading only—"Read the README and the main directories and explain what this project does."
Three reasons. Reading needs no confirmation even by default, so it goes through before you know the approval etiquette. You already know this project, so you can mark the answer. And it tests the connection, the authentication, and the working folder in one go, while breaking nothing. If something looks off, you can clear it up before moving on to writes.
The instruct → diff → approve loop
Once reading works, ask for a small rewrite. From here it is the same four beats every time.
Say it in plain English. If you can name where to fix, name it.
It finds and reads the files that look related. That is STEP 1 from Chapter 1.
"Here is what I will change" comes out line by line, and it stops there.
Let it through and it lands. If it is wrong, decline and put the difference into words.
You: "Add a Windows section to the README"
↓
[SEARCH] look for the README ← read. no stop
↓
[READ] read README.md ← read. no stop
↓
[EDIT] add 3 lines to README.md ← a diff appears, and it stops
↓
You: approve / decline and say what to change
Declining is not a failure. Because you can be specific after seeing the diff, you do not have to aim for a perfect first instruction—that is what makes this shape good.
Keep each request to "a diff you can read through." The bigger the request, the longer the diff, and long diffs get approved unread. An approval you pressed without reading is not approval, it is auto-approval. How to split work up is Chapter 3.
Which mode to start in
What decides where it stops is the permission mode. In the terminal you switch with Shift+Tab; in VS Code, the desktop app, and the browser, with the selector beside the input box.
Reads are automatic. Edits and commands are confirmed every time. Use this on day one.
Edits inside the working folder go through automatically. For people who read the diffs together afterwards.
It investigates but does not edit the source. Approve the plan and it moves to doing.
A separate judging model stops only the dangerous operations and lets the rest run unconfirmed. Conditions apply.
Confirmations and safety checks are both off. Isolated environments only. Not something to touch on day one.
What Shift+Tab cycles through is the first three. Auto mode joins the cycle once the conditions are met, and the first time you get an opt-in confirmation. Bypass permissions is only live when you launch with its own flag. To fix a mode from launch, pass claude --permission-mode plan. There is also dontAsk, which never appears in the selector—it runs only what you have allowed, and exists in settings and the CLI only.
The day-one answer is "leave it at the default." Every confirmation is practice at telling a read from a write from an execution. Loosen things once you can tell them apart—do it the other way round, and you are loosening something without knowing what. The second mode to reach for is plan mode.
Some places stay protected in every mode. Writes to sensitive paths such as .git, .claude, and shell config files are never auto-approved in any mode except bypass permissions. Loosening one thing does not loosen everything.
The modes are covered in detail in the article on permission modes, and writing allow and deny rules per tool is in the article on permission rules and settings. And note that bypass is not the answer to "the confirmations are annoying." It defends against neither a slip of your own nor an instruction planted in something it read. To reduce prompts, start by writing rules that allow only the operations you trust. The design work is Chapter 5.
CLAUDE.md — stop repeating yourself
Two days in, you notice you are giving the same warnings over and over. "Do not touch this folder." "Run lint before committing." Typing that each time wastes your time and your context. So put a CLAUDE.md at the root of the project. Claude Code reads it automatically at launch and works on the basis of what is written there.
# This project
- TypeScript / Next.js. Package manager is npm
- Replies and in-code comments in English
## Do not touch
- Anything under src/legacy/ (another team owns it)
- .env and anything derived from it
## Verification
- After a change, run npm run lint and npm test
- Do not call it done while type errors remain
What goes in is decided by "things the AI has no way of knowing."
Which command proves it works. This is the highest-value entry, because it is what makes STEP 3 from Chapter 1 possible.
Generated output, other teams' territory, files holding secrets. Plus conventions the code does not reveal, like "new pages go here."
Things like "write readable code." Nobody can judge whether it was followed, and it only dilutes the lines you really want obeyed.
How to grow it is settled too. Start with a few lines. Give the same warning twice, and add a line. Try to be exhaustive and you end up with a long, vague file that gets ignored. When a file "is not being followed," the cause is usually one of three: too much, too abstract, or self-contradictory.
Permission rules and model choice can live separately in .claude/settings.json (project) and ~/.claude/settings.json (personal), but a few lines of CLAUDE.md is plenty for day one. Choosing between them is Chapter 6.
The three things that break most on day one
People get stuck in predictable ways, and on day one it is nearly always one of these three.
It is installed, but not somewhere you can call it from. Add ~/.local/bin (on Windows, %USERPROFILE%\.local\bin) to your PATH. A duplicate install can cause it too.
The classic: an old ANTHROPIC_API_KEY overriding the subscription. Check with /status, then clear the environment variable and sign in again.
Claude Code burns 10 to 100 times the tokens of a chat. The round trips and the file reads pile up.
The third one gets misread. A message along the lines of "the server is temporarily limiting requests" is a temporary server-side throttle, not your plan allowance, and it clears after a short wait. Whether you actually hit the allowance is what /usage tells you apart.
claude doctor # overall check of install, settings, MCP, and context
/status # which credentials am I running on
/context # a breakdown of what is eating the context
claude update # when in doubt, go to the latest (it fixes a lot)
That last claude update quietly earns its place. A fair number of faults simply vanish on a version bump, so running it before you start investigating saves you from chasing a problem that no longer exists. Symptom-by-symptom fixes are in the article on common errors and their fixes. The diagnostic procedure is Chapter 4.
Summary
- Five ways in. Same thing inside, but for the first hour the terminal wins on how much it tells you
- The standard install is
npm install -g @anthropic-ai/claude-code. If that fails, Homebrew or WinGet. Settle on one method - Sign in with an account (allowance) or an API key (balance). A key in the environment overrides the subscription—when in doubt,
/status - Make your first move a read-only request. It tests the connection, the authentication, and the working folder at once, and breaks nothing
- The cycle is instruct → diff → approve. Split requests down to a diff you can read through. An unread approval is auto-approval
- The day-one mode is the default (ask for permission), the second is plan mode. Protected paths like
.githold in every mode except bypass - Start
CLAUDE.mdat the root with a few lines. Write how to verify, what not to touch, and the local conventions, and leave the platitudes out - Day-one jams are PATH, a key in the environment, and usage. First moves:
claude doctor//status//context
With your first instruction through, the next job is putting this into daily work. Move on to Chapter 3, "The Daily Workflow".