Pravidlá allow, ask a deny: čo môže agent robiť bez opýtania

Typická hodina práce v režime Manual. Agent číta projekt, navrhne úpravu, požiada o spustenie testov, potom ďalšia úprava, znova testy. Pri dvadsiatej otázke stlačíte "Yes" takmer naslepo. A niekde medzi nimi prejde úprava v priečinku legacy/, na ktorý už v projekte dávno nik nesiaha a ani by nemal.

Tento článok ukazuje, ako ponechať otázky len tam, kde rozhodnutie naozaj patrí vám. Claude Code má na to pravidlá oprávnení: tri zoznamy v súbore nastavení určujú, čo môže agent urobiť hneď, na čo sa má opýtať a čo nesmie urobiť vôbec. Pozrime sa, načo sú, ako ich čítať a ako upratať súbor s pravidlami, ktorý už pravdepodobne máte.

Jedno nastavenie na všetko

Režim oprávnení je jediný ovládač pre celú reláciu. Môžete ho otočiť ktorýmkoľvek smerom, ale iba ako celok.

V prísnom režime Manual sa agent pýta pred každou úpravou a takmer pred každým príkazom. Otázka vás chráni len dovtedy, kým ju čítate. Keď ich je priveľa, prestanete ich čítať a ochrana zostane len na papieri.

Vo voľnom režime acceptEdits prechádzajú úpravy bez otázky, rovnako aj príkazy na prácu so súbormi, napríklad rm a mv. Pri vlastnom kóde je to pohodlné. Režim však nerozlišuje priečinky: úprava v legacy/ prejde rovnako potichu ako kdekoľvek inde v projekte.

Do súboru CLAUDE.md môžete napísať "nesiahaj na legacy/". Agent sa o to pokúsi, ale je to prosba adresovaná modelu, nie zákaz. Pravidlá oprávnení kontroluje samotný Claude Code ešte pred vykonaním akcie. Text v CLAUDE.md ani v požiadavke na ne nemá vplyv.

Rôzne akcie teda prinášajú rôzne riziko, no režim odpovedá na všetky rovnako. Testy sa môžu spúšťať potichu. Úpravu cudzieho modulu chcete vidieť. Do zmrazeného priečinka agent nemá vstupovať vôbec. Tri rôzne akcie si pýtajú tri rôzne odpovede, ktoré samotný režim dať nevie.

Tri zoznamy

Pravidlá poskytujú práve tieto tri odpovede:

• allow - vykonať bez otázky. Odstráni zbytočný šum: opakované a bezpečné akcie vás už nevyrušujú;
• ask - vždy sa opýtať. Otázka zostane tam, kde rozhodujete vy, a to v každom režime, aj v tom najvoľnejšom;
• deny - nevykonať. Agent dostane zamietnutie a vám sa otázka ani nezobrazí. Platí to tiež v každom režime.

Pravidlá sa zapisujú do súboru nastavení, napríklad do projektového .claude/settings.json. Pre projekt z úvodu by to mohlo vyzerať takto:

{
  "permissions": {
    "allow": [
      "Bash(npm test)"
    ],
    "ask": [
      "Edit(src/partner/**)"
    ],
    "deny": [
      "Edit(legacy/**)",
      "Bash(git push *)"
    ]
  }
}

Tu je src/partner/ cudzí modul, v ktorom upravujete kód opatrne, legacy/ je zmrazená časť projektu a npm test je kontrola, ktorú agent v rámci úlohy spustí aj desaťkrát. Dve hviezdičky znamenajú "všetko v priečinku na ľubovoľnej úrovni".

Pozrime sa, čo sa zmení v relácii. Tých istých päť akcií v troch variantoch:

Všimnite si posledný stĺpec. Relácia beží vo svižnom režime: vlastný kód sa upravuje bez prestávok a testy sa spúšťajú automaticky. Zostala jedna otázka - pri mieste, kde si úpravu naozaj chcete skontrolovať. A dve neprípustné akcie už nezávisia od toho, ako ste večer unavení.

Práve preto sú pravidlá užitočné. Nejde o to, aby agent dostal viac povolení, ale aby ste ich rozdelili podľa ceny prípadnej chyby. Potom môžete pracovať vo voľnejšom režime a nestratiť kontrolu nad dôležitými miestami.

