This page covers CLAUDE.md files, session management, and memory systems. See also: Overview, Setup & IDE, Skills & Plugins.

Context & Memory

Claude Code has no memory by default across sessions. These systems fix that.

CLAUDE.md — Your Project Brain

CLAUDE.md is the single most important file in your project. Claude reads it at the start of every conversation. It acts as persistent memory across sessions.

The Full Hierarchy (5 Levels)

Claude Code loads instructions from multiple levels, highest precedence first:

LevelLocationScope
1. Managed policyOS-specific system pathOrganization-wide
2. Project memory./CLAUDE.md or ./.claude/CLAUDE.mdTeam-shared, checked into repo
3. Project rules./.claude/rules/*.mdModular rule files
4. User memory~/.claude/CLAUDE.mdPersonal, all projects
5. Project local./CLAUDE.local.mdPersonal, current project only

Auto-memory: Claude also stores learned context in ~/.claude/projects/<project>/memory/MEMORY.md.

your-project/
├── .claude/
│   ├── settings.json       # Auto-accept permissions
│   ├── commands/            # Custom slash commands
│   ├── skills/              # Modular workflow skills
│   └── rules/               # Modular rule files (*.md)
├── CLAUDE.md                # THE MOST IMPORTANT FILE
├── CLAUDE.local.md          # Personal overrides (gitignored)
├── docs/
│   ├── index.md             # Master index
│   ├── architecture.md      # System design
│   └── changelog.md         # Change history
├── .env                     # API keys (never commit)
└── src/                     # Your actual code

Setting Up CLAUDE.md

1

Generate initial CLAUDE.md

Run /init — Claude scans your codebase and generates a CLAUDE.md automatically. Then refine it manually.
2

Add core rules

## Core Rules
1. Read first, answer second — Always read the codebase before making changes.
2. Plan before major changes — Verify the plan with the user first.
3. High-level explanations — Every step, explain what changed and why.
4. Simplicity first — Make every change as simple as possible.
5. Maintain architecture docs — Keep docs/architecture.md updated.
3

Add documentation rules

## Documentation Rules
- After every feature: update docs/changelog.md and docs/project_status.md
- After architecture changes: update docs/architecture.md
- After API changes: update docs/api.md
4

Add autonomy settings

## Autonomy Level
- Skip plan mode — implement directly
- Do not ask for confirmation on file edits
- Only confirm before: destructive git operations, pushing, deleting files
- Run tests automatically after changes
5

Split into modular rules

Use .claude/rules/*.md to split rules into focused files instead of one massive CLAUDE.md. This reduces context bloat.
Use /memory to open and edit CLAUDE.md files directly from within a session.

Session Management

CommandWhat It Does
claude --resumeResume previous session (CLI flag)
/clearWipe context for a completely new task
/compact [instructions]Compress long conversations to save tokens
/contextVisualize current context usage as a colored grid
/rewindRoll back conversation and/or code changes
/export [filename]Save conversation history to file or clipboard

The Context Window — Critical Rules

Your context window is like working memory. When it fills up, quality drops.

  • Use /compact when context hits 50% (~100K tokens for Opus 4.6’s 200K window)
  • Use /clear between unrelated tasks — old irrelevant history wastes tokens
  • Never dump all documentation into one file — Claude loads everything in CLAUDE.md at once

Token Economy

Every message sends the entire conversation history plus active tools. Costs compound quickly.

TechniqueHow
Modular docsSplit docs into small files with an index.md
Disable unused MCPs/mcp > disable tools you’re not using
Use subagentsThey have their own context window
Concise promptsAdd “Respond briefly” when you only need core info
Right modelOpus for complex, Sonnet for routine, Haiku for trivial
/fast toggleSame model, faster output

Knowledge & Documentation Setup

docs/
├── index.md            # Master map: what each file contains
├── architecture.md     # How the system works end-to-end
├── changelog.md        # History of every significant change
├── project_status.md   # Current state, what works, what's in progress
├── api.md              # API endpoints documentation
└── features/
    ├── auth.md
    ├── payments.md
    └── dashboard.md

The Master Index Pattern

docs/index.md tells Claude where to look so it reads only what’s needed:

# Documentation Index

| File | What it contains | When to read it |
|------|------------------|-----------------|
| architecture.md | System design, data flow | Structural changes |
| changelog.md | History of all changes | Debugging |
| features/auth.md | Auth logic, OAuth | Touching authentication |
| features/payments.md | Stripe integration | Touching billing |

Link this index in CLAUDE.md: Master index: docs/index.md — always check here first.

Subagents

Subagents are specialized AI assistants that run in their own context windows:

SubagentPurposeTools
ExploreFast read-only codebase explorationGlob, Grep, Read
PlanResearch and design approachesRead-only tools
General-purposeComplex multi-step tasksAll tools

Why subagents? Context isolation (work doesn’t bloat your main session), parallel execution, focused toolsets, and independent permissions.

Extended Thinking

Claude Code’s extended thinking is controlled via keyboard toggle, not prompt keywords:

  • Toggle: Alt+T (Windows/Linux) or Option+T (macOS)
  • Effort levels for Opus 4.6: low, medium, high
Phrases like “think hard” or “ultrathink” in your prompts are interpreted as regular instructions — they do NOT activate extended thinking mode. Use the keyboard toggle instead.

Security & Secrets

The Golden Rule: Never Paste Secrets Into Chat

NEVER type or paste API keys, passwords, or tokens directly into a Claude Code prompt. Anything you type becomes part of the conversation history.

The right way: Store secrets in .env and reference them via environment variables.

# Wrong (exposed in chat history):
Set up the database with password=s3cretP@ss!

# Right (secrets stay in .env):
Set up the database using the environment variables from .env

Setup .env properly:

  1. Create .env with actual values (never commit)
  2. Add .env to .gitignore
  3. Create .env.example with placeholder values for documentation