Install / open Claude Code and first run

You cloned a repo at 4:40 p.m. The README says “run the usual install.” Your laptop has three terminals open, one of them stuck on a Node version you swore you uninstalled. A teammate drops a link in Slack: “Just use Claude Code for the onboarding tour.” You do not want a philosophy debate about agents. You want the binary on the path, a login that works, and one clean first session that does not trash the tree.

This is Part 1 of the Claude Code tutorial. We install, open, log in, and survive first run. Part 2 is about talking to a codebase (ask, explore, then change). If you still need the product family map (chat vs Code vs Cowork), start with Claude product map. If everyday Claude chat still feels foggy, use Learn Claude from scratch first, then come back here.

What you’ll learn

What “install Claude Code” actually puts on your machine (and what it does not)
Official install paths as of writing: native curl/PowerShell scripts, Homebrew cask, WinGet
How to verify with claude --version, start in a project folder, and use /login
Where Code shows up beyond the terminal: VS Code, JetBrains, desktop, web
Which accounts can sign in (subscription, Console, cloud providers) and why you should confirm live pricing
Permission modes in plain English, including Shift+Tab cycling default → acceptEdits → plan
A first-run ritual: tiny questions, tiny change, review before commit

Commands and plan names move. Treat everything below as as of writing. Re-check Anthropic’s docs at code.claude.com/docs/en/quickstart and setup the week you roll this out for a team.

What you need before the install

Claude Code is a coding agent that works on real project folders. It is not a second copy of the Claude.ai chat UI with a darker theme. You will get more out of first run if four things are true.

A project directory you are allowed to open. Prefer a personal sandbox or a throwaway clone over production on day one.
An account path that includes Code access: a Claude Pro, Max, Team, or Enterprise style subscription as marketed; a Claude Console account with billing set up; or access through a supported cloud provider your company already uses. Details shift. Confirm on the live pricing and auth pages.
A terminal you can open if you follow the CLI path (Terminal.app, iTerm, Windows Terminal, WSL). If the terminal still feels hostile, use the desktop app or an IDE extension and treat the CLI as optional homework later. Official docs also link a terminal guide for absolute beginners.
Company policy clarity if this is work code. Personal keys in a corporate monorepo is how security tickets are born. If policy is silent, ask before the first PR.

Git helps a lot. On native Windows, Anthropic’s quickstart notes that Git for Windows is recommended so Claude Code can use its Bash tool; without it, PowerShell becomes the shell tool instead. WSL setups do not need Git for Windows for that reason. You can still learn without perfect git habits, but “review the diff before commit” is much easier when git exists.

Install paths (as of writing)

Anthropic’s quickstart lists three common install families for the CLI. Native install is marked recommended and auto-updates in the background. Homebrew and WinGet are first-class alternatives with manual upgrades.

Native install: macOS, Linux, WSL

In a terminal:

curl -fsSL https://claude.ai/install.sh | bash

That one-liner fetches the official install script and runs it. Pipe-to-bash is normal in this ecosystem and still worth a pause: you are trusting Anthropic’s host and TLS path. On locked-down machines, download the script, read it, then run it if policy requires that extra step. If curl fails with a 403, a weird HTML error, or a syntax error near <, the setup and troubleshoot docs map errors to fixes.

Native install: Windows PowerShell

irm https://claude.ai/install.ps1 | iex

irm is Invoke-RestMethod. iex is Invoke-Expression. Same trust story as the curl pipe: official host, still a script execution. Your prompt should look like PS C:\... in PowerShell. If you see 'irm' is not recognized, you are in CMD, not PowerShell.

Native install: Windows CMD

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

If && blows up as “not a valid statement separator,” you are in PowerShell. Switch shells or use the PowerShell one-liner. Shell mix-ups cause half of “install is broken” threads.

Homebrew (macOS, and Linux with brew)

brew install --cask claude-code

