The Complete Claude Code Guide: From First Install to Daily Workflow

Claude Code is Anthropic's agentic coding tool — you describe what you want in plain language and it edits files, runs commands, searches the codebase, and ships. Unlike a chat-only assistant, it operates directly on your repository, which makes the setup details matter. This guide walks through installing Claude Code, seeding a project with /init, writing the CLAUDE.md memory file, configuring permissions, the commands you will actually use, and a daily workflow that holds up on a real codebase.

Installing Claude Code

Claude Code is a terminal tool distributed as an npm package. You need Node.js installed first (any recent LTS version works), then:

npm install -g @anthropic-ai/claude-code

This installs the claude command globally. Verify it is on your path:

claude --version

On first launch, claude walks you through authentication using your Anthropic account (or an API key, or a supported Bedrock / Vertex backend). Once authenticated, navigate into a project directory and run claude with no arguments to start an interactive session. Claude Code is designed to run from the root of your repository so it can read the whole project for context.

There is no separate IDE plugin required. Claude Code works in any terminal, and there are optional integrations for editors like VS Code and JetBrains that launch a session from inside the editor. The terminal is the canonical interface.

Seeding a project with /init

The first command worth running in a new project is /init. It asks Claude to explore your codebase and generate a CLAUDE.md file that captures the essentials a new contributor needs: the build and test commands, the directory layout, conventions, and any quirks worth knowing. The result is a draft you edit down to what is actually useful.

> /init

After /init finishes, open CLAUDE.md and trim anything that is wrong or already obvious. The goal is a short, accurate file — not a comprehensive one. A good CLAUDE.md is two screenfuls: how to run the tests, where the entry points are, and the conventions Claude should follow when writing code. Everything else is noise that costs tokens on every turn.

/init is not mandatory. You can write CLAUDE.md by hand and skip the draft. But running it once on a new project is the fastest way to bootstrap, because Claude reads the actual code rather than guessing.

The CLAUDE.md memory file

CLAUDE.md is the single most important configuration file in Claude Code. It is a plain Markdown file that Claude reads at the start of every session, so anything in it becomes persistent context. Think of it as the instructions you would hand to a new teammate who has never seen the codebase.

Claude Code loads CLAUDE.md from a few places, all merged:

• Project memory — ./CLAUDE.md in the repository root (and nested CLAUDE.md files in subdirectories, loaded when Claude works in that directory). Checked into git, shared with the team.
• User memory — ~/.claude/CLAUDE.md, personal preferences that apply across every project.
• Local overrides — ./CLAUDE.local.md, gitignored, for machine-specific or private notes.

Run /memory at any time to see exactly which files are loaded in the current session. This is invaluable when Claude is behaving as if it forgot something — usually the file you edited is not in the loaded list.

What belongs in CLAUDE.md? The high-value items are: build and test commands, code style and naming conventions, where new code should go, how to run the linter, and any project-specific rules ("never edit the generated dist/ directory", "always add a changelog entry"). Keep it short and imperative. Long, discursive CLAUDE.md files get skimmed by the model just like they get skimmed by humans.

Permissions: allow and deny

Because Claude Code runs commands and edits files, permissions are how you keep it from doing something you did not want. Claude Code evaluates every tool call against rules in your settings, and asks for approval the first time it tries something not covered by a rule.

There are four permission modes you can switch between in a session:

• default — asks for approval before potentially destructive actions (the normal mode).
• acceptEdits — auto-approves file edits, still asks for commands.
• plan — read-only exploration; Claude proposes a plan without making changes.
• bypassPermissions — skips all approval prompts (use with care, typically only in sandboxed environments).

The persistent rules live in settings.json (project-level in .claude/settings.json, user-level in ~/.claude/settings.json) under permissions.allow and permissions.deny:

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint)",
      "Read(./src/**)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Read(./secrets/**)"
    ]
  }
}

Two rules that matter in practice: deny always wins over allow (a denied action is blocked even if an allow rule matches), and hooks run before rules (a PreToolUse hook can block or approve a call regardless of the rules). Deny rules on Read and Edit also extend to the file commands Claude recognizes in Bash — cat, head, tail, sed — so you cannot accidentally read a secret file by shelling out.

Tuning permissions is how you reduce approval fatigue without going fully hands-off. A typical setup: allow the test and lint commands, allow reads of the source tree, deny anything that touches secrets or force-pushes, and leave everything else on the default ask.

