תיעוד 62

הגדרת מצב אוטומטי

ספרו למסווג של מצב אוטומטי אילו מאגרי קוד, דליי אחסון ודומיינים הארגון שלכם סומך עליהם. הגדירו הקשר סביבה, דרוסו את כללי החסימה וההתרה שמוגדרים כברירת מחדל, ובדקו את התצורה האפקטיבית באמצעות פקודות המשנה של CLI של מצב אוטומטי.

מצב אוטומטי מאפשר ל-Claude Code לרוץ בלי בקשות הרשאה שגרתיות, על ידי ניתוב קריאות כלים דרך מסווג שחוסם כל דבר בלתי הפיך, הרסני, או שמכוון מחוץ לסביבה שלכם. כללי deny וכללי ask מפורשים מוערכים לפני המסווג, ועדיין חוסמים או מבקשים אישור. השתמשו בבלוק ההגדרות autoMode כדי לומר למסווג אילו מאגרי קוד, דליי אחסון ודומיינים הארגון שלכם סומך עליהם, כדי שיפסיק לחסום פעולות פנימיות שגרתיות.

הערה: מצב אוטומטי זמין לכל המשתמשים בכל ספק, כולל Anthropic API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, וסשנים מחוברים של Claude apps gateway. אם Claude Code מדווח שמצב אוטומטי אינו זמין לחשבון שלכם, בדקו את הדרישות המלאות, שכוללות גם את המודלים הנתמכים ואת הבקרה ברמת הארגון בתוכניות Team ו-Enterprise. בגרסאות v2.1.158 עד v2.1.206, מצב אוטומטי ב-Amazon Bedrock, ב-Google Cloud's Agent Platform, ב-Microsoft Foundry ובסשנים של Claude apps gateway דרש הגדרה של CLAUDE_CODE_ENABLE_AUTO_MODE=1. בגרסה v2.1.207 הדרישה הוסרה.

ברירת המחדל: המסווג סומך רק על ספריית העבודה ועל הרימוטים שהוגדרו למאגר הנוכחי. פעולות כמו דחיפה לארגון בקרת הגרסאות של החברה או כתיבה לדלי ענן של הצוות נחסמות עד שתוסיפו אותן ל-autoMode.environment.

למידע על איך סשנים נכנסים למצב אוטומטי ומה המסווג חוסם כברירת מחדל, ראו מצב אוטומטי בדף מצבי הרשאה. הדף הזה הוא מדריך התצורה.

הדף הזה מכסה איך:

להוסיף נקודת בדיקה אנושית לדחיפות ולבקשות משיכה עם permissions.ask
לבחור איפה להגדיר כללים ב-CLAUDE.md, בהגדרות משתמש ובהגדרות מנוהלות
להגדיר תשתית מהימנה עם autoMode.environment
לייצר רשומות סביבה עם /auto-mode-setup
לדרוס את כללי החסימה וההתרה כשברירות המחדל לא מתאימות לצינור שלכם
לערוך כללים מתוך /permissions בלי לפתוח קובץ הגדרות
לנתב את כל פקודות המעטפת דרך המסווג עם autoMode.classifyAllShell
לבדוק את התצורה האפקטיבית עם פקודות המשנה claude auto-mode
לסקור חסימות כדי לדעת מה להוסיף בהמשך

#גבולות נפוצים

מצב אוטומטי מתיר כברירת מחדל דחיפות לכל ענף במאגר שאתם עובדים בו, כולל ענף ברירת המחדל, וגם יצירת בקשת משיכה. ענף שאינו ענף ברירת המחדל, וששמו מסמן אותו כיעד פריסה או פרסום, למשל production, release או gh-pages, אינו כלול בברירת המחדל הזו: המסווג שופט דחיפה לשם לפי הקריטריונים שלו, כולל כפריסת ייצור. גם תוכן הדחיפה נבדק, ולכן דחיפה כפויה, סוד שנכנס ל-commit, או שינוי שישלח סודות מחוץ למאגר כש-CI או צינור פריסה מריצים אותו, נשארים חסומים.

