AnswerQA

How do I run my first Claude Code session?

Answer

Open Claude inside a real repo, ask one concrete task, read the diff before approving, and use /clear when context drifts. Most beginner pain comes from overstuffed CLAUDE.md, mixed-task sessions, and rubber-stamping edits.

By Kalle Lamminpää Verified May 7, 2026

Install is not the hard part. The hard part starts at minute fifteen, when CLAUDE.md is bloated, the permission prompt has become muscle memory, and you have stopped reading the diff.

Run a real session through

1. Install and log in.

The Quickstart recommends the native installer (no Node prerequisite):

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

Windows uses irm https://claude.ai/install.ps1 | iex in PowerShell. The npm install command (npm install -g @anthropic-ai/claude-code) still works and is documented under Advanced setup, but you do not need a Node toolchain to run Claude Code anymore.

Then start it inside a real repo:

claude

Run that from inside any project directory (use cd first if you need to move there). First run prompts you to sign in: Pro, Max, Team, Enterprise, Claude Console, or a supported cloud provider (Bedrock, Vertex). Self-hosted setups can pass ANTHROPIC_API_KEY. On macOS credentials live in the system keychain; on Linux and Windows they go to ~/.claude/.credentials.json (or $CLAUDE_CONFIG_DIR if you override it). Either way, never the repo. Open Claude inside an actual codebase, not a hello-world. Claude is dramatically better when it has files to read and a real git history to ground in.

2. Ask one concrete task. Not three.

Bad first prompt:

can you fix the timezone bug, also refactor the date utils, and add a test

Good first prompt:

the timezone selector shows UTC for users in PST. find where the conversion happens and propose a fix.

One task per session. The whole conversation lives in context, so a session that started as “fix this bug” and drifted into “also refactor X” carries the bug-hunting noise forward into the refactor. Mixed-task sessions are the single most common reason a beginner says “Claude is dumb.” It is not dumb, it is drowning in your earlier asks.

3. Read the diff before you approve it.

When Claude proposes file edits it shows a unified diff. Read every line. Skim is the enemy. The cheapest moment to course-correct is before “yes”; once edits land you are in cleanup mode.

If the plan looks wrong, do not argue in chat for ten turns. Press Esc to interrupt, then redirect tightly:

stop. you are editing the wrong file. the bug is in src/lib/timezone.ts, not the React component.

Short, specific corrections beat paragraphs of context.

4. When you have corrected twice, run /clear.

Anthropic’s own best-practices doc says it directly: if you have corrected Claude on the same issue more than twice in one session, the context is full of failed approaches and the model is now anchored on them. /clear wipes the conversation while keeping the working directory and CLAUDE.md. Restart with what you just learned baked into the next prompt.

This is the single highest-leverage habit a new user can build. Treat /clear as cheap.

5. End the session deliberately.

Ctrl-D or /exit. Resume the most recent conversation with claude --continue (-c); pick from earlier sessions with claude --resume (-r). If you opened five tasks in five sessions, close the ones you have shipped. Claude Code keeps each session’s context warm, and stale ones show up in the --resume picker for weeks.

Footguns

Auto mode is not a productivity hack, it is a tripwire. New users hit a few permission prompts in a row and reach for --permission-mode auto to make them stop. Auto mode is a research preview: a classifier passes obviously-safe commands automatically and still escalates dangerous ones to you, but the classifier is not perfect. Fine for npm test. A disaster the day it green-lights a refactor that includes rm -rf node_modules typed at the wrong directory, or a git push to the wrong remote. Auto mode belongs in a sandboxed worktree (start one with claude --worktree <name> or ask Claude inside a session to create one) or a disposable VM, not in a repo that has your real .env. The first session is the wrong time to enable it.

A bloated CLAUDE.md makes Claude ignore your rules. Beginners read “you can put project context in CLAUDE.md” and dump everything: style guide, architecture notes, the entire README, deploy steps, contributor list. The file balloons to 2,000 lines. Two things go wrong. First, Claude pays the token cost for it on every turn, slowing every reply and shrinking the room left for actual work. Second, when CLAUDE.md is long, the model weighs the earlier instructions more heavily and quietly forgets the later ones. Keep CLAUDE.md under 100 lines for your first month. Only put facts the model cannot infer from the code itself: external service URLs, non-obvious test commands, “always use yarn not npm”, that kind of thing. Style preferences belong in a linter, not in CLAUDE.md.

Plan mode is for ambiguous scope, not for every task. Plan mode (Shift+Tab cycles to it, or --permission-mode plan) makes Claude propose a plan and wait for approval before any edits. It is the right default when a request touches multiple files or when you are not sure what the diff should look like. It is overkill when you ask “rename getUserData to fetchUser”. Forcing plan mode on every task adds 30 seconds of waiting per turn and trains you to rubber-stamp plans, which is the worst of both worlds. Use plan mode when you cannot predict the shape of the diff in advance.

The “trust but verify” gap is real and it bites once. First-session users tend to either approve every edit instantly or read every line obsessively. The actual move is in between: read every diff carefully for the first ten sessions so you calibrate on Claude’s habits in this codebase, then start skimming once you have seen the patterns it falls into. What bites is approving an edit that “looks right” and finding out an hour later that it deleted a test file or rewrote a function you did not mean to touch. Always look at the file paths in the diff header before scrolling the body.

When NOT to start with Claude Code

  • You do not have a real repo to point it at. Claude Code’s whole edge is grounding in actual code. Without that it is a worse claude.ai.
  • You are typing the prompt once and never again. A one-shot question fits better in the desktop app or web. Claude Code is for repeated work in a codebase.
  • You have not decided what task you want done. Spinning up a session and brainstorming inside it burns context fast and produces vague output. Decide first, then open Claude.
  • You are on production credentials with auto mode on. Practice on a fork or a worktree first. The first time Claude runs an unexpected git push is not the moment to learn the difference between modes.

Sources

  • Quickstart
    Canonical install and first-session walkthrough. The gaps this article fills: mixed-task sessions, diff-review discipline, and the concrete misuse patterns that make first sessions frustrating.
  • Claude Code best practices
    Source of the /clear-after-two-corrections rule and the explicit warning against bloated CLAUDE.md files.
  • Configure permissions
    Modes: default, acceptEdits, plan, auto, dontAsk, bypassPermissions. Auto mode is a research preview that runs background safety checks rather than blanket-allowing every command.
  • Manage Claude's memory
    CLAUDE.md hierarchy and a direct argument for why short beats comprehensive.
  • CLI reference
    Authoritative source for `claude --continue` (most recent), `claude --resume` (picker), and `claude --worktree`.
  • Authentication
    Where credentials actually live: macOS keychain, `~/.claude/.credentials.json` on Linux/Windows, and the `CLAUDE_CONFIG_DIR` override.

Was this helpful?