Manual rejimində adi bir iş saatı. Agent layihəni oxuyur, dəyişiklik təklif edir, testləri işə salmağı xahiş edir, sonra yenə dəyişiklik və testlər. İyirminci sualda artıq diqqətlə baxmadan "Yes" düyməsini basırsınız. Bu sualların arasında da layihədə çoxdan heç kimin toxunmadığı və toxunmamalı olduğu legacy/ qovluğunda bir dəyişiklik gözdən yayına bilər.
Bu məqalədə sualları yalnız qərarın həqiqətən sizdən asılı olduğu yerlərdə necə saxlamaqdan danışacağıq. Claude Code-da bunun üçün icazə qaydaları var: tənzimləmə faylındakı üç siyahı agentə nəyi dərhal edə biləcəyini, nə barədə soruşmalı olduğunu və nəyi ümumiyyətlə etməməli olduğunu bildirir. Gəlin, onların nə üçün lazım olduğunu, necə oxunduğunu və yəqin ki, artıq sizdə olan qaydalar faylını necə qaydaya salmağı nəzərdən keçirək.
Hər şey üçün bir tənzimləmə
Giriş rejimi bütün sessiya üçün bir tənzimləyici kimidir. Onu istənilən tərəfə çevirmək olar, amma yalnız bütövlükdə.
Sərt Manual rejimində agent hər dəyişiklikdən və demək olar ki, hər əmrdən əvvəl soruşur. Sual sizi yalnız onu oxuduğunuz müddətdə qoruyur. Suallar çoxalanda onları oxumamağa başlayırsınız, qorunma isə yalnız kağız üzərində qalır.
Daha sərbəst acceptEdits rejimində dəyişikliklər soruşulmadan tətbiq olunur, eləcə də rm və mv kimi fayl əmrləri. Öz kodunuz üçün bu rahatdır. Amma rejim qovluqları fərqləndirmir: legacy/ qovluğundakı dəyişiklik də layihənin başqa yerindəki kimi səssizcə tətbiq olunacaq.
CLAUDE.md faylına "legacy/ qovluğuna toxunma" yaza bilərsiniz. Agent buna əməl etməyə çalışacaq, amma bu, modelə xahişdir, qadağa deyil. İcazə qaydalarını hərəkət icra olunmazdan əvvəl Claude Code özü yoxlayır; CLAUDE.md faylındakı və ya sorğudakı mətn onlara təsir etmir.
Deməli, müxtəlif hərəkətlərdə səhvin qiyməti də fərqlidir, amma rejim hamısına eyni cavab verir. Testləri səssizcə işə salmaq yaxşı olardı. Başqasının modulundakı dəyişikliyi isə görmək istəyirsiniz. Agentin toxunmamalı olduğu dondurulmuş qovluq da var. Üç fərqli hərəkətə üç fərqli cavab lazımdır, amma rejim bunu bacarmır.
Üç siyahı
Qaydalar məhz bu üç cavabı verir:
allow- soruşmadan icra etmək. Səs-küyü aradan qaldırır: tez-tez görülən təhlükəsiz işlər artıq diqqətinizi yayındırmır;ask- həmişə soruşmaq. Qərarın sizdən asılı olduğu yerdə sualı saxlayır, ən sərbəst rejimdə belə;deny- icra etməmək. Agent rədd cavabı alır, sizə isə sual göstərilmir. Bu da istənilən rejimdə keçərlidir.
Qaydalar tənzimləmə faylında, məsələn layihənin .claude/settings.json faylında yazılır. Girişdəki layihə üçün bu, belə görünə bilər:
{
"permissions": {
"allow": [
"Bash(npm test)"
],
"ask": [
"Edit(src/partner/**)"
],
"deny": [
"Edit(legacy/**)",
"Bash(git push *)"
]
}
}Burada src/partner/ ehtiyatla dəyişiklik etdiyiniz başqa komandaya aid moduldur, legacy/ layihənin dondurulmuş hissəsidir, npm test isə agentin bir tapşırıq ərzində on dəfə işə saldığı yoxlamadır. İki ulduz "qovluğun istənilən dərinliyindəki hər şey" deməkdir.
İndi sessiyada nə dəyişdiyinə baxaq. Üç konfiqurasiyada eyni beş hərəkət:
| Hərəkət | Qaydasız Manual | Qaydasız acceptEdits | Qaydalı acceptEdits |
|---|---|---|---|
Qalan src/ qovluğunda dəyişiklik | sual | sual yoxdur | sual yoxdur |
src/partner/ daxilində dəyişiklik | sual | sual yoxdur | sual |
legacy/ daxilində dəyişiklik | sual | sual yoxdur | rədd edilir |
npm test | sual | sual | sual yoxdur |
git push | sual | sual | rədd edilir |
Sonuncu sütuna baxın. Sessiya sürətli rejimdə işləyir: öz kodunuz fasiləsiz dəyişdirilir, testlər avtomatik başlayır. Cəmi bir sual qalıb və bu, dəyişikliyə həqiqətən baxmaq istədiyiniz yerlə bağlıdır. İki yolverilməz hərəkət də artıq axşam nə qədər yorğun olmağınızdan asılı deyil.
Qaydalar məhz buna görə lazımdır. Məqsəd agentə daha çox icazə vermək yox, onları səhvin qiymətinə görə bölməkdir. Beləcə daha sərbəst rejimdə işləyərkən vacib yerlərə nəzarəti itirmirsiniz.
Bir hərəkət eyni anda bir neçə qaydaya uyğun gələ bilər, buna görə Claude Code siyahıları dəqiq ardıcıllıqla yoxlayır:
Sxem yuxarıdan aşağı oxunur və agentin hər hərəkəti yenidən bu yoxlamadan keçir. Qayda uyğun gələn kimi yoxlama bitir, daha konkret qayda üstünlük qazanmır. deny siyahısında Bash(git push *) varsa, allow siyahısındakı heç bir qayda push-a icazə verməyəcək. Qadağanı təsadüfən üstələmək olmur, bu da yaxşıdır.
Aşağıdakı düzbucaqlını ayrıca yadda saxlamağa dəyər. Hərəkət siyahıların heç birinə düşmürsə, bu, "icazə verilib" demək deyil. Rejim qərar verir: Manual rejimində agent soruşur, acceptEdits rejimində dəyişiklik özü tətbiq olunur. Yəni qaydalar heç nəyi ləğv etmir, sadəcə sizin qeyd etdiyiniz yerlərdə rejimi dəqiqləşdirir.
Qayda necə oxunur
Az qala düzgün yazılmış qayda heç qayda olmamasından da pisdir. Qayda olmayanda sərhədin olmadığını bilirsiniz. Qeyri-dəqiq qaydada isə sərhədin olduğunu düşünürsünüz, amma o, təsəvvür etdiyiniz şeyi qorumur.
Bütün qaydaların formatı eynidir: alətin adı və mötərizədə onun konkret nəyə aid olduğu. Mötərizəsiz qayda alətin bütün çağırışlarına aiddir, buna görə deny siyahısındakı Bash agentin terminalını tamamilə bağlayır.
Fayllar
Fayllar üçün iki alət lazımdır: istənilən dəyişiklik üçün Edit, oxumaq üçün isə Read. Yol .gitignore faylındakı kimi şablonla yazılır: bir ulduz bir qovluğun daxilində istənilən ada, iki ulduz isə istənilən dərinlikdəki qovluqlara uyğun gəlir. Əvvəlində slash olmayan yol sessiyanın başladığı qovluğa nisbətən hesablanır, buna görə Claude Code-u layihənin kökündən başladın.
Tez-tez edilən səhv Write(legacy/**) yazmaqdır. Agentdə bu adda alət var, amma Claude Code fayl qaydalarını yalnız Edit və Read alətləri ilə tutuşdurur. Write qaydasını qəbul edib, işə başlayanda xəbərdarlıq göstərəcək və sonra onu yoxlamayacaq. Edit isə faylları dəyişdirməyin bütün daxili üsullarını, yeni fayl yaratmağı da əhatə edir.
Bir əlverişli məqam da var: məsələn, deny siyahısındakı Read(./.env) oxuma qadağası agentin bu fayla dəyişiklik etməsini də qadağan edir.
Əmrlər
Bash(...) qaydası əmr mətnini müqayisə edir. Ulduz boşluqlar da daxil olmaqla istənilən mətni əvəz edir. Qaydanın uyğun gəlib-gəlməməsini üç detal müəyyənləşdirir:
- ulduz yoxdursa, qayda yalnız hərfi-hərfinə eyni olan bir əmrlə uyğun gəlir;
- ulduz altəmrdən sonra yazılır.
Bash(git log *)istənilən flaqla yalnızgit logəmrini buraxır,Bash(git *)isə push da daxil olmaqla istənilən git əmrini buraxır; - ulduzdan əvvəlki boşluq da qaydanın bir hissəsidir:
Bash(ls *)lsofilə uyğun gəlməyəcək,Bash(ls*)isə uyğun gələcək.
Mavi hissə əmrlə hərfi-hərfinə tutuşdurulur, narıncı hissəni isə ulduz tam əhatə edir, orada nə yazılmasının fərqi yoxdur. Buna görə qaydanın əhatə dairəsini ulduzdan əvvəl yazılanlar müəyyən edir. Birinci qaydada bu, git log-dur və o, tarixçəyə baxmaqdan başqa heç nəyi buraxmır. İkincidə yalnız git var, ulduzdan sonra isə push, budaq silmək və ya dəyişiklikləri sıfırlamaq ola bilər. Başqasının qaydasını oxuyanda bu sualla başlayın: ulduzdan əvvəl nə yazılıb?
| Qayda | Uyğun gəlir | Uyğun gəlmir |
|---|---|---|
Bash(npm test) | npm test | npm test --watch |
Bash(npm run *) | npm run build, npm run lint --fix | npm install |
Bash(git log *) | git log, git log --oneline | git push |
Bash(git *) | git push da daxil olmaqla istənilən git əmri | - |
Edit(src/partner/**) | src/partner/ daxilində istənilən fayla dəyişiklik | src/app.js faylına dəyişiklik |
Read(./.env) | layihənin kökündəki .env faylını oxumaq | .env.example faylını oxumaq |
Claude Code a && b kimi mürəkkəb əmri hissələrə bölür. allow yalnız hər hissə öz icazəsinə uyğun gələndə əmri buraxır. ask və deny isə hissələrdən ən azı biri uyğun gələndə işləyir. Beləliklə, npm test üçün icazə npm test && git push əmrini də özü ilə keçirməyəcək.
Digər alətlər üçün də qaydalar var. Məsələn, bir MCP serverinin bütün alətləri üçün mcp__github__*, yaxud bir saytdan səhifələri yükləmək üçün WebFetch(domain:example.com). Onların məntiqi də eynidir, burada ayrıca nəzərdən keçirməyəcəyik.
Qaydaları hansı faylda saxlamaq
Qaydanı yanlış fayla yazmaq işi səssizcə poza bilər. Qadağanı şəxsi fayla əlavə etsəniz, həmkarlarınızda bu qayda olmayacaq və onların agenti legacy/ qovluğuna rahatlıqla girəcək. Özünüz üçün rahat olan icazəni ümumi fayla əlavə etsəniz, layihəni endirən hər kəsə də ötürüləcək.
| Fayl | Qaydalar kim üçündür | Git-ə düşür |
|---|---|---|
~/.claude/settings.json | sizindir, bu kompüterdəki bütün layihələrdə | xeyr, ev qovluğundadır |
.claude/settings.json | layihə ilə işləyən hər kəs üçün ümumidir | bəli, commit olunur |
.claude/settings.local.json | sizindir, yalnız bu layihədə | xeyr |
Bu üç fayldan başqa, təşkilat öz tənzimləmə faylını da paylaşa bilər və onun qaydalarını üstələmək mümkün olmur. Təlim layihələrində belə fayl adətən olmur.
Müxtəlif fayllardakı siyahılar bir-biri ilə rəqabət aparmır, birləşir: sizin fayldakı allow ümumi fayldakı allow siyahısına əlavə olunur. Yoxlama ardıcıllığı hamısı üçün eynidir və istənilən fayldakı deny başqa fayldakı allow qaydasından güclüdür. Belə bölgü məntiqlidir. Layihənin legacy/, .env və ya push kimi sərhədlərini ümumi fayla yazın ki, onlar repozitoriya ilə birlikdə getsin. Öz iş tərzinizə uyğun rahatlıqları isə lokal faylda saxlayın.
Ümumi faylın bir qoruyucu xüsusiyyəti var. Onun allow qaydaları yalnız qovluğa etibar etdiyinizi təsdiqləyəndən sonra işləməyə başlayır: Claude Code layihədə ilk dəfə başladılanda bu barədə soruşur və faylın nəyə icazə verəcəyini göstərir. ask və deny isə dərhal qüvvəyə minir, çünki onlar yalnız məhdudiyyət qoyur. Bütün terminala icazə verən yad repozitoriya siz razılaşana qədər heç nə əldə etməyəcək.
Əslində hansı qaydaların qüvvədə olduğunu iki əmrlə yoxlamaq olar. /permissions bütün qaydaları və hər birinin gəldiyi faylı göstərir; orada qayda əlavə etmək və silmək də mümkündür. /status əmri Setting sources sətrində yüklənmiş faylları sadalayır. Claude Code fayllardakı dəyişiklikləri yenidən başlatmadan tətbiq edir. Tənzimləmə faylı ciddi JSON formatındadır: // ilə şərh və ya sonuncu elementdən sonra vergül faylı pozacaq, Claude Code da başlanğıcda bu barədə xəbərdarlıq edəcək.
Agent əmr barədə soruşanda "Yes, and don't ask again" seçsəniz, Claude Code allow qaydasını .claude/settings.local.json faylına yazır. Fayl hələ yoxdursa, onu yaradıb commit-lərə düşməməsinə də diqqət edir. Fayllardakı dəyişikliklərdə isə başqa cürdür: belə razılıq sessiyanın sonuna qədər qüvvədə qalır və fayla yazılmır.
Həqiqi settings.local.json faylını araşdıraq
Çox güman ki, sizdə bu fayl artıq var və onu siz yazmamısınız. Hər "bir daha soruşma" seçimi fayla bir sətir əlavə edib, bir-iki həftədən sonra isə fayl agentə düşündüyünüzdən artıq icazə verir. Budur, Python layihəsində bir neçə həftəlik iş ərzində yığılmış həqiqi blok:
{
"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 *)"
]
}
}Təhlili oxumazdan əvvəl özünüz cavab verməyə çalışın. Hansı sətirləri saxlayar, hansıları daraldar, hansıları silərdiniz?
Bash(python3 *)
Fayldakı ən geniş sətirdir. İstənilən skripti və python3 -c vasitəsilə istənilən kodu işə salmağa icazə verir. Python hər şeyi bacarır: faylları silir, şəbəkəyə qoşulur, başqa proqramları başladır. Əslində bu qayda soruşmadan istənilən şeyi icra etməyə icazə verir. Onu, məsələn, Bash(python3 scripts/build.py *) kimi, bu qaydanın yaranmasına səbəb olan konkret skriptə qədər daraltmaq lazımdır.
Bash(PYTHONIOENCODING=utf-8 python3 *)
Eyni əmr, əvvəlində mühit dəyişəni ilə. allow qaydası belə yazılışı yalnız dəyişən əvvəlcədən məlum təhlükəsiz dəyişənlərin qısa siyahısındadırsa buraxır. Siyahıda yoxdursa, Bash(python3 *) bu əmri əhatə etmir, agent ayrıca soruşur və düymə daha bir qayda saxlayır. Bu sətir də yəqin ki, belə yaranıb. Onu da eyni qaydada konkret skriptə qədər daraltmaq olar.
git status, git log, git diff, git show
Adi formada bu əmrlər yalnız oxuyur, Claude Code isə oxuma əmrlərini sualsız və heç bir qayda olmadan icra edir. Bu sətirlər zərər vermir, amma demək olar ki, heç nə də əlavə etmir. Onları silin, fayl daha qısa və aydın olsun.
Bash(git branch *)
Zərərsiz görünür: budaqların siyahısına baxmaq. Amma qayda mətni müqayisə edir, git branch -D feature əmri də git branch ilə başlayır. Budaq silmək sualsız keçəcək. Bu sətri silmək daha yaxşıdır. Budaqların siyahısı barədə sual mane olmağa başlasa, ulduzsuz dəqiq Bash(git branch) əmrinə icazə verin.
git add və git fetch
Birincisi dəyişiklikləri gələcək commit üçün əlavə edir, ikincisi serverdən yeni tarixçəni endirir və iş fayllarına toxunmur. Hər ikisini asanlıqla geri qaytarmaq olar, saxlamaq mümkündür.
Bash(git commit *)
Agent soruşmadan commit edir, yəni siz diff-i oxumazdan əvvəl. Sualın lazım olduğu yer elə buradır: commit dəyişikliklə razılaşdığınız məqamdır. Bu sətri ask siyahısına keçirmək lazımdır. Sadəcə silmək kifayət deyil. Manual rejimində agent onsuz da soruşacaq, amma ask ən sərbəst rejim də daxil olmaqla istənilən rejimdə sualı saxlayır.
Faylda olmayanlar
git push. Bu yaxşıdır, amma yalnız ona görə ki, indiyədək heç kim push zamanı "bir daha soruşma" düyməsini basmayıb. Qadağanı açıq şəkildə yazmaq daha etibarlıdır.
Təhlildən sonra belə alınır:
{
"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 *)"
]
}
}On sətirdən altısı qaldı və hər biri nəzərdə tutulan işi görür. İş zamanı suallar demək olar ki, artmadı: build özü işləyir, agent isə yalnız commit-dən əvvəl bir dəfə soruşur. Push qadağası bütün komandaya aiddirsə, əvvəlki bölmədəki qaydaya uyğun olaraq onu ümumi .claude/settings.json faylına keçirmək daha yaxşıdır.
Bash(python3 *), Bash(node *), Bash(npm *) və ya Bash(npx *) kimi qaydalar bir alətə icazə kimi görünür. Əslində isə həmin alətin işə sala biləcəyi istənilən kod üçün icazədir. Bütün proqrama yox, konkret skriptə və ya əmrə icazə verin.
Qayda nələri tutmur
Agent rədd cavabı aldı. Onun üçün bu adi alət cavabıdır və iş davam edir. Bəzən o, eyni işi görməyin başqa yolunu axtarır; burada qaydanın məhz nəyi yoxladığını anlamaq vacibdir.
Bash(...) qaydası işə düşəcək proqramı yox, əmr mətnini müqayisə edir. Buna görə qadağa əmrin adi yazılışını əhatə edir, amma bütün variantları yox:
denysiyahısındakıBash(git push *)git -C . pushəmrini dayandırmayacaq. Əmr eynidir, yazılışı fərqlidir;Bash(rm *)/bin/rmvə yabash -c 'rm ...'əmrlərini dayandırmayacaq;Read(...)qadağası faylı özü açan Python skriptinə mane olmayacaq.
Buna görə qaydalardan imtina etməyə ehtiyac yoxdur. Agent demək olar ki, həmişə əmri adi formada yazır və deny məhz həmin variantı tutur. Amma qayda keçilməz divar deyil, Claude Code sənədlərində də bu açıq yazılıb. Agent dolama yol axtarmasın deyə qadağanı CLAUDE.md faylında sözlə izah edin: "legacy/ dondurulub; tapşırıq orada dəyişiklik tələb edirsə, dayan və soruş". Qayda əmri bloklayır, CLAUDE.md isə səbəbini izah edir; birlikdə daha yaxşı işləyirlər.
Sərhədin mütləq qorunması lazımdırsa, bunun üçün başqa mexanizmlər var: hər əmri icradan əvvəl yoxlayan hook və sistem səviyyəsində girişi məhdudlaşdıran sandbox. Bunlar ayrıca mövzulardır.
Gündəlik qaydalar
Bütün bunları bir neçə vərdişə sığışdırsaq:
denysiyahısına bu layihədə heç bir halda yolverilməz olanları yazın: dondurulmuş qovluq,.env, push;asksiyahısında yalnız qərarın sizdən asılı olduğu sərhəd halları saxlayın. Hər şey üçünasksuallardan yaranan yorğunluğu geri qaytaracaq;allowsiyahısında dar qaydalar və təkrarlanan işlər olsun: konkret yoxlama, konkret skript;- layihə sərhədlərini ümumi
.claude/settings.jsonfaylında, şəxsi rahatlıqları isə.claude/settings.local.jsonfaylında saxlayın; - arada bir
/permissionsaçıb "bir daha soruşma" düyməsinin topladıqlarını təmizləyin; - yeni qaydadan sonra onu yoxlayın: agentdən qadağan olunmuş hərəkəti etməsini istəyin və rədd cavabı aldığından əmin olun.
Layihənin zonalarını agentə sözlə təsvir edin: harada sərbəst dəyişiklik etmək olar, harada soruşmaq lazımdır, hara girmək olmaz. Ondan permissions bloku təklif etməsini istəyin və JSON-u yadda saxlamazdan əvvəl yuxarıdakı təhlildəki suallarla oxuyun. Qayda lazım olduğundan geniş deyil ki? Düzgün fayla düşəcək?
Rejim işin ümumi tempini müəyyən edir, qaydalar isə harada yavaşımaq lazım olduğunu göstərir. Birlikdə heç bir rejimin təkbaşına verə bilmədiyini təmin edirlər: səhvin ucuz olduğu yerdə sürətli iş, baha başa gələcəyi yerdə isə sual və ya rədd cavabı.
GO TO FULL VERSION