Del 5: Behörighetslägen — matcha AI-autonomi mot din risknivå
De flesta utvecklare konfigurerar Claude Code en gång och återkommer aldrig till behörighetsinställningarna. Standardinställningen fungerar, sessionerna körs, kod skrivs. Frågan om vilket läge man använder, och vad det valet faktiskt innebär, tenderar att dyka upp först efter att något oväntat har hänt.
Det är för sent att tänka på det.
Behörighetslägen är inte en bekvämlighetsinställning. De är mekanismen som bestämmer hur mycket AI:n agerar innan du granskar. Det innebär att de, på en strukturell nivå, bestämmer vem som är ansvarig för vad som kommer ut ur varje session. Att välja ett läge medvetet — och välja rätt för varje sammanhang — är ett av de mest praktiska besluten i verktyget.
Vad lägen faktiskt styr
Claude Code opererar med en uppsättning verktyg: filläsningar, filskrivningar, bash-kommandokörning, webbhämtningar och andra. Behörighetssystemet styr vilka av dessa som kräver din uttryckliga bekräftelse innan de körs.
Det finns fyra lägen att förstå:
Standardläge är grundnivån. Claude läser filer fritt — det är säkert. Men innan det skriver till en fil, kör ett bash-kommando, eller vidtar någon åtgärd med verkliga konsekvenser, pausar det och ber om ditt godkännande. Du ser vad det avser att göra och bekräftar eller nekar. Varje session börjar här om du inte konfigurerar annat.
Planläge flyttar bekräftelsepunkten ännu tidigare. Istället för att utföra något genererar Claude en komplett plan över vad det skulle göra och stannar. Inga filer rörs, inga kommandon körs. Du läser planen, utvärderar den och bestämmer om du vill fortsätta. Det här är det högsta granskningsläget — maximal synlighet innan åtgärd. Det är rätt startpunkt för okända kodsbaser, riskfyllda operationer, eller när du vill tänka innan AI:n rör sig.
Auto-godkänn (konfigurerat via allowedTools i .claude/settings.json) låter dig förhandsgodkänna specifika verktyg så att de körs utan att fråga. Du kan auto-godkänna filläsningar och vissa projektspecifika skript medan du fortfarande kräver bekräftelse för bash-kommandon. Det här minskar friktionen på operationer du redan har resonerat om och litar på, utan att blankt inaktivera tillsyn.
Förbigående läge (--dangerously-skip-permissions) tar bort alla bekräftelsedialoger. Claude agerar utan att pausa. Det här finns för CI-pipelines, automatiserade testmiljöer och sandlådecontainrar där det inte finns någon människa som kan godkänna något. Det är inte för produktionskodsbaser, inte för bekvämlighet, inte för att spara tid.
Ansvarsimplikationen av varje läge
Här är den del som inte finns i någon inställningsdokumentation.
När du är i standardläge och godkänner varje åtgärd fattar du ett beslut. Du såg vad Claude avsåg att göra, utvärderade det och sa ja. Om den åtgärden leder till ett dåligt resultat äger du det — du fattade beslutet.
När du är i planläge och godkänner planen gäller samma sak. Du granskade hela omfånget av vad som skulle hända, kom fram till att det verkade rätt och lät det fortsätta. Resultatet är ditt.
När du auto-godkänner ett verktyg fattar du ett förhandsbeslut: du har redan resonerat om den här klassen av operation och dragit slutsatsen att den inte kräver granskning per session. Det beslutet är också ditt.
När du kringgår behörigheter helt delegerar du beslutet helt till AI:n. Det finns inget granskningsmoment. Det finns inget tillfälle då din bedömning kom in. Om något går fel gick det fel på en nivå du medvetet valde att inte granska.
Det här är inte ett omdöme om något läge. Alla är lämpliga i rätt sammanhang. Men ansvarslogiken bör vara explicit: det läge du väljer bestämmer vilken gransningsskyldighet du accepterar eller tackar nej till.
När varje läge passar
Rätt läge är inte detsamma i alla situationer. Det beror på kostnaden för ett misstag och kvaliteten på den kontext som finns tillgänglig.
Ny eller okänd kodbas: Börja i planläge. Innan Claude skriver något, se planen. Förstå vad den avser att ändra och varför. En okänd kodbas har okända beroenden, implicita konventioner och filer du kanske inte omedelbart känner igen som känsliga.
Mogen kodbas med bra tester och versionskontroll: Standardläge är lämpligt. Claude frågar innan varje skrivning. Du granskar diffs. Kombinationen av bekräftelse per åtgärd och git-historik innebär att misstag är spårbara och reversibla.
Greenfield-utforskning eller engångsprototyping: Högre autonomi är rimligt. Om du genererar boilerplate, skapar ett nytt projekt från grunden, eller utforskar hur en funktion kan se ut — och du kommer att granska hela utdata innan du använder något av det — innebär auto-godkännande av fler operationer inte någon betydande risk.
CI-pipelines och automatiserade arbetsflöden: Förbigående läge är lämpligt, förutsatt att miljön verkligen är isolerad. Nyckelfrågan: om det värsta möjliga kommandot kördes, vad skulle skadeverkningarna bli? Om svaret är "containern kastas bort" är förbigående läge säkert. Om svaret involverar riktiga databaser eller delad infrastruktur är det det inte.
Var lägesinställningar finns
Claude Code separerar globala inställningar från projektinställningar.
Globala inställningar finns i ~/.claude/settings.json. Dessa är dina personliga standardvärden för alla projekt.
Projektinställningar finns i .claude/settings.json i repo-roten. Dessa checkas in i repositoriet, vilket innebär att de delas med teamet.
Lokala åsidosättningar finns i .claude/settings.local.json. Dessa ignoreras av git som standard, vilket innebär att de är personliga för din maskin och inte påverkar teammedlemmar.
Hierarkin är: global → projekt → lokal. Lokala åsidosättningar vinner.
Vanliga misstag
Bekräftelseutmattning i standardläge. Att stanna i standardläge för allt, inklusive operationer du har godkänt dussintals gånger, skapar friktion som gradvis tränar dig att godkänna snabbt utan att läsa. Bekräftelsen blir en knapp att klicka, inte ett granskningsmoment. Auto-godkänn specifika lågriskoperationer för att göra de återstående bekräftelserna meningsfulla.
Auto-godkänn-övertro. Det motsatta misstaget är blankt auto-godkännande för att det känns snabbare. Auto-godkänna bash-kommandon på en kodbas du inte känner fullt ut är detsamma som att be någon köra godtyckliga skript på din maskin utan att visa dig vad de gör.
Förbigående läge på verklig data. Det farligaste misstaget är att använda --dangerously-skip-permissions utanför en engångsmiljö för att det minskar friktionen. Flaggnamnet är korrekt: det är farligt.
Föregående i serien: Del 4 — Subagenter, MCP och arkitekturen bakom Code Review
Nästa i serien: Del 6 — Tokenekonomi: den osynliga kostnaden för kontext