Home / Fundamentals and the agent loop
Reading and approving a diff
A diff is read line by line before being approved, and approval itself is now done through a menu of named options rather than a free keystroke.
A diff marks with a minus what disappears from a file and with a plus what gets added. A surgical modification, one that touches only what is necessary, is recognisable by how short these two blocks are, few lines removed, few lines added, concentrated on the exact point of the request.
A menu, not a free keystroke
When Claude proposes to modify a file, the permission prompt that appears is now a menu of named options, Yes, Yes and don't ask again, which holds until the end of the session for a file edit, and No. This edit is not saved to the file itself: the permissions table shows it, it lasts until the end of the session. It is only for a shell command or a WebFetch domain that a remembered choice survives the session and a restart, permanently and per repository. You move to the option you want and confirm with Enter. The Tab key opens, before confirming, a comment field attached to the chosen option, which lets you explain a refusal rather than leaving it silent. None of the named options in this menu let you directly edit the content of the diff shown at that exact spot. Editing proposed content goes through a different channel, the Ctrl+G combination, which opens a plan in your default text editor before approval, a mechanism distinct from editing a code diff already proposed at this stage.
Reading before approving, line by line
Reading line by line remains the gesture that protects, whatever the approval mechanism in place. A diff that touches twenty files for a change announced as localised deserves a refusal, or an explicit comment added through Tab, rather than a quick approval. Here is an example of a minimal diff, produced on files created for the demonstration:
mkdir -p /tmp/demo-diff
printf 'ligne un\nligne deux\nligne trois\n' > /tmp/demo-diff/avant.txt
printf 'ligne un\nligne deux modifiée\nligne trois\n' > /tmp/demo-diff/apres.txt
diff /tmp/demo-diff/avant.txt /tmp/demo-diff/apres.txt
The output shows exactly one line removed and one line added, exactly the expected scope of a surgical modification. A diff that, for the same request, also moved lines one and three would fall outside the necessary scope.
The mode that removes this prompt entirely, --dangerously-skip-permissions, is equivalent to the bypass permission mode presented in the lesson on permissions and plan mode. This mode is refused by default if the session is running as root or under sudo on Linux and macOS, unless inside a recognised sandbox, and its first interactive use displays a warning dialog that must be accepted once.
The three options of the permission menu on a file modification
| Permission prompt shown on a file modification proposed by Claude | Immediate effect | Effect for the rest of the repository |
|---|---|---|
| Yes | The proposed modification is applied once | No change for future requests |
| Yes and don't ask again | The proposed modification is applied | No more prompts until the end of the session, not beyond, unlike a remembered shell command |
| No | The proposed modification is not applied | A comment added through Tab can explain the refusal |
An engineer asks Claude Code to rename a variable in a single file. Claude proposes a modification and the permission prompt appears as a menu with the options Yes, Yes and don't ask again and No. The engineer moves the cursor to Yes and presses Tab before confirming.
Write in one sentence what this situation establishes, and in one sentence what it does not establish.
What this establishes: The situation establishes that a comment field opened on the Yes option before the engineer confirmed her choice with Enter.
What this does not establish: It does not establish what text the engineer wrote in that field, nor whether the proposed modification was ultimately applied.
The three most common miscalibrations
- Too broad It establishes that every approval of a file modification in Claude Code now compulsorily goes through adding a comment.
- Too narrow It establishes only that the Tab key exists on the keyboard the engineer is using, without saying anything about its effect in Claude Code.
- Beside the point It shows that the variable rename requested touched a file more complex than the project's average file.
- The approval prompt for a file modification is now a menu of named options, Yes, Yes and don't ask again, No, and not a free keystroke.
- On a file edit, Yes and don't ask again holds only until the end of the session, never longer: permanent memorisation per repository and per command only applies to a shell command or a WebFetch domain.
- The Tab key opens a comment field attached to the chosen option before confirming with Enter.
- None of the options in this menu let you directly edit the content of the diff shown at that spot.
- The --dangerously-skip-permissions mode is equivalent to bypass mode and is refused by default in a root or sudo session outside a recognised sandbox.
On a modification you ask Claude Code to make in your project, open the prompt's comment field with Tab before confirming, and write in one sentence why you are approving or refusing this exact diff.
These points depend on an interface or a rule that may have changed since this was written. Check them on your own screen before relying on them.
- The exact number of options shown on a specific file edit prompt is not documented screen by screen on a single source page.
Every datable claim in this lesson links here to the public text behind it. A source that does not open proves nothing.
- Claude Code, permissions, how long a file edit is remembered against a shell command consultée le 2026-09-02