Innhold Vis
Hvis du bruker Claude Code, bør du kontrollere .claude/settings.local.json før neste commit. Valget «Yes, and don’t ask again» kan lagre hele shell-kommandoen i fila – med passord, API-nøkler og tokens i klartekst.
Sikkerhetsselskapet Apiiro fant 104 185 offentlige kopier av denne lokale innstillingsfila på GitHub. 1 122 av dem inneholdt til sammen 1 379 det forskerne klassifiserte som reelle hemmeligheter. Blant funnene var databasepassord, skynøkler, API-tokens, private nøkler og root-innlogginger til offentlige servere.
Dette er ikke bare en historie om utviklere som burde ha sett bedre etter før de kjørte git add. Et kodeverktøy som lagrer en hemmelighet i en fil under prosjektmappa, og deretter lar beskyttelsen være avhengig av den enkelte maskinens globale git-oppsett, er ikke sikkert som standard. Du må rydde opp nå dersom fila har vært sporet – for sletting alene gjør ikke en lekket nøkkel hemmelig igjen.
Hvordan havner hemmelighetene i Claude Code-fila?
Claude Code kan lagre en godkjent shell-kommando som en tillatelsesregel når brukeren velger at verktøyet ikke skal spørre igjen. Dersom kommandoen inneholder PGPASSWORD, et bearer-token, et databasepassord eller en nøkkel direkte i kommandolinjen, kan også den verdien bli skrevet til .claude/settings.local.json. Apiiro dokumenterte mekanismen og kartla de offentlige filene mellom 1. og 3. november 2026.
Det er nettopp brukeropplevelsen som gjør dette så lett å overse. Du ber agenten sjekke en database, kjøre en migrering eller kalle et API. Claude Code foreslår en lang kommando, du godkjenner den og velger at samme type kommando ikke skal avbryte deg igjen. Tillatelsesfila ender da med å huske mer enn selve avgjørelsen. Den kan huske den konkrete kommandoen ordrett.
Anthropics dokumentasjon beskriver settings.local.json som personlige prosjektinnstillinger som ikke skal deles med teamet. Første gang Claude Code skriver fila i et git-repositorium, forsøker verktøyet å legge mønsteret i brukerens globale git-exclude-fil. Det hjelper på den maskinen, men følger ikke med prosjektet til en annen maskin, en container eller en mappe som senere blir gjort om til et repositorium. Er fila allerede sporet, er det for sent for en ignore-regel å skjule den.
Hvor omfattende er Claude Code-lekkasjen?
Apiiro fant 104 185 kopier av .claude/settings.local.json i 103 617 offentlige GitHub-repositorier. Av disse inneholdt 1 122 filer, omtrent 1,1 prosent, minst én hemmelighet etter forskernes kriterier. De 1 379 unike funnene fordelte seg på 636 nøkler med kjente leverandørformater og 743 passord eller tokens koblet til offentlige verter.
Mer enn en tredjedel ga direkte tilgang til databaser: 379 databasepassord og 122 Supabase service role-nøkler. Forskerne fant også 103 Supabase-kontotokens, 43 SSH-innlogginger, 42 tokens til GitHub, GitLab eller npm, 23 AWS-nøkler og seks private nøkler. 63 organisasjoner var berørt, fra studentmiljøer og små selskaper til etablerte leverandører.
Forskerne brukte ikke legitimasjonen og testet ikke om hver nøkkel fortsatt virket. «Reell hemmelighet» betyr her at verdien enten fulgte et kjent nøkkelformat eller sto sammen med en offentlig vert, etter at plassholdere, standardpassord, lokale verter og nøkler som er offentlige med vilje var filtrert bort. Det er en viktig avgrensning. Men du trenger ikke vite om en fremmed allerede har brukt nøkkelen før du roterer den. At den har ligget offentlig er nok.
Størrelsen på tillatelsesfila ga også et tydelig faresignal. Én av ti filer over 8 KB inneholdt en hemmelighet, mot færre enn én av 500 filer under 500 byte. Jo flere konkrete kommandoer du lar fila samle opp, desto større blir sjansen for at ett passord har sneket seg inn.
Hvorfor er ikke gitignore nok?
En global exclude-regel beskytter bare arbeidsmiljøet der regelen finnes. Den blir ikke committet sammen med repositoriet og følger derfor ikke med når prosjektet klones et annet sted. Det samme problemet oppstår hvis en vanlig mappe først får lokale Claude Code-innstillinger og blir gjort om til et git-repositorium senere.
En repo-lokal .gitignore er bedre fordi den følger prosjektet, men heller ikke den hjelper dersom fila allerede er sporet. Git fortsetter å følge en kjent fil selv om du senere legger filnavnet i .gitignore. Apiiro fant at en commit med Claude som medforfatter hadde endret innstillingsfila i 539 av 1 105 repositorier med en hemmelighet som forskerne kunne spore på denne måten.
Dette sikkerhetsproblemet har dessuten vært synlig lenge. En offentlig feilrapport fra desember 2025 beskrev hvordan API-nøkler og tokens ble lagret i settings.local.json og endte i et offentlig repositorium. Rapporten ble lukket som en duplikat. Apiiro viser til beslektede varsler helt tilbake til august 2025.
Jeg har tidligere skrevet om Claude Code og git reset --hard. Fellesnevneren er viktig: Når en agent både kan kjøre kommandoer og arbeide med git, holder det ikke å anta at en fil er «lokal» eller at agenten skjønner hvilke konsekvenser en lagret kommando får senere. Sikkerhetsgrensene må være konkrete og kontrollerbare.
Sletting fjerner ikke en lekket nøkkel
Apiiro fant 734 hemmeligheter i eldre commits i 509 repositorier der verdiene ikke lenger lå i den nåværende fila. I tillegg bar 211 forks av 74 repositorier med seg de samme hemmelighetene. Når en verdi først er committet, kan den finnes i historikk, kloner, forks, hurtiglagre og sikkerhetskopier selv etter at du har slettet fila fra hovedgrenen.
Derfor er riktig rekkefølge helt avgjørende: Roter legitimasjonen først. En ny API-nøkkel, et nytt databasepassord eller et tilbakekalt token gjør den gamle verdien ubrukelig. Deretter kan du fjerne fila fra sporing, rydde historikken der det er nødvendig og varsle berørte samarbeidspartnere. Ikke bruk en time på å pynte git-historikken mens en produksjonsnøkkel fortsatt er gyldig.
Apiiro fant dessuten totalt 2 539 hemmeligheter i 1 994 offentlige repositorier da forskerne tok med eldre git-historikk, delte settings.json-filer, agenttranskripsjoner, minnefiler og andre notater. Problemet er altså større enn én Claude Code-fil. Agenter lager stadig flere filer som utviklere kan oppfatte som ufarlig arbeidsstøy, men som i praksis kan være en logg over kommandoer, infrastruktur og tilgang.
Hva bør du gjøre nå?
Start med å søke etter både .claude/settings.local.json og .claude/settings.json i egne og organisasjonens GitHub-repositorier. Kontroller også git-historikken. Et tomt søkeresultat i dagens hovedgren beviser ikke at fila aldri har vært publisert.
Finner du en nøkkel, et passord, et token eller en tilkoblingsstreng i en fil som har vært offentlig, skal verdien behandles som kompromittert. Roter eller tilbakekall den med en gang, og kontroller logger og forbruk for tegn til misbruk. Ikke begynn med å rydde git-historikken mens legitimasjonen fortsatt virker.
Når hemmeligheten er gjort ubrukelig, kan du fjerne den lokale fila fra git-indeksen med git rm --cached .claude/settings.local.json og legge den eksplisitt i repositoriets .gitignore. Rydd deretter historikken der det er nødvendig, og husk at forks, kloner og sikkerhetskopier kan ha beholdt kopier.
Slutt også å skrive hemmeligheter direkte i shell-kommandoer. Hent dem fra miljøvariabler eller en secret manager, slik at tillatelsesregelen kan lagre $DB_URL i stedet for selve databasepassordet. Godkjenn avgrensede mønstre som Bash(npm run:*) når det er forsvarlig, ikke lange bokstavelige kommandoer med legitimasjon bakt inn.
For team bør agentmapper som .claude/, .cursor/, .gemini/ og transkripsjonsmapper behandles som mulige hemmelighetslager. Skann dem før commit og i CI, men ikke stol blindt på standardverktøyene. Av de 1 122 lokale innstillingsfilene med hemmeligheter ble 215 ikke varslet av verken gitleaks eller TruffleHog. Passord inne i vanlige kommandoer ser ikke alltid ut som en klassisk API-nøkkel.
Min vurdering: Dette må være sikkert som standard
Utvikleren har selvsagt ansvar for hva som committes. Men det fritar ikke verktøyet som oppretter fila. «Ikke spør igjen» høres ut som en innstilling for arbeidsflyt, ikke et samtykke til å lagre et databasepassord i klartekst under prosjektroten. Når fila har et fast navn, ligger i prosjektet og kan endres av agentens egen arbeidsflyt, må sikkerheten tåle mer enn den lykkeligste git-konfigurasjonen på én maskin.
Anthropics Claude Code-leder Boris Cherny svarte at teamet undersøker tiltak, blant annet grunnleggende secret scanning og bedre håndtering i auto mode. Det er nødvendig, men en innebygd skanner alene er ikke nok når to etablerte skannere til sammen overså 215 av filene Apiiro hadde klassifisert med hemmeligheter.
Den praktiske lærdommen er enkel: Agentfiler er kode- og sikkerhetsmateriale, ikke usynlig rot. Kontroller hva de inneholder, bestem hvilke som får bli sporet, og hold hemmeligheter utenfor kommandoene agenten kan lagre. Har en nøkkel vært på GitHub, roter den. Nå.
Ofte stilte spørsmål
Hvilken Claude Code-fil kan inneholde passord og API-nøkler?
.claude/settings.local.json kan inneholde konkrete shell-kommandoer som er lagret som tillatelsesregler. Hvis en godkjent kommando hadde et passord, token eller en API-nøkkel skrevet direkte i kommandolinjen, kan hemmeligheten ha blitt lagret sammen med regelen.
Er det nok å legge settings.local.json i .gitignore?
Nei, ikke hvis fila allerede er sporet. Fjern den først fra git-indeksen, legg den i repositoriets .gitignore, og kontroller historikken. Dersom en hemmelighet har vært committet, må den roteres selv om fila senere slettes.
Hva gjør jeg hvis en API-nøkkel har ligget offentlig på GitHub?
Tilbakekall eller roter nøkkelen først. Undersøk deretter logger og forbruk for misbruk, fjern fila fra sporing, rydd git-historikken ved behov og varsle andre som kan være berørt. Sletting alene gjør ikke den gamle nøkkelen trygg.
Finner gitleaks og TruffleHog alle slike hemmeligheter?
Nei. Apiiro oppga at 215 av 1 122 lokale Claude Code-innstillingsfiler med klassifiserte hemmeligheter ikke ble flagget av noen av de to verktøyene. Vanlige passord inne i shell-kommandoer mangler ofte de faste mønstrene som skannere leter etter.
