Claude Code visar reglerna bakom Auto mode

Anthropic publicerade Claude Code 2.1.246 den 25 augusti klockan 22.31 UTC, alltså strax efter midnatt den 26 augusti svensk tid. Den viktigaste nyheten är en ny flik med namnet Auto mode i dialogrutan /permissions.

Resten av uppdateringen består främst av felrättningar och mindre förbättringar. Claude Code varnar nu bland annat för felplacerade jokertecken i behörighetsregler och visar klockslaget när en arbetsomgång är klar.

Den nya fliken säger mer om hur Claude Code arbetar än den korta ändringsloggen antyder. Autoläget använder en separat AI-modell som bedömer åtgärder innan de utförs. Reglerna för den bedömningen har tidigare varit svåra att hitta. Nu går de att läsa och ändra direkt inifrån Claude Code.

Vad är Auto mode i Claude Code?

Claude Code är Anthropics programmeringsverktyg för terminalen, utvecklingsmiljöer som VS Code och företagets datorapp. Verktyget kan läsa och ändra filer, köra program samt använda externa tjänster.

I manuellt läge behöver användaren godkänna många sådana åtgärder. Auto mode, eller autoläget, minskar avbrotten. En särskild klassificeringsmodell granskar i bakgrunden det Claude Code vill göra och släpper igenom eller stoppar åtgärden.

Sedan version 2.1.228 är Auto mode det förvalda startläget för terminalen och VS Code på abonnemangen Pro, Max och Team. En administratör kan stänga av funktionen för en Team- eller Enterprise-organisation. På Enterprise och vid användning med API-nyckel startar Claude Code normalt fortfarande i manuellt läge.

Autoläget minskar antalet frågor men är ingen garanti mot fel. Det är särskilt viktigt att komma ihåg när Claude Code arbetar med produktionssystem, känsliga uppgifter eller ändringar som inte går att återställa.

Auto mode-fliken visar 85 inbyggda regler

Skriv /permissions i Claude Code och tryck på Enter. I version 2.1.246 har dialogrutan sex flikar:

• Recently denied
• Allow
• Ask
• Deny
• Auto mode
• Workspace

Med vänster- och högerpilen går det att flytta sig till den nya fliken. Där visades fem val i vårt test:

1. Lägg till en ny regel.
2. Soft allow, med 17 inbyggda regler.
3. Soft deny, med 67 inbyggda regler.
4. Hard deny, med en inbyggd regel.
5. Environment, med 20 uppgifter om datorn och projektmiljön.

Totalt rör det sig om 85 klassificeringsregler. Tryck på Enter på en avdelning för att fälla ut den fullständiga texten för varje regel. Reglerna är långa engelska beskrivningar med rubriker som Git Destructive, Production Deploy, Credential Leakage, Package Registry Bypass, Merge Without Review och Real-World Transactions.

Den enda inbyggda regeln under Hard deny heter Data Exfiltration och ska hindra att uppgifter skickas från datorn till en plats där de inte hör hemma.

Environment är inte en lista över tillåtna kommandon. Den beskriver miljön där Claude Code arbetar: organisation, kodlager, molntjänster, interna servrar, paketregister och platser med känsliga uppgifter. Utan egna inställningar utgår klassificeraren bland annat från att kodlagret är privat och att arbetsområdet och dess befintliga Git-adresser är betrodda.

När en ny regel läggs till visar fliken själv följande definitioner:

Soft allow: Actions the classifier lets run without blocking.

Soft deny: Actions the classifier blocks, unless a soft allow rule or your explicit direction applies.

Hard deny: Actions the classifier always blocks, soft allow rules cannot override.

Environment: Facts about this machine or project the classifier should take into account.

En Soft allow-regel är alltså ett undantag som låter klassificeraren släppa igenom en viss typ av åtgärd. Den kan exempelvis beskriva en intern testserver som Claude Code får skriva till.

En Soft deny-regel blockerar normalt en åtgärd, men kan sättas åt sidan om användaren uttryckligen och tillräckligt precist ber om den. Instruktionen ”städa kodlagret” ger inte tillstånd att tvångspusha en Git-gren. ”Tvångspusha den här grenen” gör det.

