Ik heb Claude effe in de hoek gezet

Ik ben op dit moment bezig met een documentatieproject: een uitgebreide as-is analyse voor een klant, geschreven in Markdown-bestanden die via mkdocs worden omgezet naar een doorzoekbare wiki. Geen code, geen deployments, geen risicovolle acties. Gewoon tekst schrijven, herstructureren en aanvullen op basis van informatie die ik zelf aanlever. Voor dat soort werk laat ik Claude Code in de zogenaamde Auto-modus draaien: hij mag doorwerken zonder dat ik voortdurend "Yes" of "Allow" moet klikken, en een ingebouwde controlelaag beoordeelt op de achtergrond of een actie veilig genoeg is om zonder mijn tussenkomst uit te voeren.

Dat werkt vlot voor het eigenlijke schrijfwerk. Maar tijdens een gewoon gesprek over de inhoud van dat project merkte ik iets vreemds op: Claude Code leek dingen te weten, of net niet te weten, die niet klopten met wat ik verwachtte van een sessie die netjes tot mijn projectmap beperkt zou moeten blijven. Dat trok mijn aandacht, en wat volgde was een zoektocht die me meer leerde over hoe toegangsbeheer in deze tools écht werkt. Helaas -tot nu toe- zonder oplossing ...

De test met een onschuldig bestand over een beukhaag

Om zeker te zijn dat ik niet iets inbeeldde, deed ik een concrete test. Ik maakte een klein onschuldig tekstbestand aan, met wat informatie over de beukhaag als haagplant: standplaats, snoeitips, onderhoud. Niets met mijn project te maken.
Ik plaatste dat bestand bewust één niveau boven mijn projectmap, in de algemene ontwikkelmap waar ook mijn andere projecten staan.

Daarna vroeg ik Claude Code doodleuk wat hij wist over "Beukhaag" binnen de context van dit project. Als de toegang correct was afgeschermd, zou het antwoord simpel moeten zijn: niets, want dat woord komt nergens in mijn project voor. Als de toegang lekte, zou hij het bestand een niveau hoger kunnen vinden en lezen zonder dat ik daar ooit toestemming voor gaf.

Het resultaat van de eerste test was op zich correct: Claude Code gaf aan geen toegang te hebben tot mijn projectmap, laat staan de map erboven. Maar dat opende meteen een ander pad in het gesprek. Als hij geen toegang had, waarom kon hij dan af en toe wel bepaalde dingen lezen zonder daar expliciet toestemming voor te vragen? Dat bleek de kern van een veel groter vraagstuk.

Eerste poging: een instelling die niet deed wat ik dacht

Claude Code laat je toe om, per project, een configuratiebestand aan te maken waarin je instelt welke acties automatisch mogen, welke geweigerd worden, en welke een bevestiging vereisen. Concreet gaat het om een JSON-bestand op het pad .claude\settings.json, in de root van je projectmap. Er bestaat ook een tweede, optionele variant: .claude\settings.local.json. Die dient om lokale, persoonlijke afwijkingen bovenop de gedeelde projectinstellingen bij te houden, handig als je met een team aan hetzelfde project werkt en niet wil dat jouw eigen voorkeuren automatisch voor iedereen gaan gelden. Bij mij bestond dat bestand niet, dus telde enkel .claude\settings.json mee.

