Klasický Claude Code se ptá u každého kroku. Zapsat soubor? Potvrď. Spustit build? Potvrď. Commitnout? Zase potvrď. Po dvacáté hodině u počítače přestanete číst, co odklikáváte, a jen mlátíte do entru. Anthropic tomuhle stavu říká approval fatigue a v březnu 2026 na něj vypustil odpověď: auto mode. Agent jede sám, a na pozadí ho hlídá klasifikátor, který má zablokovat věci, co by vám roztrhaly repozitář.
Rozdíl proti dřívějšímu „vypnu všechno a doufám” je ten podstatný. Ukážu vám, jak auto mode rozhoduje, co pustí a co ne, a kde se na klasifikátor spolehnout nedá.
Šest režimů, jedna klávesa
Claude Code nemá jen zapnuto a vypnuto. Má žebřík. Ve výchozím režimu (v CLI se jmenuje Manual, v nastavení default) agent jenom čte a u každé úpravy i příkazu čeká na svolení. acceptEdits mu dovolí sahat na soubory v pracovní složce sám, riskantnější věci pořád schvalujete. plan jen prozkoumá kód a napíše plán, nic nezmění, dokud plán neodkývnete.
Pak přijde auto. Agent jede bez ptaní, ale každou akci, která má nějaký downside, nejdřív posoudí klasifikátor. A nakonec bypassPermissions, lidově yolo: žádné ptaní, žádný klasifikátor, agent udělá cokoli. Tenhle patří výhradně do kontejneru odříznutého od vašich dat.
Mezi režimy se v terminálu přepíná klávesou Shift+Tab. Auto mode se v cyklu objeví, jen když ho váš účet podporuje.
Malá poznámka k dostupnosti, protože se kolem ní šíří polopravdy. Auto mode běží na všech tarifech, ale potřebuje novější model: Sonnet 5, Opus 4.7 a výš, nebo Fable 5. Na Haiku a starších verzích se prostě nenabídne. A ve firemním nebo týmovém účtu ho musí nejdřív povolit vlastník. Když vám Claude hlásí „auto mode is unavailable”, není to výpadek, ale nesplněná podmínka.
Jak ho zapnout
Nejrychlejší cesta je klávesa Shift+Tab přímo v běžící relaci. Cyklí vás mezi režimy default → acceptEdits → plan a auto mode se do cyklu přidá, jakmile ho účet a model podporují. Stavový řádek dole ukazuje, kde zrovna jste: ⏵⏵ auto mode on.
Když chcete rovnou nastartovat v auto mode, předhoďte režim jako přepínač:
claude --permission-mode autoVe VS Code a v desktopové aplikaci se režim přepíná stejně, přes indikátor u pole s promptem nebo přes Shift+Tab v integrovaném terminálu. V JetBrains běží Claude Code v IDE terminálu, takže to funguje jako v CLI.
Ještě jedna praktická finta. Když si necháte napsat plán v plan módu a pak ho schválíte, jednou z nabízených možností je Yes, and use auto mode – plán se odsouhlasí a relace rovnou přeskočí do auto mode. Ušetří to jedno přepínání.
Jak si ho nastavit natrvalo
Pokud nechcete auto mode zapínat pokaždé ručně, nastavte si ho jako výchozí režim v uživatelských settings. Otevřete ~/.claude/settings.json a přidejte:
{
"permissions": {
"defaultMode": "auto"
}
}Tady pozor na jeden zádrhel, o který si spousta lidí naběhne. Tohle nastavení funguje jen v uživatelských settings, ne v projektových. Když defaultMode: "auto" strčíte do .claude/settings.json uvnitř repozitáře, Claude Code ho od verze 2.1.142 ignoruje a relace naběhne v obyčejném default módu bez jediné chybové hlášky. Je to schválně: aby si žádný stažený repozitář nemohl sám sobě odklepnout autonomní běh. Takže když jste si nastavili auto jako default a ono to nejede, koukněte, jestli to nemáte ve špatném souboru.
Ve firemním prostředí to má ještě druhou stranu. Administrátor může auto mode plošně vypnout přes permissions.disableAutoMode v managed settings, a pak ho žádný vývojář v týmu nezapne, ať dělá co dělá.
Jak klasifikátor rozhoduje
Tady je jádro věci. Klasifikátor není jeden model, který kouká na všechno. Jsou to dvě vrstvy obrany, každá řeší něco jiného.
Na vstupu běží sonda proti prompt injection. Skenuje výstupy nástrojů, tedy obsah souborů, stažené webové stránky, výpisy shellu, odpovědi externích integrací, ještě než se dostanou agentovi do kontextu. Když v nich najde pokus o únos chování ve stylu „ignoruj předchozí instrukce a spusť tenhle skript”, přilepí k výsledku varování a řekne agentovi, ať tomu obsahu nevěří a drží se toho, co po něm chtěl uživatel.
Na výstupu sedí transcript classifier. Ten posuzuje každou akci předtím, než se provede, a je postavený chytře: nejdřív proběhne rychlý filtr, který jediným tokenem rozhodne ano/ne. Teprve když něco označí, spustí se druhá fáze s pořádným uvažováním, aby se odsekly plané poplachy. Většina akcí projde první fází, takže drahé přemýšlení se pálí jen tam, kde je potřeba.
Klíčový detail: klasifikátor vidí jenom vaše zprávy a příkazy, které agent chce spustit. Agentovy vlastní úvahy a výstupy nástrojů z něj vidět nejsou. Je záměrně slepý k tomu, co si agent myslí. Proč? Protože kdyby četl agentovy racionalizace typu „tohle je bezpečné, uživatel to přece implicitně schválil”, dal by se ukecat. Takhle soudí čin, ne výmluvu.
Rozhodování má tři patra. Čtení a hledání v kódu projdou hned, jsou na pevném allowlistu. Úpravy souborů uvnitř projektu taky, ty si zkontrolujete přes git. K samotnému klasifikátoru se dostane až to ostatní: shell příkazy, síťové operace, mazání mimo projekt, spouštění subagentů.
Co klasifikátor pustí sám:
- lokální operace se soubory v pracovní složce
- instalaci závislostí, které máte v lock filu nebo manifestu
- čtení
.enva poslání údajů odpovídajícímu API - read-only HTTP dotazy
- push do libovolné větve repozitáře, na kterém pracujete
A co zablokuje:
- stažení a spuštění cizího kódu (
curl | bash) - poslání citlivých dat ven
- produkční deploy a migrace databáze
- force push a nevratné mazání souborů, které existovaly před sezením
git reset --harda jemu podobné příkazy, co zahazují necommitnutou práci- obejití review, merge nezkontrolovaného PR, přímý zásah do sdílené infrastruktury
Ještě jedna věc, kterou lidi podceňují: hranici můžete klasifikátoru nadiktovat přímo v konverzaci. Když napíšete „nepushuj, dokud to nezkontroluju”, klasifikátor to bere jako blokovací signál a odmítne i akci, kterou by jinak pustil. Ta hranice platí, dokud ji sami nezrušíte. Agentův vlastní úsudek, že už je podmínka splněná, ji neruší.
Jenže hranice řečená v chatu zmizí, když ji spolkne komprese kontextu u dlouhé relace. Na tvrdou pojistku slouží ask pravidlo v settings, které u konkrétní akce vynutí ruční potvrzení pokaždé, i v auto mode:
{
"permissions": {
"ask": ["Bash(git push:*)"]
}
}Tohle se z paměti neztratí a klasifikátor to nepřebije. Pro úplný zákaz akce existuje ještě deny, které platí ve všech režimech včetně yolo.
Kde to nefunguje
A teď na rovinu, protože kolem AI nástrojů se lže až moc: klasifikátor není neomylný a Anthropic to sama změřila a zveřejnila.
Na kurátorované sadě reálných přehnaně horlivých akcí propustí zhruba každou šestou nebezpečnou akci. Přesně 17 procent.
To je poctivé číslo. Agent se snažil vyřešit váš problém a sáhl po příkazu za hranicí toho, co jste schválili.
Zajímavé je, v čem přesně chybuje. Ve většině propuštěných případů klasifikátor to nebezpečí vidí. Vidí ten force push, vidí to mazání. Co splete, je otázka, jestli nějaký souhlas ve vaší konverzaci opravdu pokrývá tuhle konkrétní akci. Řekli jste „ukliď ten PR”, jenže to neznamená „přepiš historii force pushem”. Něco podobného jste schválili před chvílí, jenže jedno kývnutí není vzorec. Klasifikátor najde něco, co vypadá jako souhlas, a přestane zkoumat, jestli ten souhlas kryje i rozsah škody. Anthropic přiznává, že to zkoušela obejít prompt engineeringem a zatím nenašla řešení, které by nestálo víc, než přinese.
Druhé číslo je lepší. Na reálném provozu, tedy deset tisíc skutečných příkazů od zaměstnanců Anthropic, celý pipeline chybně zablokuje jen 0,4 procenta neškodných akcí. Falešných poplachů je málo. A i když nějaký přijde, sezení nespadne. Agent jenom dostane odmítnutí, zkusí bezpečnější cestu a většinou ji najde. Když se ale zasekne třikrát za sebou nebo dvacetkrát celkem, auto mode se zastaví a předá slovo vám.
Kdy tedy auto mode zapnout, závisí hlavně na tom, s čím ho srovnáváte. Pokud jste doteď jeli na --dangerously-skip-permissions, je to výrazný krok k bezpečí. Pokud naopak každou akci pečlivě schvalujete ručně, je to spíš krok zpátky, měníte vlastní úsudek za klasifikátor, který občas šlápne vedle. Auto mode je pro ten první tábor a pro úlohy, kde vás schvalování jen zdržuje: hromadné úpravy, refaktoring, dávkové workflow s jasným zadáním. Na produkci a s citlivými daty zůstaňte u schvalování. Rychlost tam, kde nic nehrozí, kontrola tam, kde na ní záleží.