Jedna akcia môže zodpovedať viacerým pravidlám, preto Claude Code kontroluje zoznamy v pevnom poradí:

Schéma sa číta zhora nadol a každá akcia agenta ňou prejde odznova. Keď sa pravidlo zhoduje, kontrola sa končí a ďalšie, špecifickejšie pravidlo už nedostane prednosť. Ak je v deny pravidlo Bash(git push *), nijaké pravidlo v allow už push nepovolí. Zákaz sa nedá omylom prebiť, a to je dobre.

Spodný obdĺžnik si zapamätajte osobitne. Ak akcia nepatrí do nijakého zoznamu, neznamená to, že je "povolená". Rozhoduje režim: v Manual sa agent opýta, v acceptEdits úprava prejde automaticky. Pravidlá teda režim nerušia, iba ho spresňujú pre akcie, ktoré ste určili.

Ako čítať pravidlo

Takmer správne zapísané pravidlo je horšie ako nijaké. Bez pravidla viete, že hranica neexistuje. Pri nepresnom si myslíte, že tam je, ale nechráni to, čo ste čakali.

Všetky pravidlá majú rovnaký formát: názov nástroja a v zátvorkách spresnenie, čoho sa týka. Bez zátvoriek sa pravidlo vzťahuje na všetky volania nástroja, takže Bash v deny agentovi odoberie celý terminál.

Súbory

Pri súboroch treba poznať dva nástroje: Edit na každú úpravu a Read na čítanie. Cesta sa zapisuje pomocou vzoru ako v .gitignore: jedna hviezdička zastupuje ľubovoľný názov v jednom priečinku, dve ľubovoľnú hĺbku vnorenia. Cesta bez úvodnej lomky sa počíta od priečinka, v ktorom sa spustila relácia, preto spúšťajte Claude Code z koreňa projektu.