As of writing, Homebrew offers two casks. claude-code tracks a stable channel that can lag about a week and skip bad releases. claude-code@latest tracks newest. Homebrew installs do not use the native auto-update path. Upgrade with brew upgrade claude-code (or the @latest form if that is what you installed).

WinGet (Windows)

winget install Anthropic.ClaudeCode

WinGet also does not auto-update. Periodically run winget upgrade Anthropic.ClaudeCode. Setup docs note other Linux package managers (apt, dnf, apk) for Debian, Fedora, RHEL, and Alpine when that matches your distro norms.

Which install should you pick?

Path	Good when	Watch-out
Native curl / irm	You want the default path and background updates	Script trust; corporate SSL inspection can break curl
Homebrew cask	You already manage tools with brew	Manual upgrades; pick stable vs latest on purpose
WinGet	Windows team standard is winget	Manual upgrades; upgrade may fail while the app is running
Desktop / IDE only	You are not ready for a CLI install today	You still need login and a project folder; deep shell power may lag

If your company images machines with a fixed software catalog, ask IT whether Claude Code is already packaged. Fighting the package manager usually loses.

Verify, open a project, log in

First-run flow: install Claude Code, run claude –version, cd into a project, start claude, complete /login, then ask…

After install, prove the binary exists:

claude --version

You should see a version string that mentions Claude Code. If the shell says command not found, your PATH did not pick up the install. Open a new terminal window first. Still broken? Re-read the install method’s post-install note (brew cask paths, Windows user PATH, WSL vs Windows host confusion are the usual suspects).

Start inside a real project directory, not your home folder full of screenshots:

cd /path/to/your/project
claude

On first use, Claude Code prompts you to authenticate. Follow the browser flow for subscription or Console login. Inside a running session you can re-auth or switch accounts with:

/login

As of writing, documented login paths include Claude Pro/Max/Team/Enterprise subscriptions, Claude Console (API credits, with a Claude Code workspace created for cost tracking on first login), supported cloud providers (for example Bedrock, Google Cloud’s agent platform, Microsoft Foundry as documented), and org-run gateways when an admin preconfigures them. Credentials stay stored so you are not doing browser karaoke every morning.

When the session is up, you should see version, model, and working directory context around the prompt. Type /help once so you know where the escape hatches live. Type /exit (or the documented Ctrl+D pattern) when you are done. These small rituals beat panic-closing the window mid-edit.

Surfaces: terminal is not the only door

Claude Code surfaces side by side: terminal CLI, VS Code extension, JetBrains plugin, desktop app, and web at claude….

The CLI path is the one this part teaches end to end because it matches the official quickstart and it forces you to notice the working directory. Claude Code also shows up in other places as of writing:

Terminal: full agent loop in the project folder. Best when you already use git, tests, and package scripts from a shell.
VS Code (and compatible editors that take the extension): install the Claude Code extension from the marketplace. Docs note the extension can bundle a CLI for the chat panel; running claude in the integrated terminal still wants the standalone install.
JetBrains IDEs: plugin path for people who live in IntelliJ, PyCharm, WebStorm, and friends.
Desktop app: install Claude for macOS/Windows/Linux, sign in, open the Code tab. Useful when you want Code without a terminal ceremony. If the Code tab asks for an upgrade or online sign-in, finish that flow before you assume the product is broken.
Web: claude.ai/code for browser sessions. Handy on locked machines or for light parallel work. Deep local filesystem work still often favors desktop, IDE, or terminal.

Pick one surface for your first week. Learning login, permissions, and “where is my working directory” on five UIs at once is how people decide the tool is chaotic when the chaos was the setup tour.

Permission modes without the fear fog

Claude Code is permissioned. In default (manual) mode it asks before many writes and sensitive actions. That pause is a feature, not a bug. You can change how often the pause happens.

As of writing, during a CLI session you press Shift+Tab to cycle modes. The common cycle is:

