Chapter 1 established the asymmetry: read-only tools run without asking, state-changing tools do not. A permission mode sets where that line falls for a session.

The mode is one gate among several, and the order matters more than any individual mode does.

flowchart TB
    A([Tool call]) --> D{deny rule?}
    D -->|match| X([Blocked])
    D -->|no| K{ask rule?}
    K -->|match| P([Prompt])
    K -->|no| S{protected or
critical path?}
    S -->|yes| M2[Mode-specific
handling]
    S -->|no| M{Permission mode}
    M -->|default / acceptEdits| P
    M -->|dontAsk| X
    M -->|bypassPermissions| R([Runs])
    M -->|auto| C{Classifier}
    C -->|approves| R
    C -->|blocks| X

Two consequences fall out of that ordering, and both are load-bearing for the rest of this chapter:

Claude Code accepts input through three distinct channels. They differ in when they are parsed, what parses them, and whether the input reaches the model at all.

flowchart TB
    subgraph T["Shell — before the process exists"]
        A["claude --model opus --add-dir ../api"]
    end
    subgraph S["Session — start of an input line"]
        B["/context   /compact   /doctor"]
    end
    subgraph P["Prompt — inside the text"]
        C["explain @src/auth.js and check !git log"]
    end
    T --> S --> P

Two of the three do not consume model calls. That is the practical consequence: work done through channels 1 and 2 is free of inference cost and latency.

A language model is a text-to-text function. It has no filesystem handle, no shell, no network socket. Given “explain the code in complex.py”, the only correct response is that it cannot read files.

sequenceDiagram
    participant You
    participant LLM
    You->>LLM: Explain the code in complex.py
    LLM-->>You: No file access — supply the contents

Claude Code is the process that closes that gap. It is an agentic harness: it supplies tools, executes them on the model’s behalf, and drives the model in a loop until the task is done.