Claude Code permissions: co smí agent a kdy bypass

--dangerously-skip-permissions vypne v Claude Code dotazy na oprávnění pro celou session. Je to totéž co --permission-mode bypassPermissions a dokumentace Anthropicu doporučuje používat ho jen v kontejnerech nebo VM, kde Claude Code nemůže nic poškodit. Bereme to doslova: na notebooku vývojáře pracuje agent pod pravidly allow, ask a deny a pod hooky, plný bypass běží jen v izolovaném stroji s vlastními účty.

Krátká odpověď pro CTO: přepínač nezakazujte, rozhodněte, kde je povolený. Pravidla na notebook, hooky na to, co pravidla nevidí, izolace na všechno, co běží bez dozoru.

Co --dangerously-skip-permissions doopravdy vypne?

Claude Code má šest režimů oprávnění. Přepínač vybere poslední z nich:

„Všechno“ má výjimky a ty jsou podstatné. Podle dokumentace k režimům žádný režim automaticky neschválí nástroje, na které sedí explicitní pravidlo ask, rozpoznané mazání kritických cest přes rm ani nástroje, které potřebují člověka, třeba AskUserQuestion. Hooky běží dál. Bypass ale odstraní dotaz před zápisem do chráněných cest jako .git a .claude, který si všechny ostatní režimy nechávají.

Bypass tedy neznamená „žádná pravidla“. Znamená „žádný člověk ve smyčce“. Otázka je, jestli ve smyčce zůstalo něco jiného.

Jak rozhodují pravidla allow, ask a deny?

Pravidla jsou v settings.json jako tři seznamy. Tohle je zkrácená verze z našeho veřejného Claude Code production starteru:

{
  "permissions": {
    "allow": ["Bash(pnpm check)", "Bash(pnpm test:*)", "Bash(bash scripts/gate.sh:*)"],
    "ask": ["Bash(git push:*)", "Bash(gh pr merge:*)", "Bash(vercel --prod:*)", "Bash(wrangler deploy:*)"],
    "deny": ["Read(**/.env)", "Read(**/*.pem)", "Bash(git push --force:*)", "Bash(git reset --hard:*)", "Bash(psql:*)"]
  }
}

Tvar seznamů je sám o sobě pravidlo. Allow pro to, co agent potřebuje ke kontrole vlastní práce. Ask pro všechno, co opouští stroj: push, merge, deploy. Deny pro tajné klíče, přepisování historie a přímý přístup do databáze.

Claude Code vyhodnocuje nejdřív deny, pak ask, nakonec allow, a vyhrává první shoda. Užší allow deny nikdy neotevře. Platí to i napříč soubory: deny v repozitáři přebije allow v osobním nastavení. Proto týmová pravidla patří do .claude/settings.json v repozitáři a osobní zrychlení do ~/.claude/settings.json.

Kvůli téhle větě stojí za to přesunout každé „nikdy nedělej X“ z CLAUDE.md do pravidla nebo hooku.

Co pravidlo oprávnění nevidí?

Pravidlo porovnává text příkazu. Tři věci mu proklouznou:

• Do které větve. Bash(git push:*) nerozliší git push origin feat/x od git push origin main. Když se ptá při každém pushi, lidé začnou klikat ano bez čtení.
• Nepřímý přístup. Dokumentace to říká na rovinu: pravidla deny pro Read nepokryjí skript v Pythonu nebo Node, který si soubor otevře sám, a deny pro Bash nesedí na stejný program uvnitř sh -c.
• Kontext. Pravidlo neví, kdo session spustil a v jakém repozitáři běží.

Tady si PreToolUse hook vydělá na sebe. Dostane celé volání nástroje jako JSON, může v něm mít libovolnou logiku a exit 2 volání zablokuje dřív, než se pravidla vůbec vyhodnotí. Jádro našeho push gate, zkráceně:

CMD=$(jq -r '.tool_input.command // empty')
[[ "$CMD" != *"git push"* ]] && exit 0
BRANCH=$(git -C "${CLAUDE_PROJECT_DIR:-.}" branch --show-current 2>/dev/null)
if [[ "$CMD" =~ [[:space:]:](main|master)([[:space:]]|$) || "$BRANCH" == "main" ]]; then
  echo "Pushing to main is not allowed. Push a branch and open a PR." >&2
  exit 2
fi

Verze v našem firemním pluginu jde dál: čte úroveň repozitáře, takže v repozitářích s kódem blokuje push do každé chráněné větve všem, zatímco v repozitářích s dokumentací smí pushovat zakladatel. Pravidlem se to vyjádřit nedá.

