Anatomy of a session: prompt, tool call, permission prompt, status line

You have it installed, you typed something, and text is moving. Most people spend their first week treating that scroll as weather. It is not. There are four kinds of thing on that screen, each means something specific, and one of them is a decision you are making whether or not you read it.

Four things, and only four

The header comes before you type a word — "the version, current model, and working directory shown above it" (Quickstart). Three facts you will want later, printed once and then forgotten by everybody. Everything that scrolls below it is one of four things:

Lesson 1.1 gave you the loop; this is its instrument panel. No screenshot: what the docs pin down is the wording — exact strings, exact keys — and a screen drawn from memory would teach you a session that does not exist.

Tool calls are the loop made visible

A tool call is three parts — the tool name, its inputs, and the result — and the result is the part that matters.

Each tool use gives Claude new information that informs the next step. This is the agentic loop in action. — How Claude Code works

A session that reads one file and then a different one did not change its mind at random; the first result told it where to look next. Reading the sequence of tool calls is reading the reasoning, and it beats reading the prose summary at the end. Learn the tool name as a name, not an icon:

The tool names are the exact strings you use in permission rules, subagent tool lists, and hook matchers. — Tools reference

Bash, Read, Edit, Grep, Glob, Write, WebFetch. The word on screen today is the word you type into a settings file in Level 10; nothing else in this interface has that property. When a line collapses and you cannot tell what happened, Ctrl+O toggles the transcript viewer, which shows detailed tool usage and execution with a timestamp and the model on each assistant message (Interactive mode).

Permission prompts: read the answer, not the question

A prompt is not the model asking politely. It is the harness stopping the model.

Permission rules are enforced by Claude Code, not by the model. — Configure permissions

Which tools stop is fixed by tool type. Manual is "the mode that reviews every action" (Permission modes); its config value is default. What it asks you about (Configure permissions):

Reading is free inside the fence. Read, Grep and Glob do not prompt for paths inside the working directory, and "still prompt for paths outside the working directory and additional directories" (Tools reference). A session that quietly reads twenty files is documented behaviour, not a permission failure — which is why Level 3 is about context rather than consent. And ls is a Bash command that does not ask:

Claude Code recognizes a built-in set of Bash commands as read-only and runs them without a permission prompt in every mode […] The set includes ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, and read-only forms of git. — Configure permissions

The set is not configurable; to make one of them prompt you add an ask or deny rule. That is why "give me an overview of this repo" can run a string of Bash calls and never stop to ask.

The trap: "don't ask again" does not mean the same thing twice

Which .claude/settings.local.json is worth pinning down, because it moved. From v2.1.211 Claude Code saves the rule at the root of the git repository, resolved through worktrees to the main checkout, so it applies to future sessions anywhere in that repository — and reading it back follows the same line: the file loads from the repository root even when you start in a subdirectory, except in the cases where Claude Code does not use the root, such as on Windows (Configure permissions, Work in large codebases). Before v2.1.211 the rule was always saved in the starting directory, and the file was only loaded from there as well, so an approval granted in a worktree or a subdirectory did not apply to the rest of the repository, and one granted at the root did not reach a session started in a subdirectory or a worktree of it.

The older behaviour is not safely in the past, which is the part to carry forward. Rules an earlier version left in a subdirectory or a worktree keep applying to sessions started there, and Claude Code still reads such a file alongside the root one: where both set the same key the root's value wins, but the permission rules from both files apply (Settings). A repo you have worked in for a year can therefore carry quiet allow-lists in several directories at once, and none of them is the one file you would think to open.

You meet the edit case first, generalise from it, and spend a month answering "yes, and don't ask again" to shell commands as though it were a session convenience. It is a persisted config change made one keystroke at a time, which nobody reviews because nobody remembers making it. The /permissions dialog "lists all permission rules and the settings.json file each rule comes from" (Configure permissions); open it once in a repo you have used for a while. Where the option is missing entirely that is deliberate: Claude Code offers it only when the prompt can show you everything it would allow, so a saved rule never covers more than the label you read.

Saying no has two settings, and almost nobody finds the second. Esc declines the action, exactly as No without a comment does — and a bare No from the main conversation stops the turn. But press Tab on No and you get a comment field; the comment reaches Claude as the reason for the denial and Claude keeps working. A No that says "not that file — the config lives in packages/api" is the cheapest course correction in the product.

The mode indicator, and why your prompts may never appear

Everything above describes Manual mode. Which mode you are in is printed on the status bar, and the strings are fixed (Permission modes):

⏸  manual mode on            (config value: default)
⏵⏵ accept edits on           (acceptEdits)
⏸  plan mode on              (plan)
⏵⏵ auto mode on              (auto)
⏵⏵ don't ask on              (dontAsk)
⏵⏵ bypass permissions on     (bypassPermissions)

The docs give the strings and no meaning for the glyphs, and ⏵⏵ is not a promise of silence: no mode auto-approves everything, and the ones that stop asking you do so for three different reasons. Lesson 10.1 builds the roster in full — what each mode auto-approves, and the fixed list of actions none of them does. Shift+Tab cycles the mode. And one sentence that saves a wasted afternoon:

Asking Claude in chat to change the permission mode doesn't work. — Permission modes

It is a harness control, not a model behaviour. Telling Claude "stop asking me" changes nothing except your context window.

On a Pro, Max or Team plan you may have read this whole lesson without seeing a single permission prompt, because on those plans the built-in starting permission mode is auto mode, where a classifier decides most prompts instead of you. The prompts are not gone; you are not being asked. Press Shift+Tab until the bar shows the mode that reviews every action — config value default — for the rest of this level. Level 10 is where you pick a mode on purpose.

The status line is not built in

There is a footer, and there is a status line, and only one of them exists by default.

The status line is a customizable bar at the bottom of Claude Code that runs any shell script you configure. — Status line

You do not have one until you write one. When you do, it renders in its own row above the built-in footer badges without replacing them, it runs locally and does not consume API tokens, and it hides during permission prompts, the help menu and autocomplete suggestions — so its absence at the moment you look for it is normal. One field the script receives is context_window.used_percentage, a "pre-calculated percentage of context window used", and that matters more than it looks. The docs describe no persistent context meter in a default session. Where context percentage is documented as reaching your screen, it is because you asked — /context "visualize[s] current context usage as a colored grid" (Commands) — or because you configured a status line that prints the field above. If you are waiting for a gauge to appear on its own, stop waiting: that is why Lesson 3.2 opens with a command.

Steering while it runs: Enter queues, Esc interrupts

The input box stays live while Claude works, and people reach for the wrong thing under pressure.

Nothing stops, and your correction lands at the next seam in the loop rather than mid-tool-call. That is usually what you want; Esc is for when the next seam is too late. The last row is the fourth element hiding in plain sight. A leading ! doesn't require Claude to interpret or approve the command, and it adds the command and its output to the conversation context (Interactive mode). Both halves matter: you are outside the permission system, and you are not outside the context window. ! cat a-large-file is a budget decision exactly as Read is.

Read one session on purpose

Open a session in a repo you know. Before typing, read the header and say the version, the model and the directory. Press Shift+Tab until the bar shows the default mode — labelled ⏸ manual mode on from v2.1.200 on. Ask one question. Then, without scrolling, answer three things: which tools ran, which of them could have prompted you and did not, and what the first result told the loop that made it choose the second step. That is the difference between reading a session and watching one.