Blogg

Gjenoppretting av Claude Code: sikker modus, /cd og fallback

Markdown

Feilsøking av Claude Code med sikker modus, /cd-kommandoen, reservemodeller og gjenoppretting av innstillinger. Rekkefølgen på kontrollene og de opprinnelige begrensningene.

Les hele artikkelen

Praktisk materiale om arbeid med agenter: Ailoot-dokumentasjon.

Hva endres i Claude Code i juni 2026?

Hovedpunkter

Den 8. juni 2026 la Anthropic til flagget --safe-mode og kommandoen /cd i Claude Code v2.1.169. To dager tidligere introduserte v2.1.166 reservemodeller, opptil 3 i en kjede. Disse tre funksjonene løser det vanligste problemet for vibe-kodere: «alt har sluttet å virke, jeg vet ikke hvem som har skylda, og jeg vil ikke bruke en time på å installere alt på nytt».

Tidligere fantes det bare én utvei når Claude Code begynte å oppføre seg merkelig—en evig snurrende indikator, krasj ved oppstart, agenten som ignorerte reglene i CLAUDE.md, eller en hook som ikke ble kjørt uten å si fra: kommentere ut deler av .claude/settings.json manuelt, deaktivere MCP-servere én etter én eller, i verste fall, slette ~/.claude og installere på nytt. I et beskrevet tilfelle ble ~/.claude slettet, og MCP-serveroppsettet som hadde tatt halvannen time å sette sammen, gikk tapt. Senere viste det seg at én linje i CLAUDE.md var årsaken, og at den kunne vært funnet på 10 sekunder—men dette ble først klart etter en full gjenoppretting.

I juni 2026 lanserte Anthropic tre mekanismer som endrer dette scenarioet. Kort fortalt: hva kom, og når:

VersjonDatoNyheter
2.1.1666. juni 2026Innstillingen fallbackModel + flagget --fallback-model for interaktive økter
2.1.1698. juni 2026Flagget --safe-mode og miljøvariabelen CLAUDE_CODE_SAFE_MODE, kommandoen /cd
2.1.17612. juni 2026Rettelse: /cd og bytte av worktree viste ikke lenger den gamle git-grenen

Nedenfor forklares hver mekanisme trinn for trinn, sammen med rekkefølgen de bør brukes i når en Claude Code-økt kommer ut av kurs.

Hva får oftest Claude Code til å svikte?

Hovedpunkter

Basert på den beskrevne erfaringen svikter Claude Code vanligvis for vibe-kodere på grunn av fire ting: en oppblåst CLAUDE.md med motstridende regler, en hook med feil exit-kode, en MCP-server som svikter i stillhet, og overlappende innstillinger på tre nivåer i settings.json. Det finnes én årsak, feilsøkingen tar minutter, og panikken får folk til å gripe til rm -rf med én gang.

I eksempelet som beskrives, ble CLAUDE.md først satt sammen på 80 linjer—og fungerte i en måned. I den andre måneden ble det merkbart at Claude én gang i uken brøt alle reglene som var satt: tuklet med .env, kjørte git push --force, rotet rundt i node_modules. Ikke med vilje—den bare glemte. En gang ble .gitignore slettet, og årsaken var ikke umiddelbart klar. Dette scenarioet omtales mer utførlig i veiledningen om CLAUDE.md.

Når CLAUDE.md vokser til 400+ linjer, begynner den å skape problemer i det stille: Den bruker en betydelig del av kontekstvinduet når økten starter, og viktige instruksjoner drukner blant mindre viktige. Claude leser fortsatt filen formelt sett, så utenfra ser det ut som «reglene står der, men de virker ikke»—et typisk tegn på en oppblåst avtale.

Hooks er den nest vanligste kilden. Claude Code hooks har en nyanse Anthropic ikke fremhever.

Det vil si at sys.exit(1) i en Python-hook (eller en hvilken som helst Unix-konvensjonell «feilet med en feil») ikke stopper Claude. Bare kode 2 blokkerer. I det beskrevne tilfellet ble hooken regnet som et «absolutt forbud», men i praksis logget den en klage og lot handlingen fortsette.