מידע: לפני v2.1.211 המסווג התיר דחיפות רק לענף העבודה שלכם, לענפים ש-Claude יצר, ולדחיפות שגרתיות לענף ברירת המחדל.

אם אתם רוצים נקודת בדיקה אנושית לפני כל דחיפה או בקשת משיכה, הוסיפו כללי הרשאה: המתכונים למטה משאירים מצב אוטומטי פעיל לכל השאר.

#הוספת נקודת בדיקה אנושית {#add-a-human-checkpoint}

המנגנון הישיר ביותר הוא permissions.ask. כללי ask שמוגבלים לתוכן, כמו אלה למטה, מוערכים לפני המסווג ותמיד כופים בקשת הרשאה, גם במצב אוטומטי, כי כלל ask מפורש הוא הצהרת הכוונה שלכם להתבקש אישור לפעולה הזו. הוסיפו את הכללים בהגדרות שלכם:

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

בחרו את המנגנון שמתאים למידת הקשיחות שאתם צריכים לגבול:

גבול	מנגנון	התנהגות במצב אוטומטי
לבקש אישור לפני הפעולה	`permissions.ask`	תמיד מבקש אישור לכללים שמוגבלים לתוכן, כמו במתכון למעלה. המסווג לא יכול לאשר אוטומטית פעולה שמתאימה לכלל.
לא להריץ את הפעולה לעולם	`permissions.deny`	חוסם לפני שפונים למסווג. לא המסווג ולא כוונת המשתמש יכולים לדרוס את זה.
גבול חד פעמי לסשן הזה	לציין בשיחה, למשל "אל תדחוף עד שאני אבדוק"	המסווג חוסם פעולות מתאימות, אבל הגבול עלול להיעלם אם דחיסת הקשר מסירה את ההודעה שקבעה אותו. השתמשו בכלל `ask` או `deny` כדי לקבל הבטחה יציבה.

#איפה המסווג קורא תצורה {#where-the-classifier-reads-configuration}

המסווג קורא את אותו תוכן CLAUDE.md ש-Claude עצמו טוען, כך שהוראה כמו "לעולם לא לעשות דחיפה כפויה" ב-CLAUDE.md של הפרויקט מכוונת גם את Claude וגם את המסווג באותו זמן. התחילו משם עבור מוסכמות פרויקט וכללי התנהגות.

לכללים שחלים על פני פרויקטים, למשל תשתית מהימנה או כללי deny לכל הארגון, השתמשו בבלוק ההגדרות autoMode. המסווג קורא את autoMode מההיקפים הבאים:

היקף	קובץ	למה זה מיועד
מפתח אחד	`~/.claude/settings.json`	תשתית מהימנה אישית
לכל הארגון	הגדרות מנוהלות	תשתית מהימנה שמופצת לכל המפתחים
הדגל `--settings` או Agent SDK	JSON מוטמע	דריסות לפי הפעלה עבור אוטומציה

המסווג לא קורא autoMode מהגדרות פרויקט ב-.claude/settings.json או ב-.claude/settings.local.json. שני הקבצים נמצאים בספריית המאגר, כך שמאגר שנשמר ב-git או שלב בנייה היו יכולים אחרת להזריק כללי התרה משלהם. לפני v2.1.207 המסווג קרא גם את .claude/settings.local.json. העבירו כל בלוק autoMode שבקובץ הזה אל ~/.claude/settings.json. ההחרגה של .claude/settings.local.json סוגרת גם את המקרה שבו מאגר שומר את הקובץ ב-git, או שכלי מקומי או שלב בנייה כותבים אותו.

רשומות מכל היקף משולבות. מפתח יכול להרחיב את environment, allow, soft_deny ו-hard_deny ברשומות אישיות, אבל לא יכול להסיר רשומות שההגדרות המנוהלות מספקות. מכיוון שכללי allow פועלים כחריגים לכללי חסימה רכה בתוך המסווג, רשומת allow שמפתח הוסיף יכולה לדרוס רשומת soft_deny של הארגון: השילוב הוא תוספתי, ולא גבול מדיניות קשיח.