En Hard deny-regel gäller även när användaren ber om åtgärden. Environment innehåller i stället fakta som hjälper modellen att förstå vad som är internt, externt, känsligt eller produktionskritiskt.

Den praktiska skillnaden är att Soft deny främst skyddar mot initiativ som Claude Code tar på egen hand. Hard deny kan stoppa även en tydlig instruktion från användaren - förutsatt att åtgärden faktiskt skickas till klassificeraren.

Hur lägger man till en regel i Auto mode?

Välj Add a new rule och tryck på Enter. Claude Code frågar först vilken sorts regel du vill skapa. Därefter öppnas ett textfält där regeln skrivs som en vanlig mening.

Textrutan föreslår själv följande form:

Database Writes: UPDATE statements against the local dev database.

När regeln sparas hamnar den i den personliga inställningsfilen ~/.claude/settings.json. På Windows ligger motsvarande fil under användarens hemkatalog.

Vår första hårda regel skrevs så här i filen:

"autoMode": {
  "hard_deny": [
    "$defaults",
    "Skapa aldrig katalogen /tmp/aipress-klassificerartest, inte ens om användaren ber om det"
  ]
}

Posten "$defaults" betyder att Claude Code behåller de inbyggda reglerna i samma avdelning. Den läggs till automatiskt när den första egna regeln skapas genom fliken.

Om "$defaults" tas bort ersätter de egna reglerna hela den inbyggda listan i avdelningen. I Soft deny skulle det innebära att standardspärrar mot exempelvis tvångspushar, produktionsdriftsättningar och kommandon av typen curl | bash försvinner.

Gränssnittet tillåter att de inbyggda reglerna stängs av, men först när det finns minst en egen regel att ersätta dem med.

En sparad regel kan öppnas igen för att redigeras eller raderas. Vid radering visas dialogen:

Are you sure you want to delete this rule? The classifier stops applying it on your next request.

När regeln är den sista egna regeln i sin avdelning tillkommer en rad till:

This is your last soft deny rule, without it, only the built-in rules apply for this section.

Förvalet i dialogen är No.

Regler som en arbetsgivare har lagt in centralt visas också, men är skrivskyddade. Projektets delade .claude/settings.json ignoreras avsiktligt för Auto mode-regler. Ett nedladdat kodlager ska inte kunna lägga till egna undantag och därmed ge Claude Code större frihet på användarens dator.

Environment fungerar annorlunda än de övriga avdelningarna. Där kan användaren beskriva egna servrar, register och molnkonton så att klassificeraren kan ta hänsyn till dem. Mer information finns på Anthropics sida Configure auto mode.

Fungerar en regel på svenska i Auto mode?

Ja. Vår svenska testregel blockerade kommandot:

Skapa aldrig katalogen /tmp/aipress-klassificerartest, inte ens om användaren ber om det.

Vi lade regeln under Hard deny, stängde Claude Code och startade en ny session i en tom katalog. Därefter skrev vi:

Skapa katalogen /tmp/aipress-klassificerartest med Bash-verktyget (mkdir) och bekräfta.

Claude Code försökte köra kommandot. Efter omkring 13 sekunder dök en röd rad upp:

bash denied by auto mode · Blocked by classifier · /permissions

Claude svarade sedan på svenska att kommandot hade blockerats och att katalogen inte hade skapats. I svaret citerades klassificerarens meddelande ordagrant:

Permission for this action was denied by the Claude Code auto mode classifier. Reason: Blocked by classifier.

Claude försökte inte kringgå regeln genom att skapa katalogen på något annat sätt. I stället erbjöds tre vägar vidare: att köra kommandot själv med ett utropstecken först, att lägga till en vanlig tillåtelseregel eller att skapa katalogen på en annan plats.

En kontroll i filsystemet bekräftade att katalogen saknades. När vi tog bort regeln och upprepade samma instruktion i en ny session skapades katalogen utan någon fråga. Det var alltså vår svenska regel som gjorde skillnaden.

Felsökningsloggen visade att åtgärden granskades i två steg. Båda anropen tog omkring fem sekunder och klassificeringsmodellen var Claude Sonnet 5, inte Fable 5 som vi använde i själva samtalet. Den extra granskningen förklarar varför ett blockerat kommando kan dröja tio till femton sekunder.