MCP-servere er det tredje laget, og de svikter også på sin egen måte.

Symptomet ser ofte likt ut: MCP-kommandoer er tilgjengelige, men returnerer failed uten en traceback. Du finner mer om konfigurering av MCP og hvordan du legger til servere med claude mcp add i den separate veiledningen.

Den fjerde årsaken er hierarkiet med tre nivåer for settings.json. Du har ~/.claude/settings.json (brukernivå), .claude/settings.json i prosjektets rotmappe (prosjekt), .claude/settings.local.json (lokalt) og eventuelt administrerte innstillinger fra en bedriftsadministrator. De kombineres i henhold til prioritetsregler. Når noen legger til en MCP-server på prosjektnivå mens du har en lignende oppføring på brukernivå med en annen startkonfigurasjon, oppstår det en stille konflikt som ser ut som «Claude Code er ødelagt».

Hvordan fungerer --safe-mode, og hva deaktiverer det?

Hovedpunkter

claude --safe-mode starter Claude Code med alle tilpasninger fullstendig deaktivert: CLAUDE.md, programtillegg, ferdigheter, hooks, MCP-servere, brukerkommandoer, agenter, utdataformater, arbeidsflyter og tastebindinger. Autorisering, modellvalg, innebygde verktøy og tillatelser beholdes. Dette er et diagnoseverktøy: Hvis problemet forsvinner i sikker modus, ligger årsaken i et av lagene du har lagt til.

Anthropics opprinnelige formulering i endringsloggen for v2.1.169 lyder:

La til flagget --safe-mode (og CLAUDE_CODE_SAFE_MODE) for å starte Claude Code med tilpasninger deaktivert (CLAUDE.md, programtillegg, ferdigheter, hooks, MCP-servere) for diagnostikk.

— Anthropic Claude Code Changelog, https://code.claude.com/docs/en/changelog

Anthropic presiserer i dokumentasjonen for modellkonfigurasjon:

For å sjekke om tilpasninger er årsaken, starter du en økt med claude --safe-mode, som deaktiverer CLAUDE.md, ferdigheter, MCP-servere og hooks. Git-status og katalognavn regnes ikke som tilpasninger og er fortsatt tilgjengelige.

— Anthropic Docs - Model configuration, https://code.claude.com/docs/en/model-config

Dette er et diagnoseverktøy, ikke et «rent miljø». Sikker modus hjelper deg med å besvare ett spørsmål: Ligger problemet i Claude Codes standardoppførsel, eller i tilpasningene som er lagt til? Dette er en del av kontekstteknikk—å styre hva Claude ser og ikke ser på et gitt tidspunkt. Hvis alt fungerer i sikker modus, er det tydelig at du må kontrollere lagene ved hjelp av binærsøk. Hvis det ikke fungerer, skyldes problemet selve installasjonen, autorisering, nettverket eller infrastrukturen; da er det fornuftig å se på claude doctor og loggene.

Dette deaktiverer sikker modus (Anthropics offisielle liste—5 hovedlag):

  • CLAUDE.md på alle nivåer (bruker / prosjekt)
  • Programtillegg
  • Ferdigheter
  • Hooks
  • MCP-servere

Dette fortsetter å fungere:

  • Autorisering (OAuth-økten eller API-nøkkelen din)
  • Modellvalg (--model sonnet, --model opus)
  • Innebygde verktøy (Read, Write, Bash, Grep og så videre)
  • Tillatelser
  • Git-status
  • Katalognavn

En viktig detalj: Sikker modus deaktiverer ikke administrerte/policybaserte innstillinger fra en bedriftsadministrator. Hvis du jobber i et team der Bedrock GovCloud eller en MDM-konfigurasjon angir availableModels, gjelder disse begrensningene fortsatt—sikker modus deaktiverer bare dine egne tilpasninger, ikke bedriftens retningslinjer.

Hvordan isolerer du et lag og finner årsaken på 60 sekunder?

Hovedpunkter

