Getting Started With Claude Code in the Terminal

Install it

Claude Code runs in your terminal. Pick one method — the native installer is the recommended one and it auto-updates in the background.

macOS, Linux, WSL:

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

Two alternatives, both of which do not auto-update — you have to upgrade them yourself for features and security fixes:

brew install --cask claude-code        # then: brew upgrade claude-code
winget install Anthropic.ClaudeCode    # then: winget upgrade Anthropic.ClaudeCode

Debian, Fedora, RHEL and Alpine can also install through apt, dnf, or apk.

Confirm it worked:

claude --version

That prints a version number followed by (Claude Code).

Two Windows notes that save confusion. If you see The token '&&' is not a valid statement separator, you are in PowerShell and ran the CMD command. If you see 'irm' is not recognized, you are in CMD and ran the PowerShell one — your prompt shows PS C:\ in PowerShell and plain C:\ in CMD. And on native Windows, installing Git for Windows is recommended so Claude Code can use the Bash tool; without it, it falls back to PowerShell. WSL setups do not need it.

Log in

claude

First run prompts you to authenticate in the browser. Credentials are stored, so this is a one-time step. To switch accounts later, type /login inside a running session.

You can sign in with a Claude subscription (Pro, Max, Team, Enterprise — the recommended route), a Claude Console account with pre-paid credits, or through Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry if your organisation uses one.

One gotcha: if ANTHROPIC_API_KEY is already set in your environment, Claude Code skips the login prompt and asks you to approve that key instead. If you meant to use your subscription, unset the variable first.

Your first session

cd /path/to/your/project
claude

Start in a real project, not an empty directory. Claude Code reads files as it needs them — you do not paste anything in, and you do not add files to context manually.

Before asking it to change anything, ask it to explain something. This is the fastest way to calibrate whether you can trust it here:

what does this project do?

where is the main entry point?

explain the folder structure

Then a small change:

add input validation to the user registration form

In your first session it asks before each change. Approve them one at a time and read what it is doing — that first session is where you learn what it does well and what it guesses at.

Permission modes, and Shift+Tab

This is the setting that most changes how the tool feels, and most people find it by accident.

After your first session, auto mode is the built-in starting mode for interactive terminal sessions on Pro, Max and Team plans: a classifier reviews actions instead of you, and Claude edits most files and runs most commands without asking. On other plans, Manual mode is the starting point. Your own settings or your organisation can change this.

Press Shift+Tab at any time to cycle the mode. That is the whole control.

How to use it in practice: stay in a mode that asks while you are learning what the tool does in your codebase. Move to auto once you have a sense of it. Drop back to a stricter mode whenever you are somewhere consequential — auth, payments, migrations, deploy scripts. The mode is per-session and free to change mid-task.

Plan mode deserves its own mention. It lets Claude research and propose without touching anything, which is the right default for any change large enough that you would not want to read the diff cold.

The commands you will actually use

Shell commands, run from your terminal:

Session commands, typed inside Claude Code:

claude -p is more useful than it looks, because it composes with everything else your shell can do:

git log --oneline -20 | claude -p "summarise these commits for a release note"

That is the entry point to scripted use — running Claude Code in a loop, in a git hook, or in CI.

Keyboard shortcuts worth learning on day one

Typing / and reading the list is the single best five minutes a new user can spend. Most people do not discover what is available for weeks.

What to do in your first week

An order that builds judgement before it builds dependency.

Days 1–2: ask, do not tell. Use it as a codebase question-answering tool. "What calls this function?" "Why does this test fail?" "What would break if I changed this?" You learn where it is reliable at zero risk.

Day 3: small, verifiable changes. A bug with a reproduction. A function with tests. Something where "did it work?" has an unambiguous answer.

Day 4: ask for a plan first. Before any change touching more than one file, ask for the plan and read it. This habit is what separates people who get good results from people who get large diffs.

Create an implementation plan for this. Break it into steps that are each
independently reviewable and independently revertible. Do not implement
anything yet — I want the plan first.

Day 5: write a CLAUDE.md. The moment you notice yourself explaining the same convention twice, it belongs in a file the tool reads every session. Creating a production CLAUDE.md covers what belongs in it and — more importantly — what does not.

Rest of the week: git. Let it handle commits, branches, and history questions. It is genuinely good at this and it is low risk because everything is recoverable.

what files have I changed?
commit my changes with a descriptive message
create a new branch called feature/checkout-validation

Five beginner mistakes

Asking for too much at once

"Build the whole feature" produces a diff nobody reviews. The output is often fine; the problem is that you cannot check it. Stage the work into steps you can read.

Describing the solution instead of the problem

"Add a cache here" forecloses the possibility that the query needs an index. Describe the symptom and the constraint, and ask for approaches.

Accepting "done" without evidence

"Tests pass" is a claim. Ask for the output. Then get in the habit of asking "what did you not verify?" — the answer is often the most useful line in the response.

Staying in a mode that asks about everything

Approving forty prompts in a row trains you to stop reading them, which is worse than auto mode. Move up once you trust it, and drop back deliberately for risky work.

Re-explaining the project every session

If you are typing the same context repeatedly, that is the signal it belongs in CLAUDE.md. This is the most common reason people conclude the tool is inconsistent — it is being told different things each time.

When you outgrow the basics

The tool has considerably more depth than the quickstart shows, and it is worth knowing what exists so you recognise the moment you need it.

None of that is needed on day one. All of it becomes obvious at the moment the problem it solves shows up.

Where to go next

The natural next step is a real project end to end — how to build a website with Claude Code covers the full sequence. For directing it well, the prompt library has 27 worked examples. If you are still deciding whether an agentic tool is even the right category for you, vibe coding tools and platforms compares the alternatives.

Sources and further reading

• Claude Code: quickstart — install, login, first session
• Claude Code: CLI reference
• Claude Code: permission modes
• Claude Code: troubleshoot installation