پیکربندی گاردریل‌ها
این راهنما نشان می‌دهد چگونه گاردریل‌ها را پیکربندی کنید: قواعدی که تعیین می‌کنند کنش یک عامل اجرا می‌شود، نخست درخواست تأیید می‌کند، یا رد می‌شود.
گاردریل‌ها سیزده کلاس اثری را پوشش می‌دهند که هر ابزار تغییردهنده اعلام می‌کند. آن‌ها سمت سرور، درست در نقطه‌ای که ابزار فراخوانی می‌شود اعمال می‌شوند، هرگز با دستوری در یک پرامپت.
تنظیم یک تصمیم برای یک کلاس کنش
بخش با عنوان “تنظیم یک تصمیم برای یک کلاس کنش”- به تنظیمات → فضای کاری → مجوزهای عامل بروید
- با کنترل بخش‌بندی‌شده یک محدوده انتخاب کنید: فضای کاری، عامل (سپس عامل را انتخاب کنید)، یا فضا (سپس فضا را انتخاب کنید)
- روی ردیف کلاس کنش، اجازه، ابتدا بپرس یا رد را انتخاب کنید
- برای حذف قاعده‌ای که گذاشته‌اید، دکمهٔ بازنشانی‌ای را بزنید که در انتهای همان ردیف ظاهر می‌شود (پاک کردن تا مقدار ارثی) — تصمیم به محدودهٔ گسترده‌تر بازمی‌گردد
هر ردیف تصمیم مؤثر را به‌صورت یک برچسب وضعیت و یک نشان برای منشأ آن نمایش
می‌دهد: این محدوده، به ارث رسیده یا پیش‌فرض داخلی. ماتریس در حالت
عامل (chat) حل می‌شود، پس پیش‌تنظیم حالت هرگز اینجا ظاهر نمی‌شود — برای
دیدن آن لایه، کاوشگر «اگر…؟» را با یک حالت فقط‌خواندنی انتخاب‌شده اجرا کنید.
نوشتن یک قاعده به نقش admin نیاز دارد. خواندن ماتریس چنین نیازی ندارد.
چک‌پوینت: در محدودهٔ فضای کاری، پوش به یک ریموت را روی رد بگذارید، سپس
کاوشگر «اگر…؟» زیر را روی git push origin main اجرا کنید. نتیجه deny را با
منبع workspace نشان می‌دهد.
درک اینکه یک تصمیم چگونه حل می‌شود
بخش با عنوان “درک اینکه یک تصمیم چگونه حل می‌شود”حل به این ترتیب است: نخست خاص‌بودن، سپس محدودکنندگی:
- قواعد فضا، سپس عامل، سپس فضای کاری. نخستین محدوده‌ای که قاعده‌ای منطبق دارد تصمیم می‌گیرد و حل در همان‌جا می‌ایستد
- اگر هیچ قاعده‌ای منطبق نشود، پیش‌تنظیم حالت اعمال می‌شود — یک حالت فقط‌خواندنی (plan، review، orchestrate) یازده کلاس از سیزده کلاس را رد می‌کند
- اگر حالت چیزی برای گفتن نداشته باشد، پیش‌فرض داخلی اعمال می‌شود
در یک محدودهٔ واحد، یک قاعدهٔ فرمان بر پایهٔ بلندترین پیشوند منطبق حل می‌شود و یک تعارض با همان اندازه خاص‌بودن، محدودکننده‌ترین را برمی‌گزیند — رد از ابتدا بپرس و ابتدا بپرس از اجازه قوی‌تر است. کنشی که چند کلاس اعلام می‌کند، هر یک را مستقل حل می‌کند و سپس آن‌ها را به محدودکننده‌ترین شکل ترکیب می‌کند.
تصمیم ابتدا بپرس یک پرامپت تأیید بالا می‌آورد که هر کلاسی را که به prompt
رسیده است پوشش می‌دهد. اگر تأییدکننده‌ای متصل نباشد، رد می‌شود — هم برای
فرمان‌های شل و هم برای فراخوانی‌های ابزار هارنس. این عمدی است: یک اجرای بدون
دروازه بدتر از یک اجرای ردشده است.
کلاس‌های کنش و پیش‌فرض‌های داخلی
بخش با عنوان “کلاس‌های کنش و پیش‌فرض‌های داخلی”| کلاس کنش | پیش‌فرض داخلی |
|---|---|
| حذف یک فایل | ابتدا بپرس |
| نوشتن بیرون از worktree | اجازه |
| ایجاد یک کامیت | اجازه |
| پوش به یک ریموت | ابتدا بپرس |
| باز کردن یک pull request | ابتدا بپرس |
| انتشار یک بازبینی یا ادغام | ابتدا بپرس |
| نوشتن در یک ردیاب خارجی | ابتدا بپرس |
| دسترسی به شبکه | اجازه |
| خواندن یک راز | اجازه |
| نصب یک بسته | اجازه |
| اجرای یک فرایند | اجازه |
| تغییر ساختار فضای کاری | اجازه |
| راندن یک محفظه (ریگ) | اجازه |
این طبقه‌بندی بسته است. یک ابزار تازه که بدون اعلام کلاس‌هایش عرضه شود، در CI در یک آزمون یک‌طرفهٔ سخت‌گیرانه شکست می‌خورد، پس هیچ ابزاری با مجموعهٔ اثرِ خالی و بی‌صدا از راه نمی‌رسد.
آزمودن یک قاعده با کاوشگر «اگر…؟»
بخش با عنوان “آزمودن یک قاعده با کاوشگر «اگر…؟»”پیش از تغییر یک قاعده، بررسی کنید که سیاست فعلی آن را چگونه حل می‌کند.
- در همان صفحه، تا اگر…؟ پایین بروید
- یک کنش انتخاب کنید (یکی از سیزده کلاس)
- به‌صورت اختیاری فرمان (برای نمونه
git push origin main)، عامل، فضا و حالت را پر کنید - نتیجه را بخوانید: تصمیم، دلیل و منبع:
کاوشگر همان حل‌کننده‌ای را اجرا می‌کند که مسیر اعمال استفاده می‌کند، در برابر قواعد زندهٔ شما، پس پاسخ دقیق است. اگر غافلگیرتان کرد، قاعده‌ای را در ماتریس بالا تغییر دهید و دوباره کاوش کنید.
تنظیم درجهٔ خودمختاری یک فضا
بخش با عنوان “تنظیم درجهٔ خودمختاری یک فضا”این درجه به‌ازای هر عامل در هر فضا تنظیم می‌شود و با قواعد ترکیب می‌شود، نه اینکه جای آن‌ها را بگیرد.
- فضا را باز کنید
- از سرصفحهٔ فضا، مدیریت مشارکت‌کنندگان را باز کنید
- زیر خودمختاری روی ردیف عامل، یک سطح انتخاب کنید:
| سطح | اثر |
|---|---|
| پیش‌فرض | بدون تنظیم فضا — مانند عمل با تأیید رفتار می‌کند |
| فقط پیشنهاد | هر ابزار دروازه‌دار یکسره رد می‌شود، با پیامی که به عامل می‌گوید به‌جایش کنش را پیشنهاد کند |
| عمل با تأیید | کنش‌های پرخطر به دروازهٔ تأییدِ رد‌پیش‌فرض می‌خورند |
| عمل آزاد | هر چیزی را که به یک رد سخت نرسیده باشد از پیش تأیید می‌کند |
این درجه فقط به هارنس داخلی می‌رسد. آداپتور Claude Code ابزارهای خودش را بیرون از این دروازه اجرا می‌کند.
بدانید گاردریل‌ها کجا نمی‌رسند
بخش با عنوان “بدانید گاردریل‌ها کجا نمی‌رسند”جدول کجا قواعد اعمال می‌شوند در پایین همان صفحه، نسخهٔ درون‌برنامه‌ای همین است: به‌ازای هر کلاس اثر، می‌گوید هر اجراکننده آن را در دروازهٔ سیاست می‌گیرد، به سندباکس واگذار می‌کند، یا اصلاً نمی‌تواند رهگیری‌اش کند.
- آداپتور Claude Code روی فراخوانی‌های ابزار خودش فقط تا حدی دروازه‌گذاری می‌شود.
Claude Code با
--dangerously-skip-permissionsاجرا می‌شود، پس فراخوانی‌های خواندن، نوشتن و ویرایش آن هرگز از نگهبان نمی‌گذرند. فرمان‌های bash آن از طریق هوکی که خط فرمان را دسته‌بندی می‌کند به نگهبان می‌رسند و پوش‌هایش مانند پوش‌های هر عاملی از دروازهٔ پوش می‌گذرند. سطح ابزار MCP که به آن بازمی‌گردد و فرمان شلی که Control Center برای اجرای آن می‌سازد هم دروازه‌گذاری می‌شوند. - فعل خروجی خودِ یک حالت (
submit_plan،propose_orchestration) سنجاق شده است و هرگز نمی‌تواند رد شود — در غیر این صورت یک حالت ساختاراً نمی‌تواند تنها تحویل‌دادنی‌اش را تولید کند. - اینکه سندباکس پشتیبان این قواعد باشد به میزبان بستگی دارد. جایی که
cc_serverبک‌اندی پیدا کند، CLI مربوط به Claude Code و ابزارbashهارنس را می‌پیچد، پس قاعده‌ای که شما ننوشته‌اید هم هنوز کف سیستم‌عاملی زیر خود دارد. روی ویندوز هیچ‌کدام نیست و روی Linux یا WSL2 بدونbwrapوsocatهم هیچ‌کدام نیست — آنجا گاردریل‌ها به‌علاوهٔ سطح ابزار حالت، تمام اعمال‌اند، نه خط دفاعی دوم آن. با پیکربندی سیاست‌های سندباکس بررسی کنید در کدام حالت قرار دارید.