הערה: המסווג הוא שער שני שרץ אחרי מערכת ההרשאות. לפעולות שאסור שירוצו לעולם, בלי קשר לכוונת המשתמש או לתצורת המסווג, השתמשו ב-permissions.deny בהגדרות מנוהלות. זה חוסם את הפעולה לפני שפונים למסווג, ואי אפשר לדרוס את זה.

#הגדרת תשתית מהימנה {#define-trusted-infrastructure}

ברוב הארגונים, autoMode.environment הוא השדה היחיד שצריך להגדיר. הוא אומר למסווג אילו מאגרי קוד, דליי אחסון ודומיינים מהימנים: המסווג משתמש בזה כדי להחליט מה נחשב "חיצוני", כך שכל יעד שלא מופיע ברשימה הוא יעד אפשרי להוצאת מידע.

נכון ל-Claude Code v2.1.198, claude auto-mode defaults מדפיס שלושה סוגים של רשומת סביבה. גרסאות לפני v2.1.195 מדפיסות רק את חמשת חריצי האמון הראשונים.

חריצי הקשר: מתארים את הארגון, את המחסנית ואת עמדת האבטחה, כדי שהמסווג יקרא את שאר הכללים בהקשר שלכם. כל אחד מהם מוגדר כברירת מחדל ל-None configured, או להנחה השמרנית שרשומה לידו:
- Organization
- Primary use of Claude Code: ברירת המחדל היא פיתוח תוכנה
- Cloud provider(s)
- Repository visibility: מאגר נחשב פרטי אלא אם המארח והשם של הרימוט מעידים אחרת, או שבדיקת נראות מוקדם יותר בשיחה שהמסווג קורא מראה שהוא ציבורי. המסווג קורא את ההודעות שלכם ואת הפקודות ש-Claude מריץ, לא את הפלט שלהן, כך שהראיה צריכה להיות משהו שהוא יכול לקרוא, למשל הודעה שלכם שמציינת שהמאגר ציבורי. הפלט של gh repo view לבדו לא מגיע אליו. בדיקת הראיות מהתמלול דורשת Claude Code v2.1.200 ומעלה
- Internal sharing / snippet hosting: שירותי paste ו-gist ציבוריים נחשבים מחוץ לגבול האמון עד שתציינו אחד
- Org-specific CLIs
- Secrets management
- CI/CD deploy targets
- Network posture
- Host containment: ברירת המחדל היא מחשב מפתח רגיל או רץ CI עם אינטרנט פתוח. אם Claude Code רץ בקונטיינר, ב-VM או ב-pod עם רשימת יציאה מותרת, או עם שכנים שאסור לגעת בהם, ציינו את המארחים המותרים, האם נקודת הקצה של מטא-נתוני הענן צריכה להיות נגישה, ואיזה פרויקט ענן, אשכול או registry המשימה משתמשת בהם ותחת איזו זהות. עד שהרשומה הזו מציינת את הזהות הזו, המסווג חוסם בקשות לאישורים של המארח עצמו. דורש Claude Code v2.1.257 ומעלה
- Protected deployment namespaces / environments: חוזר להיוריסטיקה של Sensitive remote targets עד שתציינו אותם
- Data retention / declassification
חריצי אמון: מציינים מה המסווג מתייחס אליו כחלק מהגבול שלכם. החריצים הם Trusted repo, Source control, Trusted internal domains, Trusted cloud buckets, Key internal services, ו-Internal package registry. רשומות המאגר ובקרת הגרסאות מוגדרות כברירת מחדל למאגר העבודה ולרימוטים שהוגדרו לו. כל חריץ אמון אחר מוגדר כברירת מחדל ל-None configured, כך ששום דבר אחר אינו מהימן עד שתוסיפו אותו. נראות של מאגר מגבילה רק חומר סודי: מאגר פרטי הוא יעד מקובל לחומר סודי, אבל הפיכת מאגר לפרטי אף פעם לא מתירה להכניס אליו סודות או נתונים אישיים או נתונים שהופקדו בידיכם, והמסווג מתייחס לתוכן שהועתק, הופנה מחדש, או נקרא לראשונה מחוץ למאגר העבודה כאל תוכן שאינו העבודה של המאגר עצמו. ההגבלה הזו דורשת Claude Code v2.1.203 ומעלה.
חריצי רגישות: מציינים מה הכללים המגנים מתייחסים אליו כסיכון גבוה. החריצים הם Sensitive data locations & audiences, Sensitive remote targets, ו-Protected IaC scopes. כל אחד מהם מוגדר כברירת מחדל להיוריסטיקה רחבה, למשל להתייחס לכל מארח או מרחב שמות שנושא prod או production כיעד מרוחק רגיש, כך שהכללים המגנים פעילים עוד לפני שמגדירים משהו. ציון יעדים קונקרטיים בחריץ רגישות גורם לכללים האלה לחול על היעדים שצוינו, במקום על ההיוריסטיקה.