default (often labeled Manual in the UI): Claude asks before edits. Safest first-day mode.
acceptEdits: auto-approves file edits (and some common filesystem commands in-scope). You review later in the editor or with git diff.
plan: Claude researches and proposes a plan without editing source until you approve. Great when you are still mapping the repo.

Accounts and builds may also expose modes such as auto or bypass-style options. Those are power tools. Do not start day one in “never ask.” Official docs live under permission modes. On Windows, if Shift+Tab does nothing in some runtimes, docs mention Alt+M as an alternate for cycling modes when VT input is unavailable.

First-week rule: stay in default (manual) until you have watched Claude ask for three different kinds of actions and you understood every prompt. Speed comes after trust, not before it.

Your first session script

Here is a concrete first run you can copy. Use a sandbox repo if production is scary.

1. Confirm you are in the right folder

In the shell, before claude:

pwd
ls

You want to see the project’s real root (package manifests, README, .git), not a nested node_modules or a random Downloads subfolder. Wrong working directory is the most expensive “Claude is dumb” false alarm.

2. Ask boring orientation questions

Official quickstart starters work because they are small:

what does this project do?

where is the main entry point?

what technologies does this project use?

Open the paths it cites. If it never points at files you can click, slow down. You are training your own review muscle, not collecting poetry about architecture.

3. Make one tiny change

Stay microscopic. Examples that fit first run:

Add a one-line comment to the README
Fix a typo in a user-facing string
Add a trivial hello-world helper in a file that already exists (and delete it if this is only a drill)

In default mode, read the permission prompt. Approve only if the path and action match what you asked. If Claude wants to install a global tool or rewrite half the tree for a typo fix, deny and restate the scope.

4. Review before commit

Do not outsource the commit message and disappear. Ask Claude what changed if you want, then look yourself:

git status
git diff

Or use your IDE’s diff UI. Commit only when you can explain the patch in one sentence to a teammate. If this was a throwaway drill, discard the change. The win was the loop, not the line of code.

A worked example: first evening on a sample app

Imagine you cloned a small public Node API called notes-api into ~/src/notes-api. You have a Pro subscription. You pick native install on macOS.

curl -fsSL https://claude.ai/install.sh | bash
claude --version
cd ~/src/notes-api
claude

Login completes in the browser. Back in the terminal you type what does this project do? Claude summarizes: Express server, SQLite for notes, tests with a runner you have not installed yet. It points at src/index.js and package.json. You open both. The summary matches.

You stay in default permission mode. You ask: “Add a single sentence to the README under Overview that says local setup needs Node 20.” Claude proposes a diff. You approve. You run git diff. One file, one sentence, no surprise dependency changes. You commit with a message you wrote yourself: “docs: note Node 20 requirement.” That is a successful first run. Boring is correct.

What would a bad first evening look like? You start in acceptEdits, ask “modernize the whole stack,” approve a flurry of prompts you barely read, and end with a half-migrated TypeScript rewrite, a new package manager lockfile, and no tests green. The agent did not fail ethics class. You skipped the seatbelt.

Accounts, limits, and money (light touch)

Code sessions burn more capacity than a short chat about dinner plans. That is normal for agentic tools that read trees and run commands. Subscription plans market Code as included on Pro/Max and on team/enterprise seats as documented at the time you subscribe. Console users pay with API-style credits. Cloud provider paths bill through your cloud account. None of those sentences replace the live pricing page the day finance asks “why did usage spike.”

Practical habits:

Prefer short, scoped sessions over “leave it running all day and hope.”
Use plan mode when you are still exploring so you do not pay for a pile of wrong edits.
On Console, watch the Claude Code workspace spend if your org created one on first login.
If the product says you hit a limit, stop thrashing alternate accounts. Fix scope or plan tier on purpose.

Common install and first-run failures