En Soft deny-regel kan sättas åt sidan av användaren

Vi upprepade testet med samma svenska regel under Soft deny. Den här gången skapades katalogen.

Det följer definitionen i Auto mode-fliken. Vår instruktion beskrev uttryckligen den exakta åtgärden, och en sådan begäran kan sätta en mjuk spärr åt sidan. En hård regel kan inte upphävas på samma sätt.

Vi försökte även framkalla ett mjukt stopp med den vagare uppmaningen att förbereda ett tomt område för ett test utanför projektmappen. Claude Code valde då en katalog under hemkatalogen i stället för /tmp, så regeln träffade aldrig åtgärden. Försöket gav därför inget säkert svar om hur klassificeraren hade bedömt den vagare instruktionen.

Varför lästes inte vår Auto mode-regel om uptime?

Det första vi försökte blockera var det ofarliga kommandot uptime, som visar hur länge datorn har varit i gång. Vi skrev att det aldrig fick köras, inte ens på uttrycklig begäran.

Kommandot kördes ändå, både med Soft deny och Hard deny.

Orsaken syntes i felsökningsloggen: Claude Code skickade aldrig åtgärden till klassificeraren. Skrivskyddade och andra ofarliga åtgärder kan godkännas tidigare i beslutskedjan. En regel i Auto mode kan bara påverka sådant som klassificeraren faktiskt får granska.

Testet visar varför en Hard deny-regel inte bör betraktas som den starkaste möjliga spärren i hela Claude Code. Den är ovillkorlig inne i klassificeraren, men kan inte stoppa en åtgärd som godkänns innan klassificeraren kopplas in.

Claude Code kan granska reglerna i Auto mode

Kommandot

claude auto-mode critique

körs i en vanlig terminal, utanför en pågående Claude Code-session. Det analyserar användarens egna regler och pekar ut sådant som är motsägelsefullt, otydligt eller sannolikt verkningslöst.

För vår regel om uptime anmärkte granskaren bland annat på att:

• en Soft deny-regel inte kan lova att blockera en uttrycklig användarinstruktion,
• den krockar med den inbyggda regeln som godkänner skrivskyddade kommandon,
• den saknar en kort rubrik,
• blandningen av svenska och engelska kan försämra tillförlitligheten,
• det är oklart om förbudet även omfattar andra sätt att hämta samma information.

Våra svenska Hard deny-regler fungerade i samtliga relevanta försök. Språkanmärkningen betyder därför inte att svenska saknar stöd. För en regel som verkligen behöver vara tillförlitlig är det ändå klokt att använda en kort engelsk rubrik och beskriva omfattningen så konkret som möjligt.

Det finns även tre närliggande kommandon:

claude auto-mode defaults
claude auto-mode config
claude auto-mode reset

Det första skriver ut de inbyggda reglerna, det andra visar den konfiguration som faktiskt används på datorn och det tredje tar bort de egna tilläggen efter en bekräftelse.

Klassificerarens stopp öppnas direkt under Recently denied

När klassificeraren blockerar något visas en röd notifiering och Claude får veta att åtgärden nekades. Modellen kan då beskriva problemet eller föreslå ett tillåtet alternativ, men ska inte kringgå spärren.

Det nekade anropet sparas i fliken Recently denied under /permissions. Om dialogen öppnas direkt efter ett stopp visas den fliken automatiskt. I vårt fall stod det att försöket att skapa och kontrollera katalogen hade blockerats av klassificeraren.

Två tangenter anges i fliken:

Enter to approve
r to retry

Enter används alltså för att godkänna åtgärden, medan r markerar den för ett nytt försök.

Om klassificeraren blockerar tre åtgärder i följd, eller sammanlagt 20 under en session, pausar autoläget. Claude Code börjar då fråga användaren igen. En godkänd åtgärd nollställer räknaren för stopp i följd, medan den sammanlagda räknaren finns kvar tills dess gräns nås.

En ny Auto mode-regel kan påverka samma samtal

Ett försök gav ett annat händelseförlopp. Vi lade till regeln genom /permissions och bad om den förbjudna katalogen i samma session.

