Getting started with Claude Code

A good first Claude Code session is not just installation. It includes choosing the right surface, opening a real repository, giving project context, and verifying the result with the same commands a developer would use.

Last verified
Applies to
Claude Code 2.1.x. CLI spellings were checked on local version 2.1.198; current official docs may describe newer 2.1.x behavior.
Verification method
Official documentation, CLI reference, and changelog reviewed on 2026-07-19. CLI entry points were checked locally; prompts, model output, and project tests are repository-dependent and are not claimed as pre-run.
Official sources
QuickstartCLI referenceChangelog

Reproducible practice

Complete one bounded change with an evidence trail

Use a small repository task to learn exploration, planning, editing, verification, and review without granting broad automation first.

Prerequisites

  • A trusted repository with a clean or understood git status.
  • A working Claude Code login and known project test command.
  • A task with one observable outcome, such as one failing test or one validation rule.

Steps

  1. Record the baseline

    Preserve existing changes and identify the project commands before opening a session.

    Step 1
    git status --short
    git diff --check
  2. Start with read-only planning

    Ask for relevant files, the smallest change, risks, and the exact verification command.

    Step 2
    claude --permission-mode plan
  3. Approve a narrow implementation

    Review the plan, switch out of plan mode only when the file scope and acceptance check are correct, then request the bounded change.

  4. Verify outside the narrative

    Run the repository test and inspect the actual diff rather than accepting a success summary.

    Step 4
    git diff --check
    git diff --stat
    # Run the project-specific targeted test here

Expected result

The requested behavior changes, unrelated files remain untouched, and the named project check passes or yields a concrete first failure.

Validation

  • Compare the final diff with the original acceptance condition.
  • Run at least one targeted test or build command owned by the repository.
  • Check git status so generated or unexpected files are visible.

Failure handling

Plan is generic

Ask Claude to cite exact files and existing test commands before allowing edits.

Test fails elsewhere

Separate baseline failures from regressions by reproducing the same command against the pre-change state when safe.

Cleanup or rollback

  • Reject or manually revert only the task-specific hunks after reviewing them; do not erase unrelated working-tree changes.
  • Keep the failing command and first actionable error when handing the task back for another attempt.

Boundaries and when not to use it

  • Do not use a production repository as a first exercise when tests, ownership, or rollback are unclear.
  • Plan mode reduces write risk but does not replace repository backups, review, or permission policy.

Choose the surface

Claude Code is available across terminal, IDE, desktop, browser, and related development workflows. The terminal is direct and scriptable; IDE integrations help with local code editing; desktop and browser surfaces help when you want visual review, parallel sessions, or remote work.

Chrome

Best for live browser reproduction, console debugging, and UI QA.

Read guide

Start in a real project

Open the repository before starting the session. Ask Claude Code to inspect the package manager, framework, test runner, build command, and key directories. This avoids generic advice and lets it ground later edits in the actual codebase.

Create durable project context

Use repository instructions for facts that should persist: architecture boundaries, coding conventions, test commands, deployment notes, and review rules. Durable context is more reliable than restating the same setup in every prompt.

Verify the first task

Pick a small task with an observable result, such as fixing a failing test, explaining a module, adding one validation rule, or updating a narrow component. Ask Claude Code to run the project command that proves the result.

Install and authenticate

Install the CLI with the native installer, Homebrew, or WinGet, then sign in before repository work. If setup looks correct but sessions fail, use doctor-style checks instead of guessing at project config.

Native install and sign in
curl -fsSL https://claude.ai/install.sh | bash
claude auth login
claude auth status --text
Start the first session
cd my-project
claude "Explain the build, test, and deploy commands for this repo."

Before you continue

Related topics