Trinn 1: Kjør claude --safe-mode i samme mappe der problemene oppstod. Hvis det fungerer, ligger problemet i tilpasningene dine, og da aktiverer du dem én etter én: CLAUDE.md -> hooks -> MCP -> ferdigheter. Hvis det ikke fungerer selv i sikker modus, ligger problemet i auth, versjonen, nettverket eller operativsystemet. Kjør i så fall claude doctor for automatisk diagnostikk, uten å røre rm -rf.

Et diagnostisk scenario for når Claude Code har «sluttet å lytte». Minimumsversjonen for alle kommandoene nedenfor er Claude Code v2.1.169. Hvis din versjon er eldre, må du oppdatere først (npm update -g @anthropic-ai/claude-code eller via Anthropics opprinnelige installasjonsprogram).

  1. Åpne den samme mappen der problemene oppstod.
  2. Kjør claude --safe-mode.
  3. Hvis den starter uten problemer, sjekk den opprinnelige forespørselen. Fungerte den? Da ligger årsaken i ett av lagene. Gå til trinn 4.
  4. Hvis det fortsatt ikke fungerer i sikker modus, må du ikke røre konfigurasjonene. Kjør claude doctor først; kontroller auth, versjon og konflikter mellom installasjoner.

Når sikker modus starter uten problemer, aktiverer du lagene ett om gangen, med den mest sannsynlige årsaken først. Rekkefølgen er basert på den beskrevne erfaringen:

  1. CLAUDE.md. Kjør claude uten sikker modus, men gi filen midlertidig et nytt navn: mv CLAUDE.md CLAUDE.md.bak. Hvis det fungerer, er filen årsaken. Deretter kan du bruke binærsøk: behold halvparten av linjene og sjekk.
  2. Hooks. Åpne .claude/settings.json og sett midlertidig [] i delen hooks. Start claude på nytt. Fungerer det? Da er en av hookene årsaken. Aktiver dem én etter én.
  3. MCP-servere. Sett delen mcpServers til et tomt objekt midlertidig i ~/.claude.json eller .claude/settings.json, start på nytt og sjekk.
  4. Ferdigheter. Flytt .claude/skills/ til en midlertidig mappe. Start og sjekk.

Hva «midlertidig endring av navn» betyr: Filene slettes ikke under diagnostikken. mv eller git stash lar deg gjenopprette alt med én kommando hvis det viser seg at laget ikke er årsaken.

Hvordan bytter du arbeidsmappe med /cd uten å miste konteksten?

Hovedpunkter

Kommandoen /cd <path> i Claude Code 2.1.169+ bytter arbeidsmappe i den aktive økten uten å miste prompt-cachen. Nyttig når konfigurasjonen i det gjeldende prosjektet er ødelagt: Du kan gå til en ren mappe, sjekke at Claude fungerer og gå tilbake. Tidligere måtte du lukke økten og starte på nytt.

Fra endringsloggen for v2.1.169 den 8. juni:

La til kommandoen /cd for å bytte økten til en ny arbeidsmappe uten å tilbakestille prompt-cachen midt i økten.

— Anthropic Claude Code Changelog, https://code.claude.com/docs/en/changelog

Hvorfor er dette nyttig når du skal løse problemer? Tenk deg at du er i prosjektmappen ~/work/myapp, og Claude Code oppfører seg merkelig. Tidligere var den eneste måten å sjekke «fungerer det i det hele tatt?» på å lukke økten, gå til en annen mappe og starte på nytt. Du mistet konteksten, historikken og den oppvarmede prompt-cachen. Nå kan du gjøre dette:

# I samme økt:
/cd ~/sandbox/test

Claude bytter til den nye mappen og leser eventuell CLAUDE.md der som en melding, ikke som en erstatning for systemprompten—det vil si at cachen bevares. Hvis alt fungerer i ~/sandbox/test, er det tydelig at problemet lå i konfigurasjonen for ~/work/myapp.

Den 12. juni rettet v2.1.176 en ubehagelig regresjon—/cd viste den gamle git-grenen helt til en full omstart. Hvis din versjon er eldre, kan du enten oppdatere eller ganske enkelt ignorere git status de første meldingene etter byttet—det oppdateres etter hvert.

