The click was never the control

01The prompt most testers approved

In Anthropic’s 7 August study announcement, 13.6% of 1,053 paid testers blocked a substituted dangerous-looking permission prompt; the classifier blocked 89%. The testers were working in a controlled study environment. Approving the prompt never executed the dangerous operation. Those results put the value of repeated approval clicks in question. ¹

Suppose a developer asks a coding agent to fix tax rounding in a checkout service. The agent finds a decimal conversion, edits it and runs the relevant tests. The developer wants to review the diff after lunch. The application, however, deploys automatically when a commit reaches main. That arrangement turns an ordinary push into a customer-facing change.

There are two separate questions here. Does the patch calculate tax correctly? And has someone authorized this revision to reach customers? A successful unit test helps answer the first. The agent could produce a correct patch and still publish it before the developer intended. This is a hypothetical workflow, not an incident or a test we performed.

A long sequence of permission prompts makes those questions harder to follow. Reading a fixture, creating a file and publishing a commit can become successive interruptions in the same afternoon. Asking someone to notice the consequential command among routine ones places a substantial burden on attention.

02What the August study actually measured

Anthropic’s 7 August announcement set 14 August as the start of auto mode for new Pro, Max and Team sessions. The mode substitutes classifier review for routine approval prompts. That is the historical change this article examined. ¹

The table preserves the figures and original reading date from our August edition. “Live session” means an ongoing study session. ¹

The human block rate fell as prompts accumulated; the classifier performed better on these commands. That supports reducing reliance on repetitive clicks. The experiment does not establish the safety of every unattended coding workflow, and it did not measure our hypothetical checkout service. ¹

For the tax fix, the useful distinction is attention versus authority. A developer may miss a bad command after many prompts. A team can still deliberately reserve publication for a later review, even if every individual command looks routine. A classifier’s advantage in the study does not decide who should own that publication decision.

03Specify the publication checkpoint

The configuration guide read on 18 October allows ordinary pushes to the working repository’s default branch and pull-request creation. This is current documentation, not evidence of every August setting. ³

In the tax example, the developer would prefer the agent to finish the patch, show the diff and wait. An instruction in chat communicates that preference. For a repeated workflow, give the publication step a setting the operator can inspect before the agent starts.

The documented recipe below makes matching commands prompt before classifier review. Its scope matters: the guide warns that git -C and git -c forms do not match these prefixes. It recommends a PreToolUse hook for inspecting the full command text. A chat-only restriction can also disappear during compaction. ³

The lesson is to describe the operation first: publishing a revision to the checkout repository. Then examine how the actual launcher performs it. A rule written for one command spelling can leave another route open. Copying a short recipe without looking at that launcher would give the developer unwarranted confidence.

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

04Keep the repository’s decision separate

GitHub’s current branch-protection documentation describes required reviews and status checks. It also warns that administrators and roles with bypass permission are exempt by default unless the relevant setting applies the restrictions to them. ⁴

For the hypothetical checkout service, a pull request gives the reviewer a particular tax patch to examine. The remote can require the review and the relevant checks before main changes. If the agent’s credential can bypass those requirements, the intended stop may disappear. The credential’s permissions belong in the review alongside the branch setting.

Consider the moment after lunch. The developer opens the tax diff and sees a newly added rounding case, its result and the proposed commit. That is a coherent decision about a change. It is easier to understand than remembering which shell prompts were approved before lunch. The team can decide how much evidence that decision needs according to the consequences of a rounding error.

Keep automatic screening and bypass modes distinct, too. Claude Code’s current guide places bypassPermissions in isolated environments and describes permission decisions separately from the sandbox and outer isolation that constrain what an action can reach. ² A mode name alone tells the reviewer little about the checkout service’s deployment credential.

05Rehearse the route to main

A small rehearsal can use a disposable repository with the same launcher and a harmless stand-in for deployment. Have the agent prepare the tax fix, then attempt the publication paths that launcher supports. The expected result should name the stop: a local approval request or a remote rejection until review. This is a proposed exercise; we have not run it.

Include a command spelling that differs from the recipe and a resumed session. If either publishes the stand-in without the required decision, trace the credential and rule that allowed it. Keep the attempted command, revision and resulting state with the finding. The useful output is a specific route to repair.

That exercise also makes the cost visible. Count time spent supervising routine prompts, reviewing the completed patch and recovering from interruptions. A team may accept more unattended local work while keeping a deliberate publication step. The August evidence gives a reason to reconsider repetitive approval; the workflow rehearsal determines whether the team’s intended stop actually exists.