Een vervelende softwarebeveiligingsvalkuil duikt op: Don’t Ask Again lekt. Wanneer ontwikkelaars Claude Code een commando laten uitvoeren met de keuze “Yes, and don’t ask again”, kan de assistant de goedgekeurde opdracht met daarin eventuele wachtwoorden, tokens en sleutels opslaan in een projectinstellingsbestand. In veel gevallen is die informatie vervolgens in publieke GitHub-repositories terechtgekomen, waardoor derden de geheimen konden lezen.
Uit onderzoek van Apiiro blijkt dat er 1.122 publieke kopieën van een specifiek bestand bestaan die ten minste één geheim bevatten. Daarbij gaat het om verschillende soorten credentials, waaronder database-wachtwoorden en cloud- of server-toegang. Belangrijk: zelfs als teams het bestand later verwijderen, blijft de kans bestaan dat geheimen nog terug te vinden zijn via eerdere commits en forks.
Wat is er precies gelekt?
Het gaat om het bestand .claude/settings.local.json binnen een project. Wanneer Claude Code standaard om bevestiging vraagt voordat shellcommando’s worden uitgevoerd, kan een gebruiker kiezen voor “Yes, and don’t ask again”. In dat geval wordt een allow-regel opgeslagen, waarbij Claude Code in latere sessies vergelijkbare commando’s kan uitvoeren zonder opnieuw om toestemming te vragen.
Het gevaar zit in de combinatie van twee dingen: de allow-regel kan word-voor-word worden opgeslagen en omvat dan ook de inhoud die de gebruiker eerder in het commando heeft getypt. Als daarin een wachtwoord, token of sleutel zat, belandt dat geheim in het bestand en dus (bij commits) in de repository.
Alleen patterns of ook exacte opdrachten?
Soms gaat het om een patroon, zoals een wildcard (bijvoorbeeld “npm test *”). Maar de onderzoekers beschrijven ook gevallen waarin de opgeslagen regel de exacte opdracht is. Juist dan kan het commando zelf geheimen bevatten die in platte tekst worden opgeslagen.
Waarom verdwijnt het niet zomaar na verwijderen?
Een veelgemaakte gedachte is: “Als we het bestand weghalen, is het probleem opgelost.” Helaas niet. Verwijderen uit het project herstelt de geschiedenis niet. Geheimen kunnen nog steeds zichtbaar zijn in git history en in forks van het repository. De onderzoekers noemen bovendien dat bescherming die Claude Code probeert te bieden (door het bestand lokaal te negeren in iemands eigen git-instellingen) niet helpt voor bestanden die al eerder zijn gecommit.
Daarnaast lijkt Claude Code het bestand niet te koppelen aan een project-specifieke .gitignore. Dat betekent dat de “makkelijkheid” voor de gebruiker niet automatisch doorwerkt naar het hele team of naar toekomstige checks bij CI/CD.
Hoe groot was het probleem op GitHub?
Apiiro rapporteert dat er maar liefst 104.185 kopieën van het betreffende bestand zijn gevonden in 103.617 repositories. Binnen die set zijn 1.122 publieke kopieën geïdentificeerd waarin ten minste één geheim zat. In totaal gaat het om 1.379 verschillende geheimen.
De onderzoekers geven aan dat een waarde als “secret” werd geteld wanneer die matchte met bekende sleutel- of wachtwoordformaten, of wanneer een wachtwoord/token naast het adres van een publieke server stond. Ook moest een AI-reviewer akkoord geven. Ze beschrijven niet of iemand de geheimen daadwerkelijk al misbruikte, maar het feit dat ze openbaar leesbaar waren is op zichzelf al risicovol.
Welke typen geheimen kwamen voor?
Meer dan een derde van de geheimen richtte direct toegang tot databases op, waaronder 379 databasewachtwoorden. Daarnaast werden onder meer:
- 43 SSH-logins gevonden voor toegang tot openbare servers
- 42 tokens voor GitHub, GitLab en npm
- 23 AWS-sleutels
De onderzoekers noemen dat er binnen de groep eigenaren ook 63 organisaties zaten, vooral softwarebedrijven. In de meest sprekende gevallen ging het bijvoorbeeld om een admin-level cloud key van een databasevendor en om het eigenaarwachtwoord van een database met medische gegevens.
Wat je nu moet doen (voor ontwikkelaars)
Het advies is helder en tijdkritisch. Eerst rotatie, daarna pas opruiming. Daarmee voorkom je dat kwaadwillenden nog kunnen inloggen zolang credentials nog geldig zijn.
- Zoek je repositories af: controleer GitHub-omgevingen op .claude/settings.local.json en ook op .claude/settings.json. Check daarbij de git history, ook in projecten waar de bestanden inmiddels weg zijn.
- Roteren vóór opschonen: verander alle wachtwoorden, tokens en sleutels die het bestand ooit kan hebben bevat.
- Niet meer tracken: stop met het versioneren van het lokale bestand via git rm –cached .claude/settings.local.json en voeg het toe aan de project .gitignore.
- Verwijder regels met geheimen: open het bestand op je eigen computer, ook als het nooit gecommit is, en verwijder elke regel die een geheim bevat.
- Gebruik variabelen: laat commando’s geen geheimen in platte tekst bevatten. Gebruik bijvoorbeeld een variabelenaam (zoals $DB_URL) die verwijst naar een secrets manager, zodat de allow-rule de variabele opslaat en niet de waarde.
- Keuze voor patronen: keur liever patterns goed (zoals een commando met wildcard) in plaats van losse, exacte opdrachten waar gevoelige input in kan zitten.
Ook belangrijk: kopieën die nooit naar GitHub zijn geüpload, verdienen aandacht. Het bestand staat namelijk als plain JSON in de projectmap en kan ook terechtkomen in een npm-package, Docker image, zip-archief of een gesynchroniseerde map.
Wat beveiligingsteams moeten regelen
Voor security en compliance is het vooral zaak om de ontwikkelworkflow zo te laten scannen dat deze categorie secrets niet meer door de mazen glipt.
- Behandel agentmappen als secrets-bronnen, vergelijkbaar met .env-bestanden: denk aan mappen en data zoals .claude/, .cursor/, .gemini/ en .specstory/, inclusief geheugendata of “agent memory”-bestanden.
- Breid secret scanning uit: voeg pre-commit en CI-scanning toe die ook git history meeneemt.
- Pak verborgen platte-tekstgevallen aan: scanners moeten ook letten op wachtwoorden die in commando’s zijn getypt, niet alleen op bekende key-formaten.
- Pas organisatiebrede .gitignore-templates aan, zodat .claude/settings.local.json standaard niet wordt meegenomen.
- Prioriteer credentials die gekoppeld zijn aan publieke toegang: de onderzoekers adviseren te beginnen met credentials die samenhangen met publieke servers, omdat die directere toegang geven.
Waarom scanners dit kunnen missen
In het onderzoek worden secret-scanners vergeleken. De onderzoekers beschrijven dat niet alle tools deze specifieke geheimen even goed detecteren, vooral wanneer een geheim zich verstopt in de context van een commando (bijvoorbeeld als wachtwoord dat op zichzelf “gewoon woordelijk” lijkt). In hun aanpak werden onder meer gitleaks en TruffleHog uitgevoerd, zonder dat tools de extra verificatiestap deden. Daardoor ontbraken juist sommige gevallen.
Het punt voor teams: niet alleen “bekende formaten” tellen. Als een password-token in platte tekst in een shell-commando belandt, lijkt het soms minder op een typische credential-handtekening—en daarom is gerichte detectie nodig.
Praktische eerste stappen om schade te beperken
Als je vandaag nog moet handelen, begin dan zo:
- Voer direct een repo- en historiecheck uit op .claude/settings.local.json (en .claude/settings.json).
- Roteren: vervang eerst alle credentials die ooit in deze bestanden kunnen hebben gestaan.
- Pas daarna opruimen: verwijder regels, commit correcties en zorg dat het bestand niet meer wordt tracked.
Door deze volgorde te volgen voorkom je dat opschonen alleen “laat” is. Het geheim kan dan nog steeds geldig zijn terwijl je het bestand probeert schoon te maken.
Gerelateerd: patchvertraging en de bredere impact van fouten
Deze casus past in een breder patroon rond ontwikkel- en patchprocessen: zelfs als het probleem bekend raakt, bepaalt hoe snel teams reageren hoeveel systemen geraakt worden. Als je wilt kijken naar hoe vertraging in fixes en updates de risico’s kan vergroten, lees ook Japan zet in op dreiging en patchvertraging 2026-aanpak en de achterliggende analyse rondom dreiging en patchvertraging in 2026.
Conclusie
Don’t Ask Again lekt: wat bedoeld is om het ontwikkelproces sneller te maken, kan in de praktijk leiden tot openbaar toegankelijke wachtwoorden en API-sleutels. De kern is eenvoudig maar hard: Claude Code kan goedgekeurde commando’s met geheimen opslaan in .claude/settings.local.json, waarna die informatie via commits, historie en forks in publieke repositories kan belanden.
Wie dit soort agent-bestanden gebruikt, moet snel schakelen: zoek het op, roteer eerst en pas daarna pas opruimen. Met gerichte secret scanning in pre-commit en CI en met betere regels voor commando’s (variabelen in plaats van platte geheimen) voorkom je dat dit type lek zich herhaalt.
Bron: https://thehackernews.com/2026/11/claude-codes-dont-ask-again-file.html
