Guide

Install Claude Code and Run Your First Session

Install Claude Code, run a real first session in your own project, and see what skills are available.

~6 min read

A terminal window showing the Claude Code install command followed by a version check.

You have used Claude in a browser tab. Somebody told you there is a terminal version that is different in kind, not in degree, and you have been meaning to find out what that means. Fifteen minutes from now it will be installed, signed in, and answering questions about code sitting on your own disk.

What Claude Code actually is

Claude Code is Claude running in your terminal, inside a project directory, with access to the files in that directory. That is the whole difference, and it is a large one. In a chat window you paste code in and copy an answer out, which makes you the transport layer between the model and your codebase. In Claude Code you ask where sign-up is handled, and Claude opens the route, the handler, and the test, and then answers.

It is a single command-line program. You install it once, change into a project, and type one word to start a session. Everything people talk about later (skills, project memory, connections to outside tools) is built on top of that one habit.

Install it: the native installer is the current path

Anthropic ships a native installer for each platform, and that is the current recommended route. The reason to prefer it is unglamorous: it updates itself in the background, so the version you are running six months from now is not the version you installed today. Pick the line that matches your machine.

Comment: macOS, Linux, or Windows Subsystem for Linux
Command: curl -fsSL https://claude.ai/install.sh | bash
Comment: Windows PowerShell
Command: irm https://claude.ai/install.ps1 | iex
Command: claude --version
Output: 2.1.x (Claude Code)
Note: A version number followed by (Claude Code) means the install worked.
Run one of these, then confirm the binary is on your PATH.

If your shell reports that the command was not found, open a fresh terminal window so it picks up the updated PATH, then try again. On Windows Command Prompt rather than PowerShell, the installer is a downloaded batch file instead:

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

Other routes exist, and they share one tradeoff: none of them update in the background. Whichever you pick, updating becomes a thing you have to remember.

  • Native installer: recommended, and the only one of these that updates itself for you.
  • Homebrew on macOS: brew install --cask claude-code. There are two casks. The claude-code cask tracks stable and runs roughly a week behind the newest build, while claude-code@latest tracks the newest.
  • WinGet on Windows: winget install Anthropic.ClaudeCode.
  • Linux package managers (apt, dnf, apk): documented on the Claude Code setup page rather than the quickstart, and grouped with the other alternatives that do not self-update.

If you go a package-manager route, updating is on you. Run claude update, or your package manager’s own upgrade command, on whatever schedule you can actually keep.

What older tutorials get wrong about npm

Search for how to install Claude Code and most of the results still open with npm install -g @anthropic-ai/claude-code. That is no longer the headline method. The current quickstart offers native install, Homebrew, and WinGet, and does not list npm as an install option at all. Where npm still shows up in the documentation, it shows up as one of several ways to update an install you already have.

Here is the honest edge of what we can confirm. The npm package is documented as an update path, and we cannot say with confidence whether a fresh npm install still produces a fully supported setup. So: if you already installed through npm and it works, keep it and update it with npm install -g @anthropic-ai/claude-code@latest. If you are starting from nothing today, use the native installer and the question never comes up.

First launch and signing in

Change into a project directory before you launch. Claude Code is scoped to where you start it, so launching from your home folder gives it a home folder’s worth of context, which is not useful to anybody. Use a real repository you know well, ideally one where you already know the answer to your first question.

Command: cd ~/projects/storefront
Command: claude
Output: (a browser window opens for you to log in)
Output: Login successful
Note: Then press Enter to continue. Exact screens vary by version.
The first run opens a browser. You sign in once per machine.

You can sign in with a Claude Pro or Max subscription, a Claude for Teams or Enterprise account, or Claude Console credentials. If no browser opens, the terminal prints a URL you can paste into one yourself. After that the credentials persist, so this is a once-per-machine step: /login re-authenticates later, and /logout is its counterpart.

Your first real session, in a real project

Now ask something you actually want to know about the code in front of you. Not a hello world, and not a general programming question you could have asked in any chat window. Ask where something lives, or why a specific thing behaves the way it does. Then ask for a small change, because that is where the session stops and checks with you.

You type: where does this project handle sign-up, and what validates email?
Output: Reading src/routes/signup.ts and lib/validate.ts
Output: Sign-up is handled in src/routes/signup.ts. Email validation
Output: happens in lib/validate.ts, not in the route itself.
Note: No prompt for that. Reads inside your project do not ask.
You type: add a comment above validateEmail saying what it rejects
Output: Claude wants to edit lib/validate.ts
Output: Allow? Yes / Yes, and don’t ask again / No
Note: Wording varies by version. The point is that edits ask first.
Reading is quiet. The edit is what stops and asks.

That interruption is the part that catches people, and the shape of it is worth learning on day one, because it is what makes the tool safe to leave running.

  • Reads are quiet, changes are not. A fresh install starts in the default permission mode: in practice reading files inside your working directory is the quiet part, and edits and shell commands are what stop to ask.
  • Approving an edit is not a blanket grant. The “don’t ask again” option narrows future prompts rather than opening everything, and /permissions shows you which rules are actually in force. Open it once after your first approval, so you know what you agreed to.
  • After your first session the mode changes. On Pro, Max, and Team plans in a terminal, later sessions start in auto mode, where a second model reviews actions instead of prompting you. Shift+Tab switches modes mid-session, and /permissions shows the rules currently in force.

Two commands worth typing on day one

/help lists what the session can do. Read it once, on the first day, even if you retain almost none of it. Knowing the list exists and where to find it is most of its value, and you will come back to it.

/init is the other one. It generates a starting CLAUDE.md: a plain Markdown file at your project root that Claude reads at the start of every session in that project. If you already have one, read what it proposes before you accept it. Then you edit it, because the things worth writing down are usually the ones Claude could not discover. Treat the file as context and not as enforcement: Claude tries to follow it, and nothing forces it to.

You type: /help
Output: The commands and settings this session supports.
You type: /init
Output: Analyzes the codebase and writes a starting CLAUDE.md.
Note: Open the generated file and edit it. It is yours to maintain.
One command tells you what exists. The other writes your project’s memo.

Ask what skills you have, then go build one

One more question before you close the terminal. Ask the session what it can already do.

You type: what skills do you have available?
Output: A list of the skills this session can currently see. On a new
Output: install those are the bundled ones, with names like code-review,
Output: security-review, and doctor. The exact set varies by version.
You type: /skills
Note: Same question as a command. Your own skills appear here too.
On a fresh install every skill in the list is a bundled one. None are yours yet.

A skill is a folder with a SKILL.md file inside it, describing when Claude should reach for it and what to do once it does. What that file looks like, and why the split between the trigger line and the instructions is the whole design, is the first two lessons of the beginner path.

You want one the third time you retype the same instructions. Every project has a procedure somebody re-explains: how release notes get worded here, what a bug report must contain before anyone triages it, the five checks before a deploy. Written once as a skill, that procedure becomes something you or Claude can reach for by name, in any session, without the retyping and without the slow drift that comes from explaining it slightly differently each time.

The beginner path builds one real skill end to end, from empty folder to a verified trigger. It is the next thing to read, and it is linked below.

Stay updated

Get new guides in your inbox

One task, one guide, done fast. Practical Claude Code skills, zero noise.