Cum să alegeți modul de permisiuni în Claude Code

Îi cereți agentului să adauge un banner, iar el propune și actualizarea unui modul vechi. E util să vedeți planul înainte de modificări și să eliminați pasul în plus. Pentru asta contează atât cerința clară, cât și modul de lucru ales.

Modul de permisiuni stabilește cum sunt autorizate acțiunile în Claude Code: ce poate face imediat, pentru ce vă va întreba și ce va fi blocat. Setările și permisiunile acordate deja influențează, de asemenea, anumite acțiuni. Modul în sine nu verifică dacă soluția este corectă.

Să trecem prin toate modurile folosind exemplul unei sesiuni locale Claude Code în terminal.

Solicitarea și permisiunea

Aici e ușor să confundați două lucruri asemănătoare la prima vedere, dar care funcționează diferit.

Primul este ce scrieți în cerință: o secțiune cu excepții, formularea "mai întâi arată-mi planul, nu modifica nimic", lista fișierelor care nu trebuie atinse. Acestea sunt limitele sarcinii: explică sarcina și influențează considerabil propunerea agentului. Dar rămân text și nu schimbă permisiunile tehnice.

Al doilea este modul de permisiuni, numit și permission mode. Este o setare a sesiunii. Puteți să-i scrieți "nu modifica nimic" și totuși să lucrați într-un mod care acceptă automat editările. Agentul ar trebui să respecte solicitarea, însă fraza în sine nu blochează tehnic modificările.

Există o excepție, dar e parțială. În modul auto, un clasificator citește conversația și tratează mesaje precum "nu da push" sau "așteaptă revizuirea mea" drept semnale de blocare a acțiunilor respective. Totuși, asta nu devine o regulă în setări: dacă mesajul cu interdicția dispare la comprimarea contextului, se pierde și interdicția. Pentru o limită fermă, folosiți setările, nu o frază.

Modurile, de la sigur la riscant

Modurile sunt mai ușor de reținut ca o scară, nu ca o listă. Sus, agentul aproape că nu face nimic fără dumneavoastră; jos, nu întreabă deloc. Sunt cinci trepte și încă un mod care nu se potrivește pe această scară.

Urmăriți un singur lucru: câte acțiuni se execută fără răspunsul dumneavoastră. Numărul crește de sus în jos, la fel și costul unei greșeli. Sus, pierdeți timp cu confirmările; jos, aflați despre o modificare nereușită abia după ce s-a produs.

Pe scurt, fiecare mod:

• plan - agentul analizează proiectul și propune modificări înainte să le implementeze; între timp, editarea fișierelor sursă este blocată. Există o singură excepție: dacă sesiunea pornește cu bypassPermissions permis, planificarea în terminal nu mai blochează modificările, agentului i se cere doar să nu schimbe nimic. Folosiți-l când așteptați un răspuns despre cod, nu modificări în cod. Și comenzile de investigare sunt verificate de clasificator dacă auto este disponibil, așa că aici puteți primi chiar mai puține întrebări decât în default. E mai sus pe scară fiindcă nu modifică fișierele sursă. După ce planul e gata, Claude Code vă întreabă cum doriți să continuați: să-l aprobați și să treceți la auto, să-l aprobați cu confirmarea manuală a editărilor sau să continuați planificarea.
• default, afișat de obicei ca Manual - vă întreabă înainte de editări, comenzi și acces la rețea. Citirea proiectului și permisiunile deja acordate nu cer confirmare, deci nu va trebui să aprobați fiecare acțiune din nou. Uneori vă întreabă și pentru o comandă care pare inofensivă. Nu e o formalitate inutilă: find cu opțiunea -exec poate rula orice comandă, iar -delete șterge ce a găsit. De aceea, aceste variante nu se execută fără răspunsul dumneavoastră.
• acceptEdits, afișat ca "accept edits" - aplică singur modificările fișierelor din folderul de lucru și execută unele comenzi pentru fișiere, inclusiv rm și mv. E o opțiune pentru mai multă viteză când lucrați cu fișiere cunoscute, pe care oricum le veți reciti la final.
• auto - face aproape totul singur. Citirea și editările din folderul de lucru se execută imediat, iar comenzile și accesul la rețea sunt verificate de un model separat, clasificatorul. Acesta blochează unele acțiuni; revenim mai jos la subiect.
• bypassPermissions, activat și prin opțiunea --dangerously-skip-permissions - nu întreabă aproape nimic. Rămân active doar regulile explicite din setările dumneavoastră (interdicțiile și "întreabă întotdeauna") și câteva protecții ale sistemului. I se spune YOLO, pe bună dreptate.

Al șaselea mod, dontAsk, apare separat în diagramă. Iată de ce. Treptele se deosebesc prin numărul acțiunilor care trec fără răspunsul dumneavoastră; cu cât coborâți, cu atât i se permite mai mult agentului. dontAsk funcționează invers: nici el nu întreabă, dar în loc să aprobe, refuză. Execută ce nici în modul obișnuit nu necesită o întrebare (citirea fișierelor din folderul de lucru, comenzi sigure doar pentru citire), plus ce a fost permis dinainte. Tot ce ar necesita o întrebare este respins fără nicio întrebare. Sesiunea pur și simplu nu așteaptă răspunsul. E util în fluxuri automatizate și medii izolate, unde nu are cine să răspundă; în lucrul obișnuit la calculator nu vă va fi de folos.