מידע: לפני v2.1.211 חריצי ההקשר כללו גם רשומת Default / protected branches, שהתייחסה אל main ואל master כאל ענפים מוגנים עד שציינתם אחרים. v2.1.211 הסירה אותה: דחיפות לכל ענף במאגר שאתם עובדים בו מותרות כברירת מחדל, כך שאין ברירת מחדל של ענף מוגן להגדיר.

כדי להוסיף רשומות משלכם לצד ברירות המחדל, כללו את המחרוזת המילולית "$defaults" במערך. רשומות ברירת המחדל משולבות באותו מיקום, כך שהרשומות המותאמות שלכם יכולות לבוא לפניהן או אחריהן.

הדוגמה הבאה שומרת את רשומות ברירת המחדל ומוסיפה מאגרי קוד, דליי אחסון, דומיינים ושירותים של הארגון.

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}

אחרי ששומרים את ההגדרות, הריצו claude auto-mode config כדי לאשר שהכללים האפקטיביים כוללים את הרשומות שלכם.

הרשומות הן פרוזה, לא ביטויי regex ולא תבניות כלים. המסווג קורא אותן ככללים בשפה טבעית. כתבו אותן באותו אופן שבו הייתם מתארים את התשתית למהנדס חדש. סעיף סביבה מקיף מכסה:

Organization: שם החברה ומה השימוש העיקרי ב-Claude Code, למשל פיתוח תוכנה, אוטומציית תשתית, או הנדסת נתונים
Source control: כל ארגון GitHub, GitLab או Bitbucket שהמפתחים שלכם דוחפים אליו
Cloud providers and trusted buckets: שמות דליים או קידומות ש-Claude אמור להיות מסוגל לקרוא מהם ולכתוב אליהם
Trusted internal domains: שמות מארחים ל-API, ללוחות בקרה ולשירותים בתוך הרשת שלכם, למשל *.internal.example.com
Key internal services: CI, רישומי ארטיפקטים, אינדקסי חבילות פנימיים, כלי תקריות
Internal package registry: ה-npm, PyPI או registry פרטי אחר שדרך התקנות צריכות לעבור, כדי שהתקנות שעוקפות אותו לטובת registry ציבורי ייחסמו
Sensitive data locations & audiences: הדליים, מסדי הנתונים או הנתיבים שמחזיקים נתונים אישיים, נתונים עסקיים סודיים, אישורים, נתונים מוסדרים, או חומר רגיש דומה, והקהלים שאפשר לשתף איתם את הנתונים בכל מיקום, כדי שהמסווג יגן על המיקומים האלה במקום לנחש לפי התוכן. Claude Code v2.1.195 עד v2.1.197 קוראים לרשומה הזו PII / regulated-data locations, ומכסים רק מיקומים שמחזיקים נתונים אישיים או מוסדרים, בלי ממד הקהל
Sensitive remote targets: מרחבי השמות, המארחים או הקונטיינרים שנחשבים ייצור, כך שמעטפות מרוחקות והעברות פורטים אליהם דורשות אישור מפורש שלכם
Protected IaC scopes: משאבי התשתית ש-apply או destroy שלהם צריכים תמיד לדרוש שתציינו את השינוי
Additional context: מגבלות של תעשייה מוסדרת, תשתית מרובת דיירים, או דרישות ציות שמשפיעות על מה שהמסווג צריך להתייחס אליו כמסוכן