Mijn eerste, voor de hand liggende poging was: een lijst opstellen van wat wél mag (lezen en bewerken binnen mijn projectmap, een paar veelgebruikte terminalcommando's), en de rest standaard weigeren zonder dat ik ooit gevraagd word. Dit was mijn allereerste versie van .claude\settings.json:

{
  "permissions": {
    "defaultMode": "Auto",
    "allow": [
      "Read(./**)",
      "Edit(./**)",
      "Write(./**)",
      "Glob(./**)",
      "Grep(./**)",
      "Bash(git *)",
      "Bash(npm *)"
    ],
    "deny": [
      "Read(~/**)",
      "Read(//**)"
    ]
  }
}

Ik testte dat, en aanvankelijk leek het te werken. Tot ik merkte dat Claude Code, ondanks die instelling, toch af en toe een stap buiten de projectmap zette. Niet roekeloos, en niet voor iets schadelijks, maar wel voor dingen die volgens mijn regels gewoon niet hadden mogen gebeuren.

Het bleek dat ik zelf de verkeerde modus had gekozen. Er bestaat namelijk een fundamenteel verschil tussen twee instellingen die op het eerste gezicht hetzelfde lijken te doen: eentje die alles wat niet expliciet is toegestaan gewoon weigert, en eentje die voor niet-toegestane acties een soort automatische risicobeoordeling laat gebeuren op de achtergrond. Die tweede is precies de Auto-modus waar ik voor koos, om te vermijden dat ik constant moet klikken. Het probleem: die risicobeoordeling keurt dingen goed die er "onschuldig genoeg" uitzien, zelfs als ze buiten mijn expliciete regels vallen. Een tekstbestand lezen over een haagplant oogt voor zo'n beoordelingslaag natuurlijk volkomen onschuldig, dus werd het gewoon toegelaten.

Ik schakelde dus over naar de striktere variant: alles wat niet met naam op mijn lijst staat, wordt automatisch geweigerd, zonder vraag, zonder beoordeling, gewoon nee. Dat gaf me het gedrag dat ik eigenlijk vanaf het begin wilde: geen onderbrekingen, maar wel een harde grens.

Tweede poging: een schrijffout die alles op slot zette

Met de strengere modus actief, bleek al snel dat mijn regels zelf niet correct geschreven waren. De manier waarop je een pad in zo'n configuratiebestand aanduidt, blijkt gevoeliger dan je zou denken: een klein verschil in schrijfwijze bepaalt of een regel verwijst naar "alles binnen mijn projectmap", "alles op mijn hele harde schijf", of eigenlijk naar niets, omdat de schrijfwijze simpelweg niet herkend wordt als een geldig patroon.

Ik paste mijn regels aan, maar maakte daarbij een nieuwe fout: uit voorzichtigheid voegde ik een extra weigeringsregel toe, bedoeld als extra zekerheid tegen toegang buiten mijn projectmap. Die regel bleek achteraf zo breed geschreven te zijn dat hij letterlijk élke leesactie blokkeerde, ook diegene die netjes binnen mijn eigen projectmap vielen. Dit werd mijn .claude\settings.json op dat moment:

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Read(/**)",
      "Edit(/**)",
      "Write(/**)",
      "Glob(/**)",
      "Grep(/**)",
      "Bash(git *)",
      "Bash(npm *)"
    ],
    "deny": [
      "Read(~/**)",
      "Read(//**)"
    ]
  }
}

Het gevolg was hilarisch frustrerend: Claude Code kon plots niet eens meer zijn eigen instellingen lezen om me te laten zien wat er mis liep, laat staan een gewoon bestand in mijn project.

De les hier is er eentje die ik onderschat had: een weigeringsregel wint altijd van een toestemmingsregel, hoe specifiek die laatste ook is. Voeg je dus, met de beste bedoelingen, een te brede weigering toe "voor de zekerheid", dan kan die je eigen, correct opgestelde toestemmingen volledig overrulen. Minder regels, maar wel de juíste regels, bleek uiteindelijk beter dan meer regels.

Derde poging: terug naar de essentie

Ik verwijderde die te brede weigeringsregel volledig, en hield enkel een eenvoudige lijst over van wat wél mag: lezen en bewerken binnen mijn projectmap, zoeken binnen mijn projectmap, en een paar veelgebruikte terminalcommando's. Met de striktere modus als standaard zorgt de afwezigheid van een regel er automatisch voor dat iets geweigerd wordt, dus een aparte weigeringslijst is in principe overbodig. Dit werd de opgekuiste versie van .claude\settings.json:

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Read(/**)",
      "Edit(/**)",
      "Grep(/**)",
      "Bash(git *)",
      "Bash(npm *)"
    ]
  }
}

Dat gaf eindelijk het verwachte resultaat: zoeken binnen mijn eigen projectmap werkte weer, en een niveau hoger zoeken werd netjes geweigerd. Op dat moment dacht ik dat de zaak rond was.

En toch weer toegang tot buren-mappen

Bij een volgende test, nadat ik nog wat kleine aanpassingen had gedaan, bleek de toegang plots weer veel ruimer dan verwacht. Niet alleen mijn eigen projectmap, maar ook de map errond, inclusief compleet andere, niet-gerelateerde projecten die daar toevallig naast staan, en zelfs een systeemmap die niets met mijn documentatiewerk te maken heeft.

Dat wijst niet meer op een foutje in mijn projectconfiguratie zelf. Het wijst eerder op het bestaan van een tweede, algemenere configuratielaag, los van mijn project, die breder toegelaten regels bevat en die blijkbaar meetelt bovenop mijn projectspecifieke instellingen. Vermoedelijk het resultaat van maanden lang af en toe "onthoud dit, vraag het niet opnieuw" te hebben aangeklikt tijdens heel andere sessies, in heel andere mappen, zonder dat ik ooit besefte dat die keuzes zich ergens permanent opstapelen.

Op het moment van schrijven ben ik nog steeds bezig om die algemene laag te lokaliseren en op te kuisen. Het is een goede herinnering dat toegangsbeheer in dit soort tools niet één instelling is die je één keer goed zet, maar een opeenstapeling van keuzes over tijd heen, verspreid over meerdere bestanden, die je best af en toe eens grondig doorneemt in plaats van te vertrouwen op je geheugen van wat je ooit hebt toegestaan.

Waarom dit voor mij vooral een principekwestie is

Ik wil hier eerlijk over zijn: voor dit specifieke project is het risico op dit moment beperkt. Ik werk in Auto-modus, maar dat is verantwoord, want het gaat om tekstueel werk, Markdown-documentatie op basis van informatie die ik zelf aanlever, zonder code die iets kan uitvoeren of systemen die iets kunnen wijzigen. Er was hier geen data in gevaar, geen script dat iets verwijderde, niets dat echt fout kon lopen.

Maar dat is precies waarom ik dit toch belangrijk vind om uit te zoeken en te delen. Als de toegangsgrenzen van een tool zo lastig correct in te stellen blijken bij laag-risico tekstwerk, dan wil ik dat zeker onder de knie hebben vóór ik dezelfde tool ooit inzet voor iets met echte gevolgen: klantdata, productiecode, of systemen die je niet zomaar kan terugdraaien. Een AI-agent die "waarschijnlijk wel braaf blijft" is geen toegangsbeheer. Een configuratie die aantoonbaar standhoudt, wel.

Het is ook een goede les in vendor-onafhankelijkheid, iets waar ik in mijn werk als fractional consultant vaak op hamer: vertrouw niet blindelings op de standaardinstellingen van een tool, ook niet van een tool die je graag gebruikt en vertrouwt. Test je aannames. Plant desnoods een onschuldig bestandje ergens waar het niet hoort, en kijk of je tool het vindt.

Waar ik nu sta

Op dit moment is de projectconfiguratie zelf correct: een eenvoudige, strikte lijst van wat mag binnen de projectmap, met een modus die al de rest automatisch weigert zonder te vragen. Wat nog niet opgelost is, is die bredere, algemene laag die blijkbaar over mijn projectinstellingen heen zit en de grenzen weer oprekt. Ik ben die aan het opsporen en ben van plan om ze grondig op te kuisen zodat elke projectmap terug op zichzelf staat, zoals het hoort.

Heeft iemand van jullie dit al eens grondig uitgezocht? Ik ben benieuwd of er een structurele aanpak bestaat om dit soort toegang écht waterdicht te krijgen, zonder dat je om de zoveel maanden opnieuw moet uitpluizen wat er ooit per ongeluk is toegestaan. Laat het gerust weten.