Modul nu se schimbă printr-o solicitare în chat, ci manual. În terminal, apăsați Shift+Tab pentru a parcurge modurile în ciclu sau folosiți comanda /plan ca să începeți planificarea. Puteți seta modul și la pornire:

claude --permission-mode plan

Comanda se introduce în terminal, din folderul proiectului; /plan se folosește într-o sesiune deja deschisă. În editor, comutatorul arată diferit și se află sub câmpul de introducere, dar reperul e același peste tot: indicatorul modului curent.

Două precizări vă ajută să nu supraestimați scara. Planificarea nu e o copie de rezervă: nu creează un punct de restaurare și nu anulează ce s-a făcut deja, ci doar vă arată planul înainte să devină modificări. Și nicio treaptă nu schimbă limitele sarcinii - ele rămân cele pe care le-ați descris.

Când auto încurcă în loc să ajute

Merită să ajustați din timp o așteptare legată de auto. Modul se numește "automat", așa că poate părea că permite absolut totul. Nu e așa: clasificatorul există tocmai pentru a opri unele acțiuni.

În mod implicit, clasificatorul blochează, printre altele, deploy-uri în producție și migrări, trimiterea datelor către adrese externe, push-ul forțat, ștergerile în masă din stocarea cloud, acordarea permisiunilor, descărcarea și rularea codului din rețea, precum și ștergerea ireversibilă a fișierelor care existau înainte de începerea sesiunii. Logica listei e simplă: sunt lucruri pe care nu le puteți anula pe cont propriu.

Ce urmează depinde de numărul blocărilor. O acțiune blocată apare în lista celor respinse recent (/permissions, fila Recently denied), de unde o puteți porni din nou cu confirmare manuală. Între timp, Claude primește refuzul și încearcă altă cale. Dacă clasificatorul blochează acțiuni de trei ori la rând sau de douăzeci de ori într-o sesiune, modul se suspendă, iar Claude Code revine la întrebările obișnuite. După confirmarea dumneavoastră, auto se activează din nou. Pragurile sunt fixe și nu pot fi configurate.

Aici se vede când modul începe să vă încurce. Dacă sarcina are o singură comandă discutabilă, auto funcționează cum trebuie: o aprobați manual și continuați. Dar când sarcina constă tocmai din astfel de comenzi - configurați un mediu de testare, rulați migrări, lucrați cu infrastructura altcuiva - rezultatul e ciudat. Oricum confirmați manual aproape fiecare pas, doar că prin ocolișuri inutile: agentul întâlnește o blocare, caută o cale ocolitoare, iar modul ba se suspendă, ba se reactivează.

Într-un astfel de moment, e mai simplu să urcați singur mai sus pe scară. Alegerea depinde de ce anume vă încurcă:

• default - cea mai directă opțiune. Fiecare editare și comandă cere permisiunea dumneavoastră, iar acțiuni respinse nu apar deloc. E mai lent, dar vedeți fiecare pas;
• acceptEdits - potrivit când sunteți de acord cu modificările fișierelor, iar comenzile discutabile sunt doar cele de tip deploy sau migrare. Rețineți însă: în folderul de lucru, acest mod execută rm și mv fără să întrebe, în timp ce în auto clasificatorul bloca ștergerea fișierelor existente.

Asta nu înseamnă că ocoliți blocarea, iar cele două situații nu trebuie confundate. Nu dezactivați verificarea, ci vă ocupați personal de ea. Nici în bypassPermissions nu se poate șterge fără confirmarea dumneavoastră o cale de sistem, precum rădăcina discului sau folderul personal. În acest mod și în auto, Claude Code vă va întreba, iar în terminal aveți la dispoziție câteva minute pentru răspuns. Acolo unde nu are cum să întrebe, auto respinge o astfel de comandă, iar dontAsk o respinge întotdeauna. Ideea e alta: să nu faceți un ocoliș inutil acolo unde oricum urma să confirmați totul manual.

Al doilea motiv pentru a urca pe scară nu are legătură cu blocările. Clasificatorul stabilește dacă o acțiune e riscantă, dar nu dacă munca merge în direcția potrivită. Dacă agentul modifică pentru a treia oară același lucru și rezultatul tot nu e bun, în auto va încerca pur și simplu a patra oară, tot fără întrebări. Dezvoltatorii Claude Code recomandă să nu insistați în acel moment: reveniți la plan, validați din nou planul și abia apoi continuați. Același principiu se aplică de la început. Dacă înțelegeți sarcina în întregime, o puteți încredința direct unui mod mai liber. Dacă nici dumneavoastră nu știți încă sigur care ar trebui să fie rezultatul, începeți cu plan.

Ce schimbă asta în lucrul de zi cu zi

În activitatea de zi cu zi, totul se reduce la patru obiceiuri.

1. uitați-vă la indicator la începutul sesiunii. El arată modul curent; pentru fiecare acțiune contează și permisiunile deja acordate;
2. comparați planul propus cu limitele sarcinii înainte să fie pus în aplicare. Un pas în plus se elimină cu câteva cuvinte, cea mai ieftină modificare posibilă;
3. citiți opțiunea prin care aprobați planul: aceasta vă spune în ce mod va continua sesiunea după ieșirea din plan;
4. verificați rezultatul după execuție. Niciun mod nu garantează că sarcina a fost rezolvată corect; verificarea vă revine dumneavoastră.

Modul de permisiuni răspunde la întrebarea "ce se poate face fără mine", nu la "s-a făcut corect?". Indiferent ce alegeți, a doua întrebare rămâne în grija dumneavoastră.