In juni schreef ik hier dat ik van Plan mode was afgestapt en alles in auto mode deed. Dat was toen een keuze. Ik had het aangezet, ik wist wat het deed, en als het misging was dat mijn probleem.
Sinds 14 augustus is het geen keuze meer maar het vertrekpunt. Nieuwe sessies op Pro, Max en Team starten in auto mode. Dat is een ander gesprek dan mijn eigen voorkeur, want een standaard geldt ook voor iedereen die er nooit over heeft nagedacht.
Anthropic legde er een blogpost, een engineering-verhaal en een video bij. Die video is de duidelijkste uitleg die ik erover heb gezien, dus die staat hieronder integraal.
Wat er verandert, en voor wie
Vanaf 14 augustus 2026 draaien nieuwe sessies op Pro, Max en Team standaard in auto mode. Had je zelf al een andere standaard ingesteld, dan krijg je eenmalig de vraag of je wilt overstappen. Heb je een vaste standaard vastgezet, dan verandert er niets voor je. Terug naar handmatig goedkeuren gaat met Shift+Tab.
De classifier kost extra tokens per tool-aanroep. Die overhead wordt op Pro, Max en Team niet meer doorberekend, en dat gaat in per 7 augustus.
Op Claude Enterprise, de Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud’s Agent Platform en Microsoft Foundry blijft auto mode voorlopig opt-in, zodat beheerders de wijziging kunnen bekijken. Anthropic zegt het binnen een maand ook daar standaard te maken. Enterprise-beheerders die nu al willen, kunnen het via managed settings zetten.
Waarom Anthropic dit doet
Het argument staat of valt bij één getal: 97 procent van alle permissie-prompts in Claude Code wordt goedgekeurd. Vaak zo snel dat het meer op wegklikken lijkt dan op beoordelen.
Dat cijfer krijgt betekenis door het contrast ernaast. Als Claude een plan voorlegt, wijzen gebruikers 39 procent daarvan af. Bij losse permissieverzoeken is dat 3 procent. Mensen lezen dus wel degelijk, maar niet honderd keer per dag hetzelfde dialoogvenster.
Je ziet het ook terug in wat mensen zelf instellen. In juni 2026 had 49,5 procent van de actieve CLI-gebruikers handmatig een Bash-allow-regel aangemaakt: 5 procent geeft elk shell-commando vrij, 43 procent heeft interpreter-regels als Bash(python:*) die in de praktijk op hetzelfde neerkomen. Dat aandeel groeit met ongeveer 5 procentpunt per vijf weken. Daarnaast heeft 62 procent weleens bypassPermissions gebruikt of op “niet meer vragen” geklikt, en 25 procent van de interactieve sessies begint meteen in bypass.
Kortom, de veiligheidsmaatregel werd massaal uitgezet omdat hij in de weg zat. Auto mode is de poging om er iets voor terug te zetten dat mensen wel laten staan.
Hoe de beoordeling werkt
Het makkelijke misverstand is dat Claude nu zijn eigen acties goedkeurt. Dat is niet wat er gebeurt, en het onderscheid is de kern van het ontwerp. Claude die zichzelf beoordeelt, is je eigen pull request schrijven, reviewen en mergen.
In plaats daarvan gaat elke actie langs een aparte classifier. Die ziet jouw berichten en de tool-aanroepen van Claude. Wat hij níet ziet: Claudes redenering, Claudes antwoorden aan jou, en de uitvoer van tools. Dat is bewust. Als de classifier Claudes eigen onderbouwing leest, kan Claude hem overtuigen. En omdat tool-uitvoer de plek is waar vijandige inhoud binnenkomt, is het wegstrippen daarvan meteen de belangrijkste verdediging tegen prompt injection op dat niveau.
De check draait in twee trappen. Trap één is een snelle ja-of-nee zonder redenering, afgesteld op “bij twijfel blokkeren”. Alleen wat daar wordt gemarkeerd, gaat naar trap twee, die dezelfde invoer nog eens met redenering bekijkt. Op echt verkeer haalt trap één 8,5 procent vals alarm; de volledige keten brengt dat terug naar 0,4 procent.
Niet alles komt bij die classifier terecht. Je eigen deny-, ask- en allow-regels gaan eerst. Daarna sorteert een tier-check op risico:
| Tier | Wat er langsgaat | Wat er gebeurt |
|---|---|---|
| 1 | Lezen, zoeken, code-navigatie, todo’s, plan-overgangen | Direct toegestaan |
| 2 | Bestanden schrijven en bewerken binnen je projectmap | Direct toegestaan, want terug te draaien via versiebeheer |
| 3 | Shell-commando’s, web fetches, externe tools, subagents, bestandsacties buiten je project | Naar de classifier |
Eén uitzondering is belangrijk genoeg om apart te noemen. Zodra je in auto mode werkt, worden allow-regels die neerkomen op willekeurige code-uitvoering opzijgezet: blanket shell-toegang, interpreter-regels als python:* of node:*, package-manager-runs. Anders zou juist het gevaarlijkste commando de classifier overslaan. Je settings-bestand wordt niet aangepast; de regels gelden weer zodra je van modus wisselt. Smalle regels, zoals het toestaan van een formatter, blijven wel gewoon werken.
En na goedkeuring is het nog niet klaar. Een server-side probe scant elke tool-uitvoer op verstopte instructies voordat die de context van Claude in gaat, en hangt er een waarschuwing bij als er iets verdachts in staat. Een aanval moet dus langs die probe én langs een classifier die de volgende actie opnieuw tegen jouw opdracht houdt.
Blokkeert de classifier iets, dan zoekt Claude meestal zelf een veiligere weg, of vraagt het je alsnog. Bij drie blokkades achter elkaar, of twintig in één sessie, valt Claude Code terug op handmatig goedkeuren.
De cijfers, inclusief de vervelende
De studie die het meest wordt geciteerd: 1.053 betaalde professionele testers in een testomgeving. Halverwege hun sessie werd één permissie-prompt vervangen door een duidelijk gevaarlijk commando. De testers hielden dat in 13,6 procent van de gevallen tegen (143 van 1.053), auto mode in 89 procent (937 van 1.053). Direct tegenover elkaar: auto mode blokkeerde 800 commando’s die een mens goedkeurde, mensen blokkeerden er 6 die auto mode doorliet.
Het patroon binnen die studie vind ik veelzeggender dan de uitkomst. Vroeg in een sessie hielden testers ongeveer 17 procent tegen; na vijftig eerdere prompts was dat gezakt naar ongeveer 5 procent. De blokkeerkans van de classifier bleef gelijk, hoe lang de sessie ook duurde. Aandacht slijt, een model niet.
In echt verkeer, over gemarkeerde sessies van mei en juni 2026: op productie-ernst (7 of hoger op hun schaal) bevatte 6,3 procent van de handmatig goedgekeurde sessies schade die de gebruiker niet had gevraagd, tegen 2,4 procent van de auto mode-sessies.
Op prompt injection lieten ze een externe partij, Trajectory Labs, 72 scenario’s elk tien keer draaien. Van die 720 pogingen slaagde er geen enkele tegen Fable 5, Opus 5 en Sonnet 5 in auto mode. Tegen GPT-5.6 Sol in de Auto-review-modus van Codex slaagde 5,83 procent.
En dan de cijfers die minder goed uitkomen, die Anthropic zelf publiceert. Op een verzameling van 52 echte gevallen waarin het model te ver ging, laat de volledige keten er 17 procent doorheen. Hun eigen analyse van die missers is scherp: de classifier ziet het gevaar meestal wél. Wat hij verkeerd inschat, is of jouw toestemming ook dékt wat er nu gebeurt. “Ruim die PR even op” is gezegd, force-pushen niet. Een eerdere goedkeuring van iets soortgelijks is nog geen patroon. Ze schrijven erbij dat ze er met prompt-engineering niet uit zijn gekomen.
Anthropic zet er zelf de eerlijkste zin bij die je in zo’n post kunt zetten: kom je van --dangerously-skip-permissions, dan is dit een flinke vooruitgang. Keurde je alles zorgvuldig met de hand goed, dan lever je iets in.
De kanttekening
Drie dingen zitten me dwars, en geen ervan maakt auto mode een slecht idee.
De standaard is de echte wijziging, niet de functie. Auto mode bestond al maanden en je kon het aanzetten. Wat er nu gebeurt is dat het oordeel over “mag dit” verschuift van jou naar een model dat jij niet in handen hebt, voor iedereen die niets doet. Dat is precies de groep die het niet gaat instellen. De cijfers zeggen dat die verschuiving gemiddeld beter uitpakt, en ik geloof dat. Maar “gemiddeld beter” is iets anders dan “jouw geval”.
De vertrouwensgrens staat standaard heel krap. De classifier rekent alleen je werkmap en je git-remotes tot “binnen”. Alles daarbuiten is extern, inclusief de infrastructuur van je eigen organisatie. Dat is de veilige kant om op te falen, maar het betekent ook dat auto mode zonder configuratie ofwel te veel blokkeert, ofwel je leert om blokkades weg te wuiven. Dat laatste is dezelfde gewoonte als 97 procent wegklikken, één laag hoger.
Er wordt meer meegelezen dan eerst. De probe die tool-uitvoer scant, draait server-side. Bestanden die je leest en pagina’s die je ophaalt gaan dus langs een controle bij Anthropic voordat het model ze ziet. Dat is de reden dat de verdediging tegen prompt injection werkt, en het is een reële uitbreiding van wat er van je werk de deur uit gaat. Voor een openbaar project maakt dat weinig uit. Voor werk met persoonsgegevens is het de vraag die je vooraf stelt, niet achteraf.
Wat ik zelf doe: auto mode aan laten staan, en de environment-beschrijving invullen zodra ik in een repo werk die iets aanraakt buiten mijn eigen mappen. Voor productie-infrastructuur ga ik er gewoon bij zitten. Dat is ook wat Anthropic adviseert, en ik zie geen reden om slimmer te willen zijn dan de mensen die de missers hebben geteld.
Veelgestelde vragen
Hoe zet ik auto mode weer uit?
Met Shift+Tab wissel je van modus tijdens een sessie. Wil je het permanent anders, zet dan permissions.defaultMode in ~/.claude/settings.json. Een vastgezette standaard wordt niet overschreven door deze wijziging.
Betaal ik voor de classifier?
Op Pro, Max en Team niet meer, per 7 augustus 2026. Op de andere platformen wordt de overhead nog wel doorberekend, met de aankondiging dat ook dat verandert wanneer auto mode daar standaard wordt.
Wat als de classifier iets blokkeert dat ik wel wil?
Meestal zoekt Claude zelf een andere route, of het vraagt het je alsnog. Loopt het vast, dan valt de sessie na drie blokkades achter elkaar of twintig in totaal terug op handmatig goedkeuren. Structureel oplossen doe je met de environment-beschrijving en allow-uitzonderingen, niet door de modus uit te zetten.
Werkt auto mode ook voor subagents?
Ja. De classifier draait aan beide kanten van een overdracht: bij het uitzetten van de taak en bij het teruggeven van het resultaat. Bij de terugkeer wordt de volledige actiegeschiedenis van de subagent bekeken, en bij twijfel gaat er een waarschuwing mee terug in plaats van dat het resultaat verdwijnt.
Is auto mode nu veiliger dan zelf goedkeuren?
Volgens elke meting die Anthropic publiceert wel, vergeleken met hoe mensen in de praktijk goedkeuren. Vergeleken met iemand die daadwerkelijk elk commando leest, niet per se. Zij zeggen er zelf bij dat het geen vervanging is van eigen review bij ingrijpende infrastructuur.
Bronnen
- Anthropic, Auto mode is now the default in Claude Code for Pro, Max, and Team plans, 7 augustus 2026
- Anthropic Engineering, How we built Claude Code auto mode: a safer way to skip permissions, 25 maart 2026
- Anthropic, video How auto mode works with Claude Code
- Claude Code Docs, Choose a permission mode
- @ClaudeDevs op X, aankondiging van 10 augustus 2026
Cijfers overgenomen uit de bovenstaande publicaties van Anthropic en gecontroleerd op 10 augustus 2026. De classifier draait volgens de documentatie standaard op Claude Sonnet 5; de engineering-post van maart noemt nog Sonnet 4.6, dus dat is sindsdien gewijzigd. De genoemde percentages komen uit onderzoek dat Anthropic zelf heeft opgezet of laten uitvoeren; ik heb ze niet onafhankelijk kunnen reproduceren.