Hvordan konfigurerer du reservemodeller for en 529-feil?

Hovedpunkter

I v2.1.166 la Anthropic til fallbackModel—en kjede på opptil 3 modeller som prøves etter tur når den primære modellen er overbelastet eller utilgjengelig. Kjedet aktiveres bare av overbelastning og serverfeil som ikke kan prøves på nytt. Autorisasjons-, fakturerings-, rate-limit- og transportfeil aktiverer ikke fallback-kjeden—de følger den vanlige logikken for nye forsøk.

I scenarioet som beskrives, kjører en lang oppgave på Opus i et prosjekt én gang i uken; etter 10 minutter returnerer API-et 529 Overloaded, og økten krasjer. Tidligere måtte du enten vente eller bytte manuelt til Sonnet med --model sonnet og miste all oppvarmet kontekst. I en stor business/-mappe med et second-brain-oppsett tar dette omtrent tjue minutters arbeid. Nå finnes det en egen mekanisme.

Det nøyaktige sitatet fra den offisielle dokumentasjonen:

Når den primære modellen er overbelastet eller utilgjengelig, eller returnerer en annen serverfeil som ikke kan prøves på nytt, kan Claude Code bytte til en reservemodell i stedet for å la forespørselen mislykkes. Autorisasjons-, fakturerings-, rate-limit-, forespørselsstørrelses- og transportfeil utløser aldri et bytte—de følger den vanlige banen for nye forsøk og feilhåndtering.

— Anthropic Docs - Model configuration, https://code.claude.com/docs/en/model-config

Og separat: slik fungerer kjeden:

Konfigurer én eller flere reservemodeller, så prøver Claude Code dem i rekkefølge og viser et varsel når den bytter. Byttet gjelder bare den gjeldende turen—den neste meldingen prøver den primære modellen på nytt. Kjedene er begrenset til tre modeller etter deduplisering; flere oppføringer ignoreres.

— Anthropic Docs - Model configuration, https://code.claude.com/docs/en/model-config

Det finnes to måter å konfigurere dette på. Via CLI:

claude --fallback-model sonnet,haiku

Via ~/.claude/settings.json:

{
  "fallbackModel": ["claude-sonnet-4-6", "claude-haiku-4-5"]
}

En separat nyanse gjelder rate limits. Anthropic sender bevisst ikke en 429-feil gjennom kjeden, slik at du ikke kan omgå forespørselsgrensen ved å bytte til neste modell. Fallback fungerer bare når den primære modellen er overbelastet eller utilgjengelig, eller returnerer en serverfeil som ikke kan prøves på nytt (for eksempel 529 Overloaded). Rate limits følger den vanlige logikken for nye forsøk og backoff.

Enda en nyanse—den 12. juni rettet v2.1.174 en regresjon: compaction hadde ikke tatt hensyn til --fallback-model. Hvis du har en lang økt og den kompakteres mens det er overbelastning, ble ikke reservemodellen kalt før denne rettelsen. Hvis du jobber med lange økter (/compact, /loop over natten), bør du oppdatere til minst v2.1.174.

Hva bør du rette når CLAUDE.md, en hook, MCP eller en ferdighet er årsaken?

Hovedpunkter

Når sikker modus har identifisert laget som er årsaken, avhenger løsningen av hvilket lag det er. For CLAUDE.md bruker du binærsøk eller går tilbake til en ferdig mal på under 200 linjer. For en hook kontrollerer du exit-koden (2 blokkerer, 1 gjør det ikke) og logikken. For MCP fjerner du én server og sjekker. For en ferdighet sjekker du SKILL.md for motstridende regler med CLAUDE.md.

Konkrete strategier for hvert lag.

Hvis CLAUDE.md er årsaken