Commands you will actually use

Claude Code has a set of slash commands for session control. The ones that come up daily:

• /init — generate a draft CLAUDE.md.
• /memory — show which memory files are loaded right now.
• /permissions — inspect and edit the active permission rules.
• /clear — reset the conversation context, keeping the same session.
• /compact — summarize the conversation so far to free up context window.
• /mcp — list connected MCP servers and their tools.
• /model — switch the underlying model.
• /help — list all available commands.

Beyond slash commands, the main interaction is just typing a request in natural language. You can also pipe input in: cat error.log | claude -p "what's causing this error?" runs Claude non-interactively on the piped content and prints a response, which is how you wire Claude Code into scripts and CI.

A daily workflow that holds up

The workflow that tends to produce good results on a real codebase:

1. Start from the repo root so Claude has the full project in scope. Run /memory to confirm the right CLAUDE.md is loaded.
2. Explore in plan mode first. For anything non-trivial, start with plan mode so Claude reads the code and proposes an approach before touching files. Review the plan, adjust, then drop into default mode to execute.
3. Ask for tests alongside changes. When you request a feature or a fix, ask for the test in the same turn. Claude Code is most reliable when the change and its test are written together.
4. Let it run the tests. Allow npm test (or your equivalent) so Claude can verify its own changes. A change that the agent has confirmed passes the test suite is far more trustworthy than one it has not.
5. Review every diff before accepting. Use acceptEdits for speed on mechanical changes, but switch back to default mode for anything subtle. The model writes code you have to maintain.
6. Commit in small chunks. Ask Claude to stage and describe logical groups of changes rather than one big commit. Conventional commit messages come out cleanly if your CLAUDE.md specifies the format.

The pattern across all of these: keep a human in the loop on decisions, let Claude handle the typing. Claude Code is fast at the mechanical work — reading a directory, writing a boilerplate change, running the tests, regenerating a fixture — and weakest when asked to make product judgement calls unsupervised. Lean into the first, supervise the second.

Customizing with skills, commands, and hooks

Once the basics click, the customization layer is where Claude Code gets powerful on a specific project.

• Skills package repeatable procedures into a SKILL.md the model loads on demand — covered in depth in our Claude Code Skills guide.
• Custom slash commands live in .claude/commands/ as Markdown prompt files; type /project:your-command to run them.
• Hooks run scripts at lifecycle events (PreToolUse, PostToolUse, Stop) for things like auto-formatting after every edit or blocking dangerous commands.

These compose. A mature setup might have a skill for the code-review checklist, a slash command for the deploy procedure, and a PostToolUse hook that runs the formatter on every file Claude writes. The payoff is that Claude behaves the way your team expects without you re-explaining it every session.

Frequently asked questions

What is CLAUDE.md and how do I create it?

CLAUDE.md is a plain Markdown file Claude Code reads at the start of every session, making its contents persistent context. The fastest way to create one is to run /init in your project root — Claude explores the codebase and generates a draft capturing build commands, layout, and conventions, which you then edit down. You can also write it by hand. Run /memory at any time to see which CLAUDE.md files are currently loaded.

What are the four permission modes in Claude Code?

default asks for approval before potentially destructive actions; acceptEdits auto-approves file edits but still asks for commands; plan is read-only exploration where Claude proposes an approach without making changes; and bypassPermissions skips all approval prompts. You switch between them in a session, and persistent allow/deny rules live in settings.json.

How do allow and deny permission rules interact?

Deny always wins. If an action matches both an allow rule and a deny rule, it is blocked. Deny rules on Read and Edit also extend to file commands Claude recognizes in Bash such as cat, head, tail, and sed, so you cannot read a denied file by shelling out. Hooks run before rules, so a PreToolUse hook can block or approve a call regardless of the permission rules.

Can I use Claude Code non-interactively in scripts or CI?

Yes. The -p flag runs Claude non-interactively on piped input and prints a response, for example cat error.log | claude -p "what's causing this error?". This is how you wire Claude Code into shell scripts, git hooks, and CI pipelines. The Agent SDK offers the same capabilities programmatically for production automation.

Official references

• Claude Code overview
• Claude Code memory management (CLAUDE.md)
• Claude Code permissions
• Claude Code CLI reference
• Anthropic — Claude Code

This article reflects publicly available information as of July 2026; relevant APIs may evolve.