Častou chybou je pravidlo Write(legacy/**). Agent síce má nástroj s takým názvom, ale Claude Code pri pravidlách pre súbory kontroluje len Edit a Read. Pravidlo s Write prijme, pri spustení na to upozorní a ďalej ho nebude kontrolovať. Nástroj Edit pokrýva všetky vstavané spôsoby úpravy súborov vrátane vytvorenia nového.

A ešte jeden užitočný detail: zákaz čítania, napríklad Read(./.env) v deny, zároveň agentovi zakáže upraviť tento súbor.

Príkazy

Pravidlo Bash(...) porovnáva text príkazu. Hviezdička zastupuje ľubovoľný text vrátane medzier. O tom, či sa pravidlo zhoduje, rozhodujú tri detaily:

• bez hviezdičky sa pravidlo zhoduje s jediným príkazom presne znak po znaku;
• hviezdičku umiestnite za podpríkaz. Bash(git log *) prepustí iba git log s ľubovoľnými príznakmi, kým Bash(git *) prepustí každý príkaz git vrátane push;
• aj medzera pred hviezdičkou je súčasťou pravidla: Bash(ls *) sa nezhoduje s lsof, ale Bash(ls*) áno.

Modrá časť sa porovnáva s príkazom znak po znaku, oranžová časť sa vďaka hviezdičke zhoduje s čímkoľvek. Rozsah pravidla preto určuje text pred hviezdičkou. V prvom pravidle je to git log, takže prepustí len prezeranie histórie. V druhom je to iba git a za hviezdičkou sa môže objaviť push, odstránenie vetvy alebo reset zmien. Keď budete čítať cudzie pravidlo, začnite otázkou: čo je pred hviezdičkou?

Zložený príkaz, napríklad a && b, Claude Code rozdelí na časti. Pravidlo allow ho prepustí, len ak každá časť zodpovedá vlastnému povoleniu. Pravidlá ask a deny sa uplatnia, ak zodpovedá aspoň jedna časť. Povolenie na npm test teda so sebou neprepašuje npm test && git push.

Pravidlá možno nastaviť aj pre ďalšie nástroje, napríklad mcp__github__* pre všetky nástroje jedného MCP servera alebo WebFetch(domain:example.com) na načítanie stránok z jedného webu. Platí pri nich rovnaká logika, podrobnejšie sa im tu venovať nebudeme.

V ktorom súbore uchovávať pravidlá

Pravidlo v nesprávnom súbore môže potichu pokaziť prácu. Ak zákaz uložíte do osobného súboru, kolegovia ho nemajú a ich agent vojde do legacy/, akoby sa nič nedialo. Ak svoje pohodlné povolenie uložíte do spoločného súboru, dostane sa ku každému, kto si stiahne projekt.

Okrem týchto troch môže organizácia distribuovať vlastný súbor nastavení. Jeho pravidlá nemôžete prepísať. V učebných projektoch sa s tým zvyčajne nestretnete.

Zoznamy z rôznych súborov si neprotirečia, ale spájajú sa: vaše pravidlo allow sa pridá k spoločnému allow. Poradie kontroly je pre všetky rovnaké a deny z ktoréhokoľvek súboru má prednosť pred allow z iného. Z toho vyplýva jednoduché rozdelenie. Hranice projektu, napríklad legacy/, .env alebo push, zapisujte do spoločného súboru, aby cestovali spolu s repozitárom. Nastavenia pre vlastný spôsob práce patria do lokálneho.

Spoločný súbor má jednu ochrannú vlastnosť. Jeho pravidlá allow začnú platiť až po tom, čo potvrdíte dôveru v priečinok: pri prvom spustení v projekte sa vás na to Claude Code opýta a ukáže, čo chce súbor povoliť. Pravidlá ask a deny platia hneď, pretože iba obmedzujú. Cudzí repozitár nezíska povolenie na celý terminál, kým s tým nesúhlasíte.

Skutočne platné pravidlá si môžete overiť dvoma príkazmi. /permissions zobrazí všetky pravidlá aj súbor, z ktorého každé pochádza; priamo tam ich môžete pridať alebo odstrániť. Riadok Setting sources v /status vypíše načítané súbory. Zmeny v súboroch Claude Code načíta bez reštartu. Súbor nastavení musí byť platný JSON: komentár s // alebo čiarka za poslednou položkou ho pokazí a Claude Code vás na to pri spustení upozorní.

Rozoberme reálny settings.local.json

Tento súbor už pravdepodobne máte a nenapísali ste ho vy. Každé kliknutie na "Yes, and don't ask again" pridalo riadok, takže o pár týždňov povoľuje agentovi viac, než si myslíte. Tu je skutočný blok, ktorý sa nazbieral počas niekoľkých týždňov práce na projekte v Pythone:

{
  "permissions": {
    "allow": [
      "Bash(python3 *)",
      "Bash(PYTHONIOENCODING=utf-8 python3 *)",
      "Bash(git status *)",
      "Bash(git log *)",
      "Bash(git diff *)",
      "Bash(git show *)",
      "Bash(git branch *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git fetch *)"
    ]
  }
}

Skôr než si prečítate rozbor, skúste to sami. Ktoré riadky by ste ponechali, ktoré zúžili a ktoré odstránili?

Bash(python3 *)
Najširšie pravidlo v súbore. Povoľuje spustiť ľubovoľný skript aj ľubovoľný kód cez python3 -c. Python dokáže všetko: mazať súbory, pripájať sa na sieť aj spúšťať iné programy. V praxi teda povoľuje bez otázky vykonať čokoľvek. Zúžte ho na skript, pre ktorý vzniklo, napríklad na Bash(python3 scripts/build.py *).

Bash(PYTHONIOENCODING=utf-8 python3 *)
Ten istý príkaz s premennou prostredia na začiatku. Pravidlo allow takýto zápis prepustí len vtedy, ak premenná patrí do krátkeho zoznamu vopred známych bezpečných premenných. Ak v ňom nie je, pravidlo Bash(python3 *) príkaz nepokryje, agent sa opýta osobitne a tlačidlo uloží ďalšie pravidlo. Takto sa tam tento riadok pravdepodobne dostal. Aj toto pravidlo zúžte na konkrétny skript.

git status, git log, git diff, git show
V bežnom tvare tieto príkazy iba čítajú a Claude Code ich vykoná bez otázky aj bez pravidiel. Riadky neškodia, ale takmer nič nepridávajú. Odstráňte ich a súbor bude kratší a prehľadnejší.

Bash(git branch *)
Vyzerá nevinne: zobrazí zoznam vetiev. Pravidlo však porovnáva text a aj git branch -D feature sa začína na git branch. Vetva sa tak odstráni bez otázky. Riadok radšej vymažte. Ak vás otázka pri zobrazovaní zoznamu vetiev začne zdržiavať, povoľte presný príkaz Bash(git branch) bez hviezdičky.

git add a git fetch
Prvý pridá zmeny do budúceho commitu, druhý stiahne novú históriu zo servera a pracovných súborov sa nedotkne. Obe akcie sa dajú ľahko vrátiť, takže ich môžete ponechať.

Bash(git commit *)
Agent vytvorí commit bez otázky, teda skôr, než si prečítate diff. Práve tu sa otázka hodí: commit je chvíľa, keď odsúhlasíte zmenu. Presuňte toto pravidlo do ask. Samotné odstránenie nestačí. V režime Manual sa agent síce opýta aj tak, ale ask zachová otázku v každom režime vrátane toho najvoľnejšieho.

Čo v súbore chýba
git push. To je dobré, no drží sa to len vďaka tomu, že nikto nikdy nestlačil "Yes, and don't ask again" pri pushi. Spoľahlivejšie je zapísať zákaz priamo.

Po rozbore zostane toto:

{
  "permissions": {
    "allow": [
      "Bash(python3 scripts/build.py *)",
      "Bash(PYTHONIOENCODING=utf-8 python3 scripts/build.py *)",
      "Bash(git add *)",
      "Bash(git fetch *)"
    ],
    "ask": [
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Z desiatich riadkov zostalo šesť a každý plní svoj účel. Počet otázok sa takmer nezvýšil: zostavenie prebehne samo a agent sa opýta len na jednom mieste, pred vytvorením commitu. Ak zákaz pushu platí pre celý tím, presuňte ho podľa pravidla z predchádzajúcej časti do spoločného .claude/settings.json.

Čo pravidlo nezachytí

Agent dostal zamietnutie. Preňho je to bežná odpoveď nástroja a pokračuje v práci. Niekedy hľadá iný spôsob, ako dosiahnuť to isté. Preto je dôležité vedieť, čo presne pravidlo kontroluje.

Pravidlo Bash(...) porovnáva text príkazu, nie program, ktorý sa spustí. Zákaz preto zachytí bežný zápis príkazu, ale nie všetky jeho podoby:

• pravidlo Bash(git push *) v deny nezastaví git -C . push. Príkaz je rovnaký, zápis iný;
• pravidlo Bash(rm *) nezastaví /bin/rm ani bash -c 'rm ...';
• zákaz pre Read(...) nezabráni Python skriptu, aby súbor otvoril sám.

Pravidiel sa však kvôli tomu netreba vzdávať. Agent takmer vždy zapíše príkaz v bežnej podobe a deny zachytí práve tú. Pravidlo však nie je nepreniknuteľná stena (a dokumentácia Claude Code to hovorí priamo). Aby agent nemusel hľadať obchádzku, vysvetlite zákaz aj v súbore CLAUDE.md: "legacy/ je zmrazený priečinok; ak úloha vyžaduje úpravu v ňom, zastav sa a opýtaj sa". Pravidlo akciu zachytí, CLAUDE.md vysvetlí dôvod a spolu fungujú lepšie než každé zvlášť.

Ak má hranica platiť bez výnimky, použite iné mechanizmy: hook, ktorý kontroluje každý príkaz pred spustením, a sandbox, ktorý obmedzuje prístup na úrovni systému. To sú samostatné témy.

Každodenné pravidlá

Ak to zhrnieme do niekoľkých návykov:

• do deny patrí to, čo je v projekte neprípustné za každých okolností: zmrazený priečinok, .env, push;
• do ask patria len hraničné situácie, o ktorých rozhodujete vy. Pravidlo ask na všetko vráti únavu z otázok;
• do allow patrí úzko vymedzené a opakované: konkrétna kontrola či skript;
• hranice projektu patria do spoločného .claude/settings.json, osobné pohodlie do .claude/settings.local.json;
• občas otvorte /permissions a odstráňte pravidlá, ktoré pribudli po kliknutí na "Yes, and don't ask again";
• po pridaní pravidla ho otestujte: požiadajte agenta o zakázanú akciu a overte, že dostal zamietnutie.

Režim určuje celkové tempo práce, pravidlá hovoria, kde ho spomaliť. Spolu umožňujú to, čo samotný režim nedokáže: rýchlu prácu tam, kde je chyba lacná, a otázku či zamietnutie tam, kde je drahá.