Åpne filen og sjekk størrelsen. Basert på den beskrevne erfaringen bør den aktive CLAUDE.md ikke være på mer enn 200 linjer; flytt resten til rutere og støttedokumenter ved siden av prosjektet (hele second-brain-strukturen finnes i veiledningen om second brain). Hvis du har 400+ linjer, er den nesten helt sikkert årsaken. Trinn:

  1. Ta en sikkerhetskopi: cp CLAUDE.md CLAUDE.md.full.
  2. Gå tilbake til en kort, fungerende mal. En ferdig mal finnes i veiledningen «Slik konfigurerer du CLAUDE.md».
  3. Start Claude Code på nytt. Sjekk.
  4. Hvis det fungerer, gjenopprett reglene i små blokker på 10–20 linjer, og sjekk etter hver blokk.
  5. Finn blokken som forstyrrer oppførselen. Skriv den om som en hook med riktig exit-kode (exit-koder for hooks omtales i neste underavsnitt av denne H2-en).

Hvis en hook er årsaken

Hovedspørsmålet er om exit-koden er riktig. Claude Code-hooks bruker:

  • Exit 0 — alt i orden; handlingen fortsetter.
  • Exit 1 — en feil, men ikke-blokkerende. Claude fortsetter som om ingenting har skjedd.
  • Exit 2 — en blokkerende feil. Bare denne stopper faktisk handlingen.

Hvis du skrev sys.exit(1) eller exit 1 i en shell-hook fordi du trodde du blokkerte handlingen, fungerer denne koden som en advarselslogg i Claude Code, uten å stoppe handlingen. Endre den til 2. Du finner mer informasjon om hooks og hvordan du konfigurerer dem uten denne fallgruven i den separate veiledningen.

Det nest vanligste tilfellet er at en hook returnerer ugyldig JSON på stdout. Claude Code tolker hook-responsen som JSON, og hvis den inneholder støy (en logg, fremdriftsmarkør, emoji), regnes hooken som mislykket, og handlingen fortsetter. Regel: stdout inneholder bare JSON; alt annet sendes til stderr.

Det tredje tilfellet er at en hook leser noe fra ~/.claude/ som sikker modus har skjult. Dette er et normalt scenario; løs det ikke ved å endre hooken, men sjekk os.environ.get('CLAUDE_CODE_SAFE_MODE') i starten og avslutt med 0.

Hvis en MCP-server er årsaken

Symptomer: MCP-kommandoer er tilgjengelige, men returnerer failed uten en tydelig traceback. Trinn:

  1. Kjør claude mcp list—hvilke servere er definert?
  2. Deaktiver servere én etter én i ~/.claude.json: endre nøkkelen claude-server-A til _claude-server-A (dette deaktiverer den uten å slette den).
  3. Start claude på nytt. Sjekk hvilke kall som fungerer.
  4. Når du har funnet serveren som er årsaken, sjekk loggen: claude mcp logs <name>.
  5. Hvis det er en tredjepartsserver (@modelcontextprotocol/server-postgres og lignende), sjekk om den har fått en nyere utgave. MCP-økosystemet er fortsatt i uro; servere går jevnlig i stykker etter oppdateringer av Claude Code.

Hvis du opplever «krasj ved oppstart, og bare med to MCP-er», bør du sammenligne med oppførselen i sikker modus uten MCP.

Hvis en ferdighet er årsaken

En ferdighet består av SKILL.md pluss kode i .claude/skills/<name>/. Symptomer: Claude ignorerer ferdigheten, bruker den på feil tidspunkt eller bruker den, men produserer bare søppel. Trinn:

  1. Åpne SKILL.md. Sjekk beskrivelsen—den bør være på 1–2 setninger og beskrive konkret når ferdigheten skal brukes. Hvis det står «en universell hjelper for alt», forstår ikke Claude når den skal aktiveres.
  2. Sjekk om den strider mot CLAUDE.md. Hvis CLAUDE.md sier «skriv alltid tester», men beskrivelsen av ferdigheten sier «bruk til rask prototyping uten tester», er det en konflikt.
  3. Hvis ferdigheten bruker eksterne kommandoer (npm, python, git), må du sjekke at de er tilgjengelige i den systemomfattende PATH-en. En ferdighet har sitt eget minimale miljø.

Hvis sikker modus ikke hjelper: diagnostiser og bevar tilstand før reparasjon

Hovedpunkter

