CLAUDECODE101 · chapter 1 of 21 · free to read

Getting Started — Your First Session

This is the whole chapter, not a sample of it. Nothing is shortened for the showcase and nothing here is recorded — no account, no cookie, no reading history. Every chapter of this ladder was signed by a named person before it was served; this one by Capt Anil Sharma.

Before anything else: you do not need this course to use Claude Code. A ladder of twenty-odd chapters standing in front of a tool implies a wait that is not real, so let us remove it now.

Claude Code is aim and shoot. Install it, go to a project, type claude, and say what you want in ordinary English. That is the whole of getting started, and people do useful work on that alone within an hour.

So what are the other chapters for? Not how to start — what you do not know you do not know. Those are different things, and only the second needs a course. Read this ladder the way you would read the manual of a machine you already operate: chapters 1 to 4 early, everything after that as reference for when something surprises you, or before you do something you cannot undo. Nothing here is a gate you pass before you are allowed to work.

WHAT THIS CHAPTER ASSUMES YOU ALREADY HAVE

You have finished CodeAI101, so five things are not explained again here, and you should notice that they are not.

You know what a tool call is and that a model deciding to act is different from a model producing text — Day 3. You know that an agent loops on its own until it reaches a goal or hits a limit — Day 4. You know what a context window is and that what a model cannot see, it cannot use — Day 2. You know that approval gates come in tiers and that irreversible actions belong behind the strictest one — Day 3 again. And you know the whole of Day 1: fluent output is not evidence of correct work.

Claude Code is those ideas wearing a specific shape. This ladder does not re-teach them. It shows you where they live in one particular tool, what that tool calls them, and where its defaults sit — which is the only part a course can usefully add once you have the mechanism.

WHAT YOU NEED, AND WHAT YOU DO NOT

You need a machine you control, a terminal with Node and npm on it — check both before you start:

node --version
npm --version

and your own Anthropic account — billed by Anthropic to you. The course fee, wherever you paid one, buys the course and never the tokens. ANKR provides no machine, no key, and no proxy for this ladder, and that is stated on the course card before you pay for exactly this reason.

You do not need to be a programmer. You do not need a project ready. A directory with a few files in it is enough to follow every step below.

INSTALL, AND THEN PROVE IT INSTALLED

Installing is one command:

npm install -g @anthropic-ai/claude-code

Three failures account for almost all of them. A permission-denied error means npm is trying to write somewhere your user does not own — do not reach for sudo, fix the ownership instead. Command not found: npm means Node is not installed or is not on your PATH. And an install that succeeds while the next step still says command not found: claude means npm's global bin directory is not on your PATH — the install worked, your shell simply cannot find what it produced.

There is a second route, claude install, which you do not need today but should know exists.

Then prove it installed, which is not ceremony:

claude --version

Two installations on one machine is the commonest confusion in this chapter, and the symptom is that a version you did not install answers when you ask.

Then run the health check the tool ships with:

claude doctor

It reports what it found — installation, authentication, configuration — and it is the first thing to run whenever the tool behaves differently in one project than another. It is worth running once now, while nothing is wrong, so that you know what a healthy report looks like. A diagnostic you have only ever seen unhappy is a diagnostic you cannot read.

Then sign in:

claude auth login

Your credentials are your own, tied to your own account, and a session that worked yesterday and not today is almost always this and not the tool.

THE STEP EVERYONE SKIPS

Here is the one that matters more than it looks, and the one beginners skip.

THE DIRECTORY YOU START IN IS THE DIRECTORY IT CAN SEE.

Not mostly. The tool reads and writes inside where you started it. Start it in your home directory and it can see everything you own; start it inside one project and it can see that project. So change into the work first, and check where you are before you begin:

cd ~/projects/my-project
pwd

You should see the full path of the project you meant, and nothing else. If you get no such file or directory, the path is wrong — use ls to look around before starting a session, not after.

Start in the narrowest directory that contains the work. Not because the tool is reckless — chapter 4 is about the controls, and they are real — but because scope you never granted is scope you never have to think about. This is Day 3's approval discipline in its simplest possible form: the cheapest gate is the one you set before anything runs.

YOUR FIRST SESSION

Type claude, and the interface opens with a prompt waiting. Ask it something small and observable — what files are in this directory, and what is this project? — and then watch what happens rather than reading the answer.

It will run a command or two, show you the output, and then tell you in prose what it concluded. That sequence is the whole shape of the tool: it acts, it shows you the acting, then it summarises. Everything in the rest of this ladder is about the gap between the second and the third.

To leave, press Ctrl+C twice, or type /exit.

AND THE THING MOST PEOPLE MISS FOR WEEKS

A session is not lost when you close it.

claude --continue

That resumes your previous conversation in this directory, with everything it had learned about your project still in place. If it starts something empty instead, you are almost certainly in a different directory than last time — the same pwd problem as above, wearing a different coat.

To pick from earlier sessions rather than taking the most recent, use claude --resume, which lists them. An empty list means no prior sessions exist for this directory, which is again the same problem. Chapter 7 covers sessions properly, including forking one so you can try two approaches from the same starting point.

TELLING WHAT KIND OF PROBLEM YOU HAVE

You will hit something this chapter does not cover. The useful skill is not knowing every failure — it is telling what kind of problem you have, because each kind has a different first move.

Read that table as five categories rather than five fixes. Three of the five are not faults in the tool at all — they are the shell, the account, or the directory. Chapter 17 is entirely about that distinction, because getting the category right is most of the repair.

THE ONE HABIT

Here it is, and it is worth more than any flag in this chapter.

WATCH THE COMMANDS, NOT THE SUMMARY.

You already hold this one. CodeAI101's capstone put it as inspect the result, not the summary, and Day 1 gave you the reason: a model produces fluent text whether or not the work behind it went well. What is new is only where it shows up here. This tool displays every command before or as it runs, and then describes in prose what it did. The commands are the thing that happened. The prose is a description of them, produced by the same machinery that produces everything else it says.

So the habit costs nothing on day one and saves a great deal by day thirty: do not scroll past the commands to read the summary. A summary saying updated the configuration is compatible with several different things having happened, and only one of them is what you wanted. Chapter 16 turns this into a discipline. For now, simply read the top of the block, not the bottom.

That is the whole of getting started. Install it, stand in the right directory, ask for something small, and watch what it does rather than what it says about what it did.