Claude Code vraagt vanaf 14 augustus geen toestemming meer: zo zet jij grenzen

Vanaf 14 augustus vraagt Claude Code niet meer of het een commando mag uitvoeren. Anthropic zet die dag auto mode aan als standaard voor alle nieuwe sessies op de Pro-, Max- en Team-abonnementen. De agent draait dan door zonder tussenstops, en een aparte classifier beslist achter de schermen wat wel en niet mag. De reden die Anthropic geeft is ongemakkelijk eerlijk: gebruikers klikken 97 procent van alle toestemmingsvragen weg. Die vraag was dus allang geen controle meer. Wat er nu voor in de plaats komt, kun je zelf bijstellen, en dat is precies wat je deze week moet doen.

Wat verandert er precies op 14 augustus?

Vanaf die datum starten nieuwe sessies op Pro, Max en Team in auto mode in plaats van in de handmatige modus. Wie zelf al een andere standaardmodus had ingesteld, krijgt eenmalig de vraag of hij wil overstappen; wie die vraag wegklikt, houdt zijn eigen instelling. Heeft je werkgever de modus centraal vastgezet via managed settings, dan verandert er niets voor jou.

Voor Enterprise-klanten en iedereen die via de API, Amazon Bedrock, Google Cloud of Microsoft Foundry werkt, blijft auto mode voorlopig een keuze. Anthropic zegt die groep binnen een maand te volgen.

Het mechanisme eronder is simpeler dan het klinkt. In de oude situatie onderbrak Claude zichzelf bij elk shell-commando en elke bestandswijziging met een ja-nee-vraag aan jou. In auto mode gaat elke tool-call langs een tweede model, dat alleen kijkt of de actie past bij wat je hebt gevraagd en of hij omkeerbaar is. Denk aan een sluiswachter die niet vraagt waar je heen vaart, maar wel weigert de deur te openen als het waterpeil niet klopt.

Waarom denkt Anthropic dat dit veiliger is?

Anthropic liet 1.053 betaalde developers een sessie doorlopen waarin bewust een gevaarlijk commando was verstopt, zonder dat ze wisten waarop werd gelet. De mensen onderschepten dat commando in 143 van de 1.053 gevallen, oftewel 13,6 procent. Auto mode blokkeerde er 937, oftewel 89 procent.

Dat gat van 75 procentpunt is het hele argument. Een toestemmingsvraag die je twintig keer per uur ziet, lees je niet meer. Je drukt op enter omdat je verder wilt.

Ook naar prompt injectie is gekeken, de aanval waarbij kwaadaardige instructies verstopt zitten in een webpagina of een bestand dat de agent leest. In een test met browsertaken slaagde geen van de 720 aanvalspogingen tegen Claude Fable 5, Opus 5 en Sonnet 5 in auto mode. Anthropic zette de eigen cijfers in dezelfde grafiek naast die van GPT-5.6 Sol, waar in de meest vrije stand (Full Access) 25,53 procent van de aanvallen wel doel trof.

Belangrijke kanttekening: beide grafieken komen van de partij die het product verkoopt. Er is nog geen onafhankelijke herhaling van deze test.

Wat blijft de classifier tegenhouden?

De classifier blokkeert standaard alles wat onomkeerbaar of destructief is of gegevens naar buiten je omgeving stuurt. Concreet betekent dat: een force push, het verwijderen van remote branches of releases, het herschrijven van geschiedenis, deploys naar productie, en het bekende recept waarbij een script rechtstreeks van internet wordt gedownload en uitgevoerd.

Wat wel mag zonder overleg, is ruimer dan veel mensen verwachten. Pushen naar elke branch van de repository waarin je werkt is toegestaan, inclusief de hoofdbranch, en een pull request aanmaken ook. Branches waarvan de naam naar een deploy ruikt, zoals production, release of gh-pages, vallen daar niet onder en worden apart beoordeeld.

Overigens is de standaard-vertrouwensgrens smal getrokken: de classifier vertrouwt alleen je werkdirectory en de remotes die in die repo zijn ingesteld. Alles daarbuiten, van je bedrijfs-GitHub tot je eigen cloudbucket, geldt als een mogelijk lek totdat je het aanmeldt.

Zo zet je vóór donderdag een harde grens

Een ask-regel en een deny-regel worden allebei beoordeeld vóórdat de classifier eraan te pas komt. De classifier kan ze niet overrulen, en jouw eigen instructie in het gesprek ook niet. Dat maakt ze de enige echt harde grens die je hebt.

Stap 1. Open je persoonlijke instellingenbestand op ~/.claude/settings.json. Bestaat het nog niet, maak het dan aan met een lege JSON-structuur.

Stap 2. Bepaal welke handelingen je altijd zelf wilt zien voordat ze gebeuren. Voor de meeste teams zijn dat pushes en pull requests. Zet die in een ask-blok:

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

Stap 3. Bepaal wat er nooit mag gebeuren, ook niet als je er zelf om vraagt in een vermoeid moment. Dat gaat in een deny-blok, dat de actie blokkeert voordat de classifier iets ziet:

{
  "permissions": {
    "deny": [
      "Bash(terraform destroy *)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

Stap 4. Controleer wat er nu daadwerkelijk actief is. Deze opdracht laat de regels zien waarmee de classifier werkt, inclusief de ingebouwde standaarden:

claude auto-mode config

Stap 5. Wil je helemaal terug naar de oude situatie, druk dan tijdens een sessie op Shift+Tab tot je bij Manual uitkomt, of gebruik in de desktop-app de keuzelijst voor de modus. Wie het voor een heel team wil dichtzetten, kan in managed settings permissions.disableAutoMode op "disable" zetten. Die instelling kan een individuele developer niet overschrijven.

Een detail dat makkelijk misgaat: de classifier leest de autoMode-instellingen níét uit het projectbestand .claude/settings.json, juist omdat een binnengehaalde repository daar zijn eigen versoepelingen in zou kunnen zetten. Zet je vertrouwensregels dus in ~/.claude/settings.json of in de centraal beheerde instellingen.

Zo vertel je de classifier wat je wél vertrouwt

Loopt Claude steeds vast op dezelfde blokkade, dan mist de classifier context over je infrastructuur. Je beschrijft die in gewone taal, niet in patronen of regex. De letterlijke tekst "$defaults" houdt de ingebouwde regels intact, en jouw regels komen erbij:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Organisatie: Voorbeeld BV. Primair gebruik: webontwikkeling",
      "Source control: github.com/voorbeeld-bv en alle repos daaronder",
      "Trusted internal domains: *.intern.voorbeeld.nl",
      "Sensitive data locations: de klantendatabase op db.voorbeeld.nl bevat persoonsgegevens"
    ]
  }
}

Die laatste regel is voor Nederlandse bedrijven de belangrijkste. Onder de AVG blijf jij verwerkingsverantwoordelijke voor wat er met persoonsgegevens gebeurt, ook als een agent het commando typte. De classifier gaat niet raden welke database gevoelig is; hij beschermt wat je benoemt en valt daarbuiten terug op een grove vuistregel, namelijk alles waar het woord prod in voorkomt.

Nog een laag strakker kan met deze schakelaar, die elke shell-opdracht langs de classifier stuurt, ook de opdrachten die je zelf ooit hebt goedgekeurd met een smalle allow-regel:

{
  "autoMode": {
    "classifyAllShell": true
  }
}

Het kost wat snelheid, want elk commando wacht nu op een beoordeling. In ruil daarvoor glipt er geen destructief argument doorheen via een oude allow-regel die je allang vergeten bent.

Wat vinden ervaren gebruikers ervan?

De reacties lopen uiteen van praktische opluchting tot principiële argwaan. Ontwikkelaar en AI-onderzoeker Simon Willison, die al jaren over prompt injectie schrijft, ziet het nut maar houdt een slag om de arm.

“Ik geloof absoluut dat auto mode een betere oplossing is dan mensen constant acties laten goedkeuren.”

Simon Willison, ontwikkelaar en AI-onderzoeker

Tegelijk zegt hij graag onafhankelijke bevestiging te willen zien van de claim over prompt injectie, en wijst hij op een gat dat auto mode niet dicht: een aanval via een besmet softwarepakket dat je zelf installeert. De instructies zitten dan in code die je agent volstrekt legitiem uitvoert. Willison zegt zelf te blijven zoeken naar manieren om agents te draaien zonder toegang tot data of tools die schade kunnen aanrichten.

Op Hacker News klinkt de andere kant: developers die maandenlang in auto mode werken, ook voor beheerwerk op servers via SSH, melden dat ze geen enkel moment iets doms hebben zien gebeuren. Die twee ervaringen spreken elkaar minder tegen dan het lijkt. Het risico zit niet in het gemiddelde commando, maar in de zeldzame situatie waarin een externe bron de agent iets influistert.

Drie dingen om vóór 14 augustus te regelen

Werk je zelf met Claude Code, of doet iemand in je team dat op een betaald Claude-abonnement, dan is dit de korte checklist. Eén: zet je ask-regels voor pushes en pull requests in ~/.claude/settings.json, zodat er een mens naar je repository blijft kijken. Twee: benoem je gevoelige databases en interne domeinen in autoMode.environment, want wat je niet benoemt, wordt geraden. Drie: draai één keer claude auto-mode config en lees wat eruit komt, zodat je weet welke grenzen er donderdag echt staan.

Wie liever eerst kijkt hoe het bevalt, kan de oude modus gewoon terugzetten met Shift+Tab. Maar het bredere patroon is duidelijk: de toestemmingsvraag als veiligheidsmaatregel is aan het verdwijnen, en wat ervoor terugkomt zijn regels die je vooraf opschrijft. Wie eerder al gevaarlijke commando's blokkeerde met hooks en deny-regels heeft dat werk al gedaan. De rest heeft nog drie dagen. In het Nederlandse mkb groeit het gebruik van dit soort agents hard, zoals te zien is in de MKB-cijfers van TheAIDaily, en de meeste bedrijven hebben deze instellingen nog nooit aangeraakt. Meer achtergrond over de tool zelf staat in ons overzicht van Claude Code.