Hvis sikker modus også feiler, kan årsaken fortsatt være installasjon, autorisasjon, nettverk eller infrastruktur. Kjør claude doctor og undersøk belegget. En uavklart rapport rettferdiggjør ikke sletting av innstillinger eller økter. Bevar og verifiser full tilstand først, og reparer bare den diagnostiserte installasjonen.

Fjerning av brukertilstand er ingen diagnostisk snarvei. Bruk kontrollene nedenfor til å finne feilen. Er de uavklarte, bevar belegget og undersøk videre. Installasjonsreparasjon starter med verifisert sikkerhetskopi og beholder eksisterende konto og nøkkellageridentitet. Rekkefølge:

  1. claude doctor — automatisk diagnostikk. Anthropic skriver i dokumentasjonen:

Hvis claude --version fungerer, men noe annet går galt, kjører du claude doctor for å generere en automatisk diagnoserapport.

— Anthropic Docs - Troubleshoot installation, https://code.claude.com/docs/en/troubleshoot-install
  1. Se etter konflikter mellom installasjoner. Mange har både en global npm-versjon og den opprinnelige installasjonen samtidig:

Flere installasjoner av Claude Code kan føre til versjonsforskjeller eller uventet oppførsel.

— Anthropic Docs - Troubleshoot installation, https://code.claude.com/docs/en/troubleshoot-install
  1. Sjekk om ANTHROPIC_API_KEY overstyrer OAuth-økten din. Dette er en vanlig årsak til «ingenting fungerer, nøkkelen har utløpt»:

Når `ANTHROPIC_API_KEY` er angitt og bekreftet av deg, bruker Claude Code denne nøkkelen i stedet for OAuth-legitimasjonen fra abonnementet ditt.

— Anthropic Docs - Troubleshoot installation, https://code.claude.com/docs/en/troubleshoot-install

Løsning: Kjør unset ANTHROPIC_API_KEY i den gjeldende shell-økten, eller fjern den fra ~/.zshrc / ~/.bashrc.

  1. Reparer bare installasjonen diagnostikken identifiserer; bevar all brukertilstand først. Feil i sikker modus eller en uavklart doctor-rapport fastslår ikke at brukerdata må fjernes. Stopp alle Claude-økter og andre skrivere før konsistent sikkerhetskopi. Behold samme Unix-konto, HOME, operativsystemets nøkkellager og Anthropic-konto. Ikke roter nøkler eller opprett erstatningsidentitet.

Sikkerhetskopieksemplet gjelder Linux med GNU tar. På macOS eller Windows bruker du et verktøy som bevarer plattformens ACL-er, utvidede attributter, lenker og metadata, og verifiserer gjenoppretting før videre arbeid. Ikke anta at GNU-flagg fungerer der. Arkivet inneholder tilganger og økttranskripsjoner; hold det privat og utenfor repositorier.

# Run as the same user who owns the Claude state, after stopping writers.
set -eu
umask 077
backup_dir=$(mktemp -d "$HOME/.claude-recovery-XXXXXXXX")
set --
if [ -e "$HOME/.claude" ] || [ -L "$HOME/.claude" ]; then
  set -- "$@" .claude
fi
if [ -e "$HOME/.claude.json" ] || [ -L "$HOME/.claude.json" ]; then
  set -- "$@" .claude.json
fi
[ "$#" -gt 0 ] || exit 1
tar --acls --xattrs --numeric-owner -cpf "$backup_dir/claude-state.tar" -C "$HOME" "$@"
tar --acls --xattrs --compare -f "$backup_dir/claude-state.tar" -C "$HOME"
sha256sum "$backup_dir/claude-state.tar" > "$backup_dir/claude-state.sha256"
(cd "$backup_dir" && sha256sum -c claude-state.sha256)
mkdir "$backup_dir/restore-check"
tar --acls --xattrs -xpf "$backup_dir/claude-state.tar" -C "$backup_dir/restore-check"
tar --acls --xattrs --compare -f "$backup_dir/claude-state.tar" -C "$backup_dir/restore-check"
printf 'Verified recovery directory: %s\n' "$backup_dir"