הרשומות Internal package registry, Sensitive data locations & audiences, Sensitive remote targets ו-Protected IaC scopes דורשות Claude Code v2.1.195 ומעלה. גרסאות מוקדמות יותר עדיין קוראות אותן כהקשר רגיל, אבל אין להן את הכללים המובנים שמכוונים אליהן.

תבנית התחלה שימושית: מלאו את השדות שבסוגריים מרובעים, והסירו שורות שלא רלוונטיות.

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}

ככל שההקשר שאתם נותנים ספציפי יותר, כך המסווג יכול להבדיל טוב יותר בין פעולות פנימיות שגרתיות לבין ניסיונות להוציא מידע החוצה.

אין צורך למלא הכול בבת אחת. הטמעה סבירה: התחילו עם ברירות המחדל והוסיפו את ארגון בקרת הגרסאות ואת השירותים הפנימיים המרכזיים, וזה פותר את חסימות השווא הנפוצות ביותר, כמו דחיפה למאגרים שלכם. אחר כך הוסיפו דומיינים מהימנים ודליי ענן. מלאו את השאר כשעולות חסימות.

#יצירת רשומות סביבה עם `/auto-mode-setup` {#generate-environment-entries}

הריצו /auto-mode-setup כדי ש-Claude Code ינסח טיוטה של רשומות autoMode.environment, ולפעמים גם רשומות כללים, מתוך הפרויקט ומתוך הסשנים האחרונים שלכם בו. אם אתם מאשרים את הטיוטה, Claude Code כותב אותה אל ~/.claude/settings.json.

הערה: /auto-mode-setup דורש תוכנית Pro, Max או Team, ו-Claude Code v2.1.228 ומעלה. ב-Windows מקורי זה דורש v2.1.233 ומעלה. אי אפשר להריץ את זה ב-Claude Code on the web. בנוסף נדרשת שליפת דגלי תכונות, כך שאי אפשר להריץ את זה בסשן שבו כיביתם שליפת דגלים.

#מה `/auto-mode-setup` קורא {#what-auto-mode-setup-reads}

אם ~/.claude/settings.json כבר מכיל רשומות autoMode, Claude Code מתחיל בשאלה אם להוסיף לרשימת הסביבה או להחליף אותה, ושומר בכל מקרה את הכללים שכתבתם. אחר כך Claude Code שואל איך אתם משתמשים בפרויקט הזה, ומציע שתי סריקות אופציונליות לפני שהוא סורק משהו. בסריקה, Claude Code תמיד קורא את המקורות האלה:

את CLAUDE.md, README.md, קובצי התצורה והרימוטים של git של הפרויקט הזה
את הגדרות autoMode ו-permissions.allow שלכם
את המארחים, הדליים ושמות הפקודות מתוך הפקודות ש-Claude הרץ בסשנים האחרונים שלכם בפרויקט הזה, אף פעם לא את ההודעות שלכם

שתי הסריקות האופציונליות מוסיפות מקור אחד כל אחת:

המילה הראשונה של כל פקודה בהיסטוריית המעטפת שלכם
המארחים המרוחקים והשמות של המאגרים תחת ספריית הבית שלכם

#סקירה ושמירה של הטיוטה

Claude Code סורק ברקע, ואז מציג לכם את הטיוטה. אתם מאשרים או דוחים אותה בשלמותה, לכן ערכו את ~/.claude/settings.json אחר כך כדי לכוון רשומות בודדות. כשאתם מאשרים, Claude Code כותב את הטיוטה ומיישב אותה עם ההגדרות שכבר יש לכם:

Claude Code כותב את רשימת environment בלי "$defaults", כי הטיוטה מפרטת את הרשומות המובנות שהוא השאיר בלי שינוי
Claude Code כולל "$defaults" בכל אחת מרשימות allow, soft_deny ו-hard_deny שהטיוטה מוסיפה אליהן רשומות, אלא אם כבר כתבתם רשימת allow בלי זה, כדי שהכללים המובנים שלא החלפתם יישארו בתוקף
אחרי השמירה, Claude Code מציע להסיר מ-~/.claude/settings.json כללי permissions.allow שמצב אוטומטי מתעלם מהם, למשל Bash(*), או שמאשרים אוטומטית פקודות הרסניות