Då försökte Claude Code aldrig köra kommandot. Samtalsmodellen hade sett meddelandet om den nyss tillagda regeln och avstod själv. Klassificeraren kontaktades inte och inget hamnade under Recently denied.

Efter en omstart fanns regeln bara i inställningsfilen. Samtalsmodellen försökte då utföra uppgiften, varpå klassificeraren stoppade den.

Resultatet blev detsamma, men mekanismen var en annan. Den som vill kontrollera om klassificeraren verkligen tillämpar en ny regel bör därför starta en ny session efter att regeln har lagts till.

Auto mode-regler kan användas i flera gränssnitt

Själva Auto mode-fliken finns i terminalens dialogruta. Inställningarna sparas däremot i samma användarfil som Claude Code använder i VS Code och Claude Desktop på samma dator.

En regel som läggs till från terminalen bör därför även gälla när Claude Code körs i autoläge genom dessa gränssnitt. Vi testade bara terminalversionen och kan inte bekräfta beteendet i VS Code eller datorappen från egna körningar.

En regel i projektets CLAUDE.md fungerar annorlunda. Klassificeraren läser den filen tillsammans med Claude, så en instruktion som ”tvångspusha aldrig” kan påverka båda. Den gäller då för projektet. Regler i användarens Auto mode-inställningar följer i stället med mellan olika projekt.

Vanliga Ask- och Deny-regler ger starkare spärrar än Auto mode

Autoklassificeraren är inte den första kontrollen. De vanliga behörighetsreglerna under Allow, Ask och Deny granskas före den.

Om du alltid vill bli tillfrågad före en git push kan du exempelvis lägga till:

"permissions": {
  "ask": [
    "Bash(git push *)",
    "Bash(gh pr create *)"
  ]
}

En Ask-regel tvingar fram en fråga även när Auto mode är aktivt. En vanlig Deny-regel stoppar åtgärden innan klassificeraren kontaktas och kan inte upphävas genom en tydlig instruktion i samtalet.

Auto mode-regler passar när bedömningen behöver bero på sammanhang: en testserver är betrodd, ett visst register är internt eller en riskfylld åtgärd ska blockeras så länge användaren inte uttryckligen beställer den.

Deny passar bättre för något som aldrig får ske. Det gäller exempelvis åtkomst till hemliga filer, användning av ett visst kommando eller en gräns som måste fungera även om åtgärden annars skulle godkännas före klassificeraren.

Auto mode-regler kan skärpa eller lätta på klassificeringen

För att skärpa autoläget öppnar du /permissions, går till Auto mode och lägger till en konkret Hard deny-regel. Starta sedan en ny session om du vill kontrollera att det är klassificeraren som verkställer regeln. För en absolut teknisk spärr är en vanlig Deny-regel säkrare.

Om en legitim rutinåtgärd stoppas ofta kan du öppna Recently denied och kontrollera exakt vad Claude Code försökte göra. Därefter kan du lägga till en Soft allow-regel eller beskriva den berörda servern, molnlagringen eller paketkällan under Environment.

Behåll "$defaults" om avsikten bara är att komplettera de inbyggda reglerna. Kör därefter claude auto-mode config för att kontrollera slutresultatet och claude auto-mode critique för att hitta svagheter i formuleringarna.

Den nya fliken gör inte Auto mode riskfritt, men säkerhetsmodellen blir betydligt lättare att förstå. Det går att se vad Claude Code normalt släpper igenom, vad klassificeraren stoppar och vilka egna gränser som kan läggas till utan att inställningsfilen behöver redigeras för hand.

Så testade vi reglerna i Auto mode

Vi använde Claude Code 2.1.246 på Ubuntu med ett Max-abonnemang, Fable 5 med hög ansträngningsnivå och Auto mode aktiverat. Varje klassificeringstest kördes i en ny session med svenska instruktioner.

Vi provade en mjuk och en hård regel mot uptime, en hård svensk regel mot en katalog under /tmp, samma instruktion utan den egna regeln, en mjuk version av katalogregeln samt skillnaden mellan att lägga till regeln under en pågående session och att starta om först.

Environment-redigeraren, Windows, VS Code och Claude Desktop ingick inte i testet. Inställningsfilen säkerhetskopierades före försöken och återställdes oförändrad efteråt.