Alle kommandoer må lykkes. Arkivet dekker hele eksisterende .claude-tre, inkludert ignorerte og usporede økter og plugintilstand, samt .claude.json, ikke bare Git-sporede innstillinger. Hvis en bane er en symlenke eller data ligger et separat konfigurert sted, stopp og inkluder det oppløste målet i samme verifiserte sikkerhetskopi. Arkivering av en lenke alene kopierer ikke målet. Arkivet inneholder ikke macOS Keychain eller andre eksterne nøkkellagre. Behold disse identitetene på plass.

Hvis diagnostikken spesifikt identifiserer den eldre lokale installasjonen som konflikten, flytt bare den installasjonen til privat gjenopprettingsmappe fremfor å slette konfigurasjon og økter:

# Use the verified backup_dir from the previous block.
if [ -d "$HOME/.claude/local" ]; then
  mv "$HOME/.claude/local" "$backup_dir/legacy-local"
fi

Fjern en npm-installasjon bare hvis diagnostikken peker på den som konflikt og du vil beholde den native. Bruk deretter dokumentert native installasjonsprogram, uten å slette .claude eller .claude.json:

curl -fsSL https://claude.ai/install.sh | bash
claude --version
claude doctor

På Windows er den native installasjonskommandoen fortsatt:

irm https://claude.ai/install.ps1 | iex

Gjenopprett separat. Stopp skrivere igjen. Kontroller arkivets sjekksum og pakk ut i en tom gjenopprettingsmappe som ovenfor. Sammenlign vellykket før filene brukes. Hvis den flyttede eldre installasjonen må tilbake, bekreft først at $HOME/.claude/local ikke finnes, og flytt så $backup_dir/legacy-local tilbake til nøyaktig den banen. Gjenopprett en diagnostisert innstillingsfil fra verifisert uttrekk først etter at en nåværende erstatning er bevart. Ikke legg hele treet blindt over det eksisterende. Økter, MCP-innstillinger og opprinnelig identitet beholdes. Et Git-øyeblikksbilde alene dekker ikke ignorerte/usporede transkripsjoner, tilganger eller filsystemmetadata.

Hva bør du IKKE gjøre når Claude Code er ødelagt?

Hovedpunkter

Seks anti-mønstre fra de beskrevne supportsakene: endre nøkler før feilsøking, utføre en full gjenoppretting som første trinn, få panikk over en UI-feil i en hook, heve exit-koden til en hook før logikken er rettet, redigere CLAUDE.md uten sikkerhetsnett i form av sikker modus og tro at «Claude reparerer sin egen MCP». Hvert av disse koster timer, og ingen av dem er nødvendig.

Ikke endre nøkler før feilsøkingen

«Autoriseringen fungerer ikke» skyldes i 90% av tilfellene enten at ANTHROPIC_API_KEY overstyrer abonnementet, en UI-feil i en hook eller en MCP som har sviktet. Å rotere nøkler løser ingen av disse problemene, men fører til en time med driftsavbrudd: Du må tilbakekalle den gamle nøkkelen, opprette en ny, signere CI på nytt med den og oppdatere variablene i produksjon. Kjør claude --safe-mode først. Fungerer det? Da ligger problemet i tilpasningene; du trenger ikke røre nøklene.

Ikke utfør full gjenoppretting før du har prøvd sikker modus

Sikker modus gir deg et isolert miljø på 1 sekund. Sletting av .claude kan ødelegge økter, MCP-konfigurasjon og annen usporet tilstand. Diagnostiser først, verifiser privat sikkerhetskopi og bruk reversibel flytting bare for installasjons- eller konfigurasjonslaget som faktisk er implisert.

Ikke få panikk over en UI-feil i en hook

Før du retter noe, bør du sjekke om hooken faktisk ble kjørt (via en logg til stderr eller en eksplisitt utskrift), i stedet for å stole på den visuelle indikatoren.

Ikke øk exit-koden til en hook før du har rettet logikken

Når den blokkerende hooken din ikke blokkerer, er det fristende å sette exit 2 og kalle det ferdig. Dette er en fungerende oppdatering, men den skjuler et annet problem: Hvis blokkeringen ikke fungerte på en måned, har alt hooken skulle ha forbudt, sluppet gjennom. Gå først gjennom git-loggen og finn ut nøyaktig hva som slapp gjennom. Legg deretter til blokkeringen. Ellers gjør ikke en blokkering som er lukket nå, om på det som allerede har skjedd.