אחר כך הריצו claude auto-mode config כדי לראות את התוצאה האפקטיבית.

#כיבוי `/auto-mode-setup` {#turn-off-auto-mode-setup}

אחרי שמצב אוטומטי חסם כמה פעולות ועדיין אין לכם רשומות autoMode.environment, Claude Code מציג בסוף תור דיאלוג בשם "Teach auto mode about your environment?" ומציע להריץ /auto-mode-setup בשבילכם. כדי להפסיק את ההצעה אבל להשאיר את הפקודה, בחרו Don't show again בדיאלוג הזה.

כדי לכבות גם את הפקודה וגם את ההצעה, הוסיפו את רשומת skillOverrides הזו אל ~/.claude/settings.json:

{
  "skillOverrides": {
    "auto-mode-setup": "off"
  }
}

/auto-mode-setup היא פקודה מובנית ולא skill כלול, ולכן רשומת skillOverrides הזו עדיין חלה עליה, אבל disableBundledSkills לא מכבה אותה.

#דריסת כללי החסימה וההתרה {#override-the-block-and-allow-rules}

שלושה שדות נוספים מאפשרים לכם להחליף את רשימות הכללים המובנות של המסווג:

autoMode.hard_deny: גבולות אבטחה ללא תנאי
autoMode.soft_deny: פעולות הרסניות שכוונת המשתמש יכולה לשחרר
autoMode.allow: חריגים לכללי חסימה רכה

כל אחד מהם הוא מערך של תיאורים בפרוזה, שנקראים ככללים בשפה טבעית. לחסימות קשיחות שמבוססות על תבניות כלים ורצות לפני המסווג, השתמשו ב-permissions.deny.

בתוך המסווג, סדר העדיפות עובד בארבע רמות:

כללי hard_deny חוסמים ללא תנאי. כוונת המשתמש וחריגי allow לא חלים.
כללי soft_deny חוסמים אחר כך. כוונת המשתמש וחריגי allow יכולים לדרוס אותם.
כללי allow דורסים אחר כך כללי soft_deny מתאימים, כחריגים.
כוונת משתמש מפורשת דורסת את שאר החסימות הרכות: אם ההודעה של המשתמש מתארת באופן ישיר ומדויק את הפעולה המדויקת ש-Claude עומד לבצע, המסווג מתיר אותה גם כשכלל soft_deny מתאים.

בקשות כלליות לא נחשבות לכוונה מפורשת. לבקש מ-Claude "לנקות את המאגר" לא מאשר דחיפה כפויה, אבל לבקש מ-Claude "לעשות דחיפה כפויה לענף הזה" כן.

כדי להרפות, הוסיפו ל-allow כשהמסווג מסמן שוב ושוב דפוס שגרתי שחריגי ברירת המחדל לא מכסים. כדי להחמיר, הוסיפו ל-soft_deny סיכונים הרסניים שספציפיים לסביבה שלכם ושברירות המחדל מפספסות, או ל-hard_deny לגבולות אבטחה שאסור לחצות לעולם.

כדי לשמור על הכללים המובנים תוך הוספת כללים משלכם, כללו את המחרוזת המילולית "$defaults" במערך. כללי ברירת המחדל משולבים באותו מיקום, כך שהכללים המותאמים שלכם יכולים לבוא לפניהם או אחריהם, ואתם ממשיכים לקבל עדכונים כשהרשימה המובנית משתנה בין גרסאות.

הדוגמה הבאה שומרת את ברירות המחדל בכל ארבע הרשימות, ומוסיפה לכל אחת כללים ספציפיים לארגון.

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "$defaults",
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

זהירות: הגדרה של אחד מבין environment, allow, soft_deny או hard_deny בלי "$defaults" מחליפה את כל רשימת ברירת המחדל של אותו סעיף. אם מגדירים מערך בלי "$defaults", זורקים את הכללים המובנים של אותו סעיף:

soft_deny: כל כלל חסימה רכה מובנה, כולל דחיפה כפויה, curl | bash, פריסות ייצור, ועקיפת מצב אוטומטי

hard_deny: כלל הוצאת המידע המובנה

כל סעיף מוערך בנפרד.