Innhold Vis
Claude Code versjon 2.1.87 kjørte automatisk git reset --hard origin/main hvert 10. minutt mot brukerens prosjektrepo – uten å spørre om lov og uten varsel. Rapporten kom 29. mars 2026 og fikk 207 poeng på Hacker News og 135 kommentarer på rekordtid. Anthropic svarte ved å lukke issuet som «NOT PLANNED».
Det er den kombinasjonen – stille datatap og en avvisende respons – som har satt fyr på diskusjonen. Ikke selve buggen isolert sett, men hva den sier om sikkerhetsmodellen i AI-kodeverktøy.
Jeg bruker Claude Code daglig. Og jeg skal innrømme at denne saken fikk meg til å sjekke min egen git reflog umiddelbart.
Hva skjedde egentlig?
Brukeren som rapporterte issue #40710 på GitHub la frem solid bevis. Git reflog-en viste 95+ reset-oppføringer med nøyaktig 10-minutters intervall:
e8ea2c9 HEAD@{2026-03-29 22:19:09 +0200}: reset: moving to origin/main
e8ea2c9 HEAD@{2026-03-29 22:09:09 +0200}: reset: moving to origin/main
e8ea2c9 HEAD@{2026-03-29 21:59:09 +0200}: reset: moving to origin/mainDet var ikke tilfeldig, og det var ikke innbilning. Filsystemmonitorering bekreftet at Claude Code kjørte git fetch origin etterfulgt av git reset --hard origin/main via programmatiske git-operasjoner – altså ikke ved å spawne en ekstern git-binær, men gjennom libgit2 eller lignende. Dermed var det usynlig for vanlig prosessmonitorering.
Konsekvensen: alle uncommittede endringer i sporede filer ble slettet. Ukommittede filer i usporede filer overlevde, og git worktrees var immune. Men tracked files i main working tree – de forsvant stille og rolig, hvert tiende minutt, så lenge Claude Code kjørte.
Når skjer dette – og hvem er utsatt?
Her er det viktig å være presis, for det er mye forvirring i diskusjonene. Buggen er koblet til flagget --dangerously-skip-permissions. Med dette flagget aktivert kan Claude Code kjøre shell-kommandoer uten å spørre om lov. Flagget brukes typisk i automatiserte workflows – CI/CD, agentbaserte oppsett, eller når man kjører Claude Code i en loop.
Jarred Sumner fra Anthropic hevdet i sitt svar at «there is no code in Claude Code itself that runs git reset –hard origin/main», og la frem hypotesen om at brukeren kan ha kjørt /loop 10m som deretter instruererte Claude til å utføre reseten. Med andre ord: det er ikke en timer i Claude Code sin kode som kjører reseten – det er Claude Code som AI-agent som kan bli instruert til å gjøre det, og som med --dangerously-skip-permissions ikke vil stoppe for å bekrefte.
Uansett årsak – og debatten om årsaken er ikke avsluttet – er resultatet det samme: stille datatap uten varsel.
Lukket som «NOT PLANNED» – er det riktig?
Det som opprørte Hacker News-fellesskapet like mye som selve buggen, var Anthropics håndtering av den. Issuet ble lukket som «NOT PLANNED» – altså at de ikke planlegger å fikse det.
Argumentet er at --dangerously-skip-permissions er et eksplisitt opt-in til farlig oppførsel. Brukeren har sagt «gjør alt uten å spørre». Og ja, det er et poeng. Men det er en subtil forskjell mellom «kjør kommandoer uten å bekrefte hver enkelt» og «slett automatisk alt ucommittet arbeid hvert 10. minutt, stille».
En kommentator på Hacker News oppsummerte det godt: «Å si til en LLM at den ikke skal gjøre noe, vil aldri deterministisk forhindre det. Løsningen er sandkasse-miljøer og hooks som blokkerer farlige kommandoer på systemnivå.» Det er et argument for mer beskyttelse utenfor modellen – ikke at brukeren selv må sørge for å committe oftere.
Et mønster av destruktive git-kommandoer
Issue #40710 er ikke en isolert hendelse. GitHub-trackeren til Claude Code er full av lignende rapporter:
- Issue #7232: «CRITICAL: Claude executed git reset –hard without authorization causing data destruction»
- Issue #17190: Claude Code valgte destruktiv
git reset --hardfremfor trygggit checkout - Issue #11237: Claude Code kjørte git-kommando uten prompt som medførte katastrofalt datatap
- Issue #29179: Claude Code kjørte unødvendig
git clean -fdunder branch-oppretting
Det er et mønster. AI-kodeverktøy og destruktive git-operasjoner er en kombinasjon som tydeligvis ikke er løst.
Hva kan du gjøre for å beskytte deg?
Jeg er fremdeles begeistret for Claude Code – det er et kraftig verktøy som jeg bruker til daglig. Men denne saken er en god påminnelse om noen grunnleggende regler:
- Bruk git worktrees – de er immune mot denne typen reset. Arbeider du i en worktree, er du trygg.
- Commit hyppig – committede endringer overlever en reset. Det er god praksis uansett, men med AI-kodeverktøy er det ekstra viktig.
- Vær forsiktig med
--dangerously-skip-permissions– flagget heter «dangerously» av en grunn. Bruk det kun i isolerte miljøer der tap av data ikke er kritisk. - Sett opp pre-commit hooks – ikke for å blokkere Claude, men for å ha dokumentasjon på hva som skjer i repoet ditt.
Det større bildet – tillitsmodellen i AI-koding
Saken reiser et spørsmål jeg tenker mye på: hva er den riktige tillitsmodellen for AI-kodeverktøy?
Claude Code er ikke et deterministisk verktøy. Det er et LLM som tar avgjørelser basert på kontekst og instruksjoner. Det betyr at du aldri kan være 100% sikker på hva det vil gjøre – selv om du har gitt klare instruksjoner. Flagget --dangerously-skip-permissions fjerner det siste laget med menneskelig kontroll.
Dette er ikke et argument mot Claude Code. Det er et argument for å forstå verktøyet man bruker, og for at Anthropic bør tenke mer grundig på hvilke operasjoner som alltid bør kreve eksplisitt bekreftelse – uansett flagg. git reset --hard mot production-kode er en god kandidat for den listen.
Jeg har tidligere skrevet om Cog-arkitekturen som gir Claude Code vedvarende hukommelse – et prosjekt som bygger ut Claude Code sine evner. Og i OpenClaw-testen min gikk jeg gjennom sikkerhetsproblemer som fulgte med OpenClaw (CVE-2026-25253, ClawHavoc). Sikkerhetsmodellen i AI-kodeverktøy er et tema som ikke er ferdig diskutert.
Hva tenker du? Bruker du --dangerously-skip-permissions, og tar du noen forholdsregler? Gi meg gjerne en kommentar.