Ikke rediger produksjonsfilen CLAUDE.md uten sikker modus som sikkerhetsnett

I det beskrevne tilfellet redigerer du CLAUDE.md, Claude begynner å oppføre seg merkelig, og du kjører git diff og ser at noen også la til en MCP-server og en hook i repoet samme kveld. Du gir endringen din skylden, ruller den tilbake, og Claude oppfører seg fortsatt merkelig. Regel: Kjør claude --safe-mode før git revert. Hvis problemet vedvarer i sikker modus, hadde endringen din ingenting med det å gjøre; det er ingen grunn til å rulle den tilbake.

Ikke tro at «Claude reparerer sin egen MCP»

Et typisk scenario: Du ber Claude om å «legge til et bestemt verktøy på MCP-serveren», Claude skriver om en fungerende konfigurasjon, alt går i stykker, og deretter bruker Claude flere turer på å feilsøke skaden den selv forårsaket—og bruker opp øktkvoten underveis. Når MCP er ødelagt, hent konfigurasjonen manuelt; ikke overlat det til agenten. Deler av verktøyarsenalet kjører også på MCP, og en ødelagt MCP betyr en ødelagt diagnostiker.

Hva bør du gjøre etter at du har reparert det?

Hovedpunkter

Når Claude Code er gjenopprettet, må du legge til forebyggende tiltak slik at det ikke går i stykker igjen. Som et minimum: disableBypassPermissionsMode: "disable" i brukerinnstillingene, hooks som blokkerer .env og git push --force, og en sandkasse for lange autonome kjøringer. Forebyggingsveiledningen er motstykket til denne.

Ikke gå rett tilbake til arbeidet etter å ha analysert hendelsen. Legg først til forebyggende tiltak for å hindre at den gjentar seg. Du kan bruke timer på et second brain (business/-mappen med prosjektstrukturen) og CLAUDE.md, og det er vanskelig å gjenopprette dem manuelt—det er en god grunn. Minimumssett:

  1. ~/.claude/settings.json med permissions.disableBypassPermissionsMode: "disable"—et arkitektonisk forbud mot omgåelsesmodus, slik at --dangerously-skip-permissions ikke fungerer hvis det startes ved en feil.
  2. Hooks for Read(./env*), Bash(git push --force), Write(./node_modules/**)—ting som må fanges opp som en absolutt regel, ikke et ønske.
  3. Sandkassekonfigurasjon for lange autonome kjøringer (/loop, /schedule).
  4. /compact med egne regler for hva som skal fjernes fra konteksten, slik at Claude ikke bruker opp seg selv.

Hele beskyttelsesordningen med fire lag finnes i veiledningen «Slik konfigurerer du Claude Code så det ikke ødelegger prosjektet ditt over natten». Den ene veiledningen dekker forebygging før du starter /loop; den andre dekker gjenoppretting etter at /loop allerede har ødelagt noe. Et logisk par.

Kilder

Praktisk materiale: Ailoot-dokumentasjon.

Mer materiale og verktøy: Ailoot.

Flere detaljer

Spørsmål om denne veiledningen: Gjenoppretting av Claude Code: sikker modus, /cd og fallback | Ailoot

Betyr feil i sikker modus at jeg bør slette ~/.claude?

Nei. Installasjon, autorisasjon, nettverk og infrastruktur må fortsatt undersøkes. En uavklart doctor-rapport er ikke belegg for fjerning av innstillinger eller økter. Reparer bare det diagnostiserte laget.

Hva må bevares før installasjonsreparasjon?

Stopp skrivere og sikkerhetskopier full Claude-tilstand, inkludert økter, plugin-/MCP-konfigurasjon, ignorerte filer og metadata. Verifiser sjekksum og uttrekk før videre arbeid. Behold konto og nøkkellager, og gjenopprett bare diagnostisert lag uten blind overskriving.

Alle artikler