I hook potřebuje vlastní test, jinak může potichu přestat fungovat. Přesně tak jsme přišli o týden, popisujeme to v článku Claude Code hooks: proč naše hooky nedělaly nic.

Kdy je vypnutí oprávnění opravdu bezpečné?

Když je hranicí samotný stroj. Naše běhy bez dozoru staví s --permission-mode bypassPermissions a --disallowedTools AskUserQuestion ExitPlanMode, protože na dotaz by nikdo neodpověděl. Přijatelné to není kvůli přepínači, ale kvůli tomu, co je kolem něj. Pro AI agenta, který u nás nonstop pracuje na issues, to vypadá takhle:

I v bypassu zůstává merge na člověku. Agent otevře pull request, ochrana větve vyžaduje schválení a to schválení nikdy nepatří agentovi.

CI reviewer je opačný extrém. Taky běží bez dozoru, ale místo bypassu dostane výslovný seznam nástrojů:

claude_args: --allowed-tools "Read,Glob,Grep,Bash(git diff:*),Bash(git log:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Umí přečíst diff a napsat komentář. Neumí upravovat, pushovat ani mergovat, takže není co obcházet.

A co vestavěný sandbox?

Claude Code má sandbox na úrovni operačního systému, který omezuje, co smí shellové příkazy číst, zapisovat a kam se smí připojit, včetně jejich podprocesů. Je to správná odpověď na druhé slepé místo výše, protože nezávisí na textu příkazu.

Dvě nastavení stojí za to znát, než cokoli rozšíříte do týmu. permissions.disableBypassPermissionsMode: "disable" v managed settings vezme bypass všem. Uživatel si ho může nastavit i sám pro sebe.

Jak nastavit oprávnění Claude Code pro tým?

Projděte, co už vaše repozitáře mají:

Na pořadí záleží. Pravidla deny nestojí nic a hned první den zastaví nejhorší případy. Pak přijde hook. Izolaci potřebujete, až když něco běží bez člověka, který se dívá.

Jak tato pravidla sedí vedle CLAUDE.md a týmových konvencí, rozebíráme v článku Pravidla pro AI kód v týmu. Jak smyčka bez dozoru dovede issue až k pull requestu, je v článku Harness engineering v praxi.

Chcete agenty, kteří jsou rychlí a produkci přesto nerozbijí?

Pravidla oprávnění, hooky, izolaci a CI nastavujeme přímo v repozitářích týmu v rámci služby AI-native SDLC pro vývojové týmy. AI dnes píše veškerý náš kód a za výsledek ručí senior. Od roku 2023 jsme dodali 15+ produkčních projektů.

Ozveme se do dvou pracovních dnů a společně vybereme, co vyřešíme jako první.

Pokud si chcete nejdřív promluvit, domluvte si meeting na 15 minut s Filipem.

Kam by se váš agent dostal dnes, kdyby nikdo neodpověděl na jediný dotaz?

Časté otázky

Co dělá --dangerously-skip-permissions v Claude Code?

Spustí session v režimu bypassPermissions, stejně jako --permission-mode bypassPermissions. Claude Code se přestane ptát před příkazy, úpravami souborů a stahováním. Explicitní pravidla ask, pár kritických mazání a nástroje, které potřebují člověka, se ptají dál a hooky běží dál.

Je YOLO mode v Claude Code bezpečný?

Jen v izolovaném prostředí. Anthropic píše, že bypassPermissions patří jen do kontejnerů nebo VM, kde Claude Code nemůže nic poškodit. Na vývojářském notebooku se skutečnými přístupy použijte pravidla oprávnění a hooky.

V jakém pořadí se vyhodnocují pravidla allow, ask a deny?

Nejdřív deny, pak ask, nakonec allow. Vyhrává první shoda v tomto pořadí, takže pravidlo allow nikdy neudělá výjimku z deny a ask se zeptá, i když sedí i užší allow.

Kde jsou uložená nastavení oprávnění Claude Code?

V souborech settings.json: managed settings pro celou firmu, ~/.claude/settings.json pro jednoho člověka, .claude/settings.json v repozitáři pro tým a .claude/settings.local.json pro lokální výjimky. Managed settings mají přednost a deny z jakékoli úrovně přebije allow z jiné.

Jak vývojářům zakázat režim bypass?

Nastavte permissions.disableBypassPermissionsMode na "disable", ideálně v managed settings, kde to nikdo nepřepíše.