What loads at session start

The sequence

flowchart TD
    START(["claude launched in /work/repo/services/api"]) --> ST{"Workspace<br/>trusted?"}
    ST -->|"No"| TRUST["Trust prompt<br/>project settings and env<br/>withheld until accepted"]
    ST -->|"Yes"| SET
    TRUST --> SET

    SET["Resolve settings.json hierarchy<br/>managed → CLI → local → project → user"] --> ENV["Apply env block<br/>into process environment"]
    ENV --> OS["Apply outputStyle<br/>modifies system prompt"]
    OS --> AG["Register agents<br/>managed → CLI → project → user → plugin"]
    AG --> SK["Index skills<br/>load descriptions only"]
    SK --> MEM["Walk filesystem for memory files"]

    MEM --> M1["/etc/claude-code/CLAUDE.md — managed"]
    M1 --> M2["~/.claude/CLAUDE.md — user"]
    M2 --> M3["/work/CLAUDE.md"]
    M3 --> M4["/work/repo/CLAUDE.md"]
    M4 --> M5["/work/repo/CLAUDE.local.md"]
    M5 --> M6["/work/repo/services/api/CLAUDE.md"]
    M6 --> IMP["Resolve @imports — max depth 5"]

    IMP --> RUL["Load rules without a paths: field"]
    RUL --> READY(["Session ready"])

    READY -.->|"later: Claude reads services/web/foo.ts"| LAZY["Lazily load<br/>services/web/CLAUDE.md<br/>+ rules matching **/*.ts"]

Two behaviours in that diagram are worth stating explicitly because they surprise people:

• Nested CLAUDE.md files load lazily. A CLAUDE.md sitting in a subdirectory you never touch costs nothing. It enters context the moment Claude reads a file in that directory. This is the monorepo pattern.
• Path-scoped rules behave the same way. A rule with paths: ["**/*.go"] is absent from a pure TypeScript session.

The practical consequence is that the context window is not static. A session that started at 3,000 tokens of configuration can be at 11,000 an hour later without you having changed a file, simply because Claude has now read code in four directories that each carry their own memory.

The trust gate

A committed .claude/settings.json is withheld until the workspace is trusted. This catches teams regularly:

If a teammate reports “the build command you documented doesn’t work for me”, the first question is whether they accepted the trust prompt, not whether the command is wrong.

Verifying what actually loaded

Never assume. Three commands answer almost every “why did Claude do that” question:

/context is the debugging tool. When Claude ignores an instruction, the first question is always “was it actually loaded?”, and roughly half the time the answer is no.

A worked diagnosis

You added a convention to .claude/rules/typescript.md and Claude keeps ignoring it.

1. /context. Is typescript.md listed? If not, either its paths: glob does not match your files, or Claude has not touched a .ts file yet this session. Rules load on first match, not at startup.
2. Check the glob. paths: ["*.ts"] matches only the repository root. You almost always want ["**/*.ts"]. This is the most common cause.
3. /memory. Is an ancestor CLAUDE.md saying the opposite? A rule and a memory file that contradict each other are both in context, and neither wins reliably. See conflicting rules.
4. Only then conclude the model made a judgement call.

Reading a /context breakdown

A healthy mid-size repository looks roughly like this:

If your configuration total is past ~8,000 tokens before you have written a single prompt, the fix is almost always moving language conventions out of CLAUDE.md and into path-scoped rules.