Symptom	Likely cause	What to try
`claude: command not found`	PATH or stale shell	New terminal; re-check install method; confirm binary path
Install script HTML/403 errors	Network filter, TLS inspection, wrong URL	Use corporate proxy settings; try alternate install; see troubleshoot-install docs
PowerShell vs CMD confusion	Wrong shell for the one-liner	Match prompt: `PS` → irm; plain CMD → install.cmd flow
Login loops	Browser blocked, wrong account, org SSO	Try `/login`; complete browser step; ask admin about gateway SSO
Code tab missing on desktop	Plan or auth incomplete	Upgrade/sign-in prompts; restart app after web auth
Agent edits the wrong project	Started Claude in the wrong directory	Exit, `cd` correctly, restart; verify with `pwd`
“It keeps asking permission”	Default mode	That is expected; cycle modes only when you mean to
Huge surprise diff	Vague prompt + acceptEdits	Revert; restart in plan or default; shrink the ask

Safety rails for day one

Do not paste production secrets into the prompt “just this once.”
Do not point Code at a directory that mixes personal tax PDFs with the repo.
Do not approve shell commands you would not type.
Do not skip git status because the UI felt confident.
Do not learn on the branch that deploys at 5 p.m. Friday.

If your org already has CLAUDE.md or AGENTS.md instruction files, leave them alone on day one unless a teammate asked you to edit them. Those files steer the agent for everyone. Later parts of this series cover memory, skills, and instruction files properly.

FAQ

Do I need Node.js to install Claude Code?

Native install is positioned so you are not assembling a separate Node toolchain just to get the agent. Your project may still need Node, Python, or whatever its README demands. That is project setup, not Claude Code install.

Can I use Code with only the free chat tier?

As of writing, the quickstart points at paid Claude subscriptions, Console, or cloud provider access. Free chat alone is usually not the path. Confirm live. Do not invent a workaround that violates terms or company policy.

Is desktop “the same” as the CLI?

Same family, different shell. Features, permission UX, and update channels can differ by surface. Learn one deeply, then expand.

Should I start in plan mode or default?

Default (manual) for first edits. Plan when the task is large and you want a proposal before any write. acceptEdits when you already trust the loop and will review via git.

How to practice this week

Install with the method that matches your OS norms.
Run claude --version and screenshot it for your own notes.
Open a sandbox repo. Complete login.
Ask what the project does and where the entry point is. Open those files yourself.
Make one reversible docs or comment change in default mode.
Review the diff. Commit or discard on purpose.
Optional: open the same project once in VS Code or desktop so you know the second door exists, then go back to one primary surface.

Quick recap

Install via native script (recommended), Homebrew cask, or WinGet; verify with claude --version.
Always cd into the project before claude; use /login when auth is wrong.
Surfaces include terminal, VS Code, JetBrains, desktop, and web; pick one for week one.
Default permission mode asks first; Shift+Tab cycles default → acceptEdits → plan.
First questions map the repo; first change stays tiny; review before commit.

Next: Part 2, Talking to a codebase: ask, explore, change, builds the conversation habits that keep agents useful after install. For product context outside the CLI, stay oriented with the Claude product map and everyday chat skills in Learn Claude.

Sources

Research and further reading used for this article (re-check before you write policy; product UIs move):

Claude Code Docs: Quickstart (install commands, version check, login, first questions, first change, permission mode note)
Claude Code Docs: Advanced setup (install methods, Homebrew/WinGet notes, updates, desktop pointer)
Claude Code Docs: Choose a permission mode (default, acceptEdits, plan, Shift+Tab cycle)
Claude Code Docs: Use Claude Code in VS Code (extension install, CLI vs panel notes)
Claude Code Docs: Get started with the desktop app (desktop install and Code tab)
Claude Code Docs: Interactive mode (keyboard shortcuts including mode cycling)
Claude Code Docs: Overview (surfaces and product orientation)
Analytics Made Simple: Claude product map (chat vs Code vs Cowork orientation)
Analytics Made Simple: Learn Claude from scratch (everyday Claude before deep tooling)