🔒 פרק 7

הרשאות, אבטחה וסביבת ריצה

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

מצב הרשאה קובע אילו פעולות קלוד יכול לבצע בסשן בלי לשאול אותך קודם. מחליפים מצב עם Shift+Tab ב-CLI, עם מחוון המצב בהרחבת VS Code, או עם בורר המצב באפליקציית Desktop.

כאשר קלוד קוד פועל אצלך, הוא קורא קבצים, מריץ פקודות מעטפת ויכול לגשת לרשת. במצב Manual, קלוד קוד עוצר ושואל לפני רוב הפעולות שעורכות קבצים, מריצות פקודות מעטפת או ניגשות לרשת. במצב auto, מודל שני, המסווג (classifier), בודק את הפעולות במקומך. איך המסווג מעריך פעולות מפרט אילו פעולות הוא בודק ואילו מדלגות עליו.

החל מקלוד קוד v2.1.283, מצב auto הוא מצב הפתיחה המובנה לסשנים אינטראקטיביים בטרמינל ובהרחבת VS Code, בכל תוכנית ואצל כל ספק. בגרסאות מוקדמות יותר זה מצב הפתיחה המובנה רק בתוכניות Pro, Max ו-Team. הסעיף על מצב הפתיחה מפרט את המשטחים וההגדרות שמשנים את המצב שבו סשן נפתח. באפשרותך לשנות את מצב ההרשאה של סשן פעיל בכל עת.

מצב ההרשאה הוא קו הבסיס. מעל המצב אפשר להוסיף כללי הרשאה כדי לאשר מראש או לחסום כלים ספציפיים. כללי deny חוסמים בכל מצב, כולל במצב bypassPermissions. כללי allow אינם משפיעים במצב bypassPermissions. כללי deny ו-ask אינם חלים על EndConversation כל עוד נותר לקלוד כלי אחר לקרוא לו.

הכללים נבדקים בסדר קבוע: קודם deny, אחר כך ask, אחר כך allow. ההתאמה הראשונה מנצחת, ורוחב הכלל אינו משנה את הסדר. כלל deny רחב כמו Bash(aws *) חוסם כל קריאה תואמת, כולל קריאה שמתאימה גם לכלל allow צר יותר כמו Bash(aws s3 ls). כלל allow אינו יוצר חריג מתוך כלל deny. אותו סדר חל גם בין ask ל-allow: כלל ask תואם מציג בקשת אישור גם כשכלל allow ספציפי יותר מתאים לאותה קריאה.

כלל deny על שם כלי בלבד, כמו Bash, מסיר את הכלי לגמרי מההקשר של קלוד, וקלוד אינו רואה אותו. אם מוסיפים כלל כזה באמצע סשן, קלוד אינו יכול לקרוא לכלי החל מקריאת הכלי הבאה. כלל עם תחום, כמו Bash(rm *), משאיר את הכלי זמין וחוסם קריאות תואמות כשקלוד מנסה אותן. הסרה לפי שם בלבד חלה על כל כלי מלבד EndConversation.

ההרשאות נאכפות על ידי קלוד קוד, לא על ידי המודל. הוראות ב-CLAUDE.md או בפרומפט משפיעות על מה שקלוד מנסה לעשות. כדי להעניק או לבטל גישה השתמשו ב-/permissions, בכללים המתוארים כאן, במצב הרשאה, או ב-hook מסוג PreToolUse.

כתיבה לנתיבים מוגנים כמו .git ו-.claude אינה מאושרת אוטומטית, חוץ מבמצב bypassPermissions ובסשני plan שבהם הרשאות bypass זמינות: סשנים שהופעלו בטרמינל אינטראקטיבי באופן שמכניס את bypassPermissions למחזור המצבים. במצב bypassPermissions קלוד קוד מדלג על בקשות אישור, כולל כתיבה לנתיבים האלה. אמצעי ההגנה על הודעות בין סשנים ממשיכים לחול. השתמשו במצב זה רק בסביבות מבודדות כמו מכולות, מכונות וירטואליות, או dev containers בלי גישה לאינטרנט, שבהם קלוד קוד אינו יכול לפגוע במערכת המארחת. רשימת הנתיבים והתוצאה בכל מצב מופיעות בסעיף נתיבים מוגנים.

#פעולות שאף מצב אינו מאשר אוטומטית

קלוד קוד אינו מאשר אוטומטית את הפעולות הבאות באף מצב, כולל במצב bypassPermissions:

• כלים שמתאימים לכלל ask מפורש.
• כלי מחברים (connectors) שהארגון הגדיר למצב ask, בסשנים שבהם ההגדרה מגיעה לקלוד קוד.
• כלים הדורשים אינטראקציה עם המשתמש: הכלי המובנה AskUserQuestion, וכלי MCP המסומנים ב-requiresUserInteraction.
• מחיקות rm ו-rmdir המכוונות לנתיב קריטי, ופקודות Bash שסומנו Dangerous rm operation not ruled out, שאף כלל allow או hook מסוג PreToolUse עם "allow" אינם מאשרים.
• אמצעי ההגנה על הודעות בין סשנים (cross-session messaging).
• קריאות מחוץ לספריות העבודה כאשר ההגדרה permissions.blockReadsOutsideWorkingDirectories מופעלת: פקודות Bash מוכרות לקריאת קבצים מציגות בקשת אישור גם במצב auto וגם במצב bypassPermissions, וכך גם כל ניסיון ריצה חוזר מחוץ ל-sandbox שדורש אישור כדי לרוץ מחוץ ל-sandbox. דורש קלוד קוד v2.1.257 ומעלה. פקודה שמנתח המעטפת אינו יכול לעקוב אחריה, למשל פקודה שמשנה ספרייה יותר מפעם אחת או מריצה תת מעטפת (subshell), מציגה בקשת אישור באותו אופן גם כשהיא אינה מציינת נתיב חיצוני. בקשת האישור הזו אינה חלה כאשר הפקודה רצה בתוך ה-sandbox וה-sandbox אוכף את החסימה.

#מצבי הרשאות זמינים

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

המצב שבודק כל פעולה נקרא Manual ב-CLI, ב-claude --help, בהרחבות VS Code ו-JetBrains, ובאפליקציית Desktop. ערך ההגדרה שלו הוא default, וזה הערך שבו משתמשים ב-hooks ובאינטגרציות SDK. ה-CLI מקבל את הכינוי manual בכל מקום שבו מקלידים את הערך, למשל claude --permission-mode manual או "defaultMode": "manual".

כדי להסיר את מצב auto כך שאי אפשר לבחור אותו, קובעים את permissions.disableAutoMode לערך "disable". כדי למנוע שימוש במצב bypassPermissions, קובעים את permissions.disableBypassPermissionsMode לערך "disable". את שני המפתחות אפשר לקבוע בכל קובץ הגדרות. הם שימושיים במיוחד בהגדרות מנוהלות, שם אי אפשר לדרוס אותם. disableBypassPermissionsMode פועל מכל היקף, ומשתמש יכול לקבוע אותו בהגדרות שלו ולנעול את עצמו מחוץ למצב.

במצב dontAsk נדחים גם AskUserQuestion, כלי MCP עם requiresUserInteraction (דורש v2.1.199 ומעלה), וכלי מחברים שהארגון הגדיר ל-ask, גם אם כלל allow מתאים להם. הסימון הרשמי לכלי MCP כזה הוא _meta["anthropic/requiresUserInteraction"]: כרטיס האישור דורש תשובה, והמצב אינו אוסף אותה. מחיקת נתיב קריטי ב-rm או rmdir נדחית גם כשכלל allow או hook עם "allow" מתאימים. קריאה מנתיב רשת נדחית באותו אופן. קריאות ש-hook מסוג PreToolUse מאשר עדיין רצות, יחד עם פעולות שאינן דורשות אישור במצב Manual, כולל פקודות Bash לקריאה בלבד, ועם כלים שכלל permissions.allow מאשר. שורת המצב מציגה ⏵⏵ don't ask on. הסשן אינו ממתין לקלט. סשנים בענן מתעלמים מ-defaultMode: "dontAsk".

פותחים במצב dontAsk כך:

claude --permission-mode dontAsk

#אישור עריכות במצב acceptEdits

במצב acceptEdits קלוד יוצר ועורך קבצים בספריית העבודה בלי בקשה. שורת המצב מציגה ⏵⏵ accept edits on. בנוסף לעריכות, מאושרות אוטומטית פקודות Bash נפוצות: mkdir, touch, rm, rmdir, mv, cp, ו-sed. חוץ מ-touch, אותו אישור חל גם כשלפניהן משתני סביבה בטוחים כמו LANG=C או NO_COLOR=1, או עטיפות תהליך כמו timeout, nice, או nohup. האישור חל רק על נתיבים בתוך ספריית העבודה או additionalDirectories, ואחרי בדיקת symlink. נתיב מחוץ לתחום, כתיבה לנתיב מוגן, rm ו-rmdir לנתיב קריטי, touch עם משהו מעבר לנתיב קובץ פשוט (אפשרות, glob, או קידומת כמו timeout 5 או LANG=C), ושאר פקודות Bash מלבד קבוצת הקריאה המובנית, עדיין מבקשים אישור.

כשכלי PowerShell מופעל, מאושרים גם Set-Content, Add-Content, Clear-Content, ו-Remove-Item על נתיבים בתחום, יחד עם כינויים נפוצים. אותם כללי תחום ונתיב מוגן חלים, ול-Remove-Item יש בדיקה נפרדת. ארגומנט מיקומי שמכיל מרכאה, למשל הגרש ב-Set-Content .\notes.txt "It's done", עדיין מבקש אישור גם בנתיב בתחום, כי אי אפשר לאמת סטטית ארגומנט שהקריאה המצוטטת והלא מצוטטת שלו שונות. מעבירים את התוכן בפרמטר מפורש כמו -Value.

נכנסים ממצב Manual בלחיצת Shift+Tab אחת, או פותחים עם:

claude --permission-mode acceptEdits

המצב מתאים כשסוקרים את השינויים אחר כך בעורך או ב-git diff, בלי לאשר כל עריכה בתוך השיחה.

#תכנון לפני עריכה

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

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

1. סשן טרמינל אינטראקטיבי עם הרשאות bypass זמינות: לא המסווג ולא בקשת אישור חלים על פקודות התכנון. כללי ask מפורשים, ומחיקות rm ו-rmdir לנתיב קריטי, עדיין מבקשים אישור.
2. מצב auto זמין ו-useAutoModeDuringPlan פועל, וזו ברירת המחדל: המסווג בודק פקודות מעטפת שאינן מחיקת נתיב קריטי, במקום לבקש ממך. פקודה שאושרה רצה, ופקודה שנדחתה נחסמת. ערך false מכובד מכל מקור מנוהל, מ---settings, מ-~/.claude/settings.json, או מ-.claude/settings.local.json, גם כשהמקור המנוהל המנצח קובע true. ערך false בקובץ הפרויקט המשותף .claude/settings.json אינו נכנס לתוקף.
3. מצב auto אינו זמין, או שההגדרה כבויה: פקודות מחוץ לקבוצת הקריאה המובנית מבקשות אישור, גם כשמצב auto-allow של ה-sandbox פועל.

נכנסים עם Shift+Tab, עם קידומת /plan לפרומפט בודד, או עם claude --permission-mode plan. לחיצת Shift+Tab נוספת יוצאת בלי לאשר תוכנית.

כשהתוכנית מוכנה אפשר לבחור:

• Yes, and use auto mode: אישור ומעבר למצב auto. אם המצב אינו זמין לסשן, למשל כי הארגון כיבה אותו, האפשרות נקראת Yes, auto-accept edits. אם הסשן נפתח עם הרשאות bypass, האפשרות נקראת Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session.
• Yes, manually approve edits: אישור, וכל עריכה נבדקת בנפרד.
• No, keep planning: נשארים במצב plan.

אישור תוכנית יוצא ממצב plan ועובר למצב שכל אפשרות מתארת. כדי לתכנן שוב חוזרים עם Shift+Tab, או מוסיפים /plan לפרומפט הבא. Ctrl+G פותח את התוכנית בעורך ברירת המחדל לפני שקלוד ממשיך. כש-showClearContextOnPlanAccept פועל, נוסף בראש הרשימה אישור שמנקה את הקשר התכנון. קבלת תוכנית גם נותנת לסשן כותרת שנוצרה מהתוכנית, אלא אם כבר נתתם שם.

כדי שמצב plan יהיה ברירת המחדל לסשני טרמינל של פרויקט, קובעים defaultMode ל-plan ב-.claude/settings.json. שיחות שהרחבת VS Code פותחת אינן קוראות את הגדרות הפרויקט עבור מצב הפתיחה. שם קובעים claudeCode.initialPermissionMode ל-plan בהגדרות המשתמש של VS Code.

#זמינות מצב auto

מצב auto מריץ בלי בקשות שגרתיות. מסווג נפרד בודק פעולות לפני שהן רצות, וחוסם מה שחורג מהבקשה, מכוון לתשתית לא מוכרת, או נראה מונע מתוכן עוין שקלוד קרא. כלל ask מפורש עדיין כופה בקשה. עם קלוד קוד v2.1.283 ומעלה, מצב auto הוא מצב הפתיחה המובנה לסשן טרמינל אינטראקטיבי ולהרחבת VS Code, בכל תוכנית ואצל כל ספק. בגרסאות מוקדמות יותר זה מצב הפתיחה המובנה רק בתוכניות Pro, Max ו-Team. המסווג גם בודק כל הודעה שקלוד שולח לסוכן אחר עם SendMessage, טקסט רגיל או הודעת צוות סוכנים, לפני המסירה, גם במצב auto וגם במצב plan כשהמסווג בודק פקודות. בדיקת השליחה דורשת v2.1.222 ומעלה.

כברירת מחדל המסווג אינו בודק מחיקות rm ו-rmdir לנתיב קריטי כמו rm -rf / או rm -rf ~. מה שקורה להן מופיע בסעיף נתיבים קריטיים.

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

המצב זמין רק כשכל אלה מתקיימים:

• תוכנית: כל התוכניות.
• ארגון: ב-Team וב-Enterprise המצב זמין כברירת מחדל. מנהלים יכולים לכבות אותו עם permissions.disableAutoMode בערך "disable" בהגדרות מנוהלות.
• מודל: ב-Anthropic API וב-Claude Platform on AWS: Claude Opus 4.6 ומעלה, Sonnet 4.6 ומעלה, Haiku 5.5, או מודל Fable. ב-Amazon Bedrock, ב-Agent Platform של Google Cloud, ב-Microsoft Foundry, ובסשני Claude apps gateway מחוברים: רק Claude Sonnet 5 ומעלה, Opus 4.7 ומעלה, Haiku 5.5, ומודלי Fable. מודלים ישנים יותר, כולל Sonnet 4.5, Opus 4.5, Haiku 4.5, ומודלי claude-3, אינם נתמכים אצל אף ספק.
• ספק: זמין כברירת מחדל ב-Anthropic API, ב-Claude Platform on AWS, ב-Amazon Bedrock, ב-Agent Platform של Google Cloud, ב-Microsoft Foundry, ובסשני Claude apps gateway מחוברים.

אם קלוד קוד מדווח שהמצב אינו זמין, בודקים את הדרישות האלה ואם קובץ הגדרות קובע disableAutoMode. Anthropic יכולה גם לכבות את המצב זמנית בצד השרת, או שהשרת דחה אותו לחשבון. סשן שקיבל אחת מהתשובות האלה משאיר את המצב כבוי עד שהסשן נגמר.

הודעה נפרדת שמציינת מודל ואומרת שמצב auto אינו יכול לקבוע את הבטיחות של פעולה פירושה שבקשת מסווג נכשלה. זה בדרך כלל חולף, אבל ב-Amazon Bedrock זה יכול לחזור עד שהחשבון יכול להפעיל את המודל שצוין.

אם defaultMode: "auto" בקובץ הגדרות וסשן טרמינל נפתח במצב Manual בלי שגיאה, הערך כנראה ב-.claude/settings.json או ב-.claude/settings.local.json. משם "auto" אינו נכנס לתוקף. מעבירים אותו אל ~/.claude/settings.json. לשיחה שהרחבת VS Code פתחה, בודקים את רשימת ההרחבה בסעיף החלפת מצב.

אצל Bedrock, Agent Platform, Foundry, וסשני Claude apps gateway מחוברים, המצב זמין כברירת מחדל. עם v2.1.283 ומעלה הוא גם מצב הפתיחה המובנה לסשן טרמינל אינטראקטיבי ולהרחבת VS Code, בגרסאות שהטבלה בסעיף מצב הפתיחה מפרטת. רק Sonnet 5 ומעלה, Opus 4.7 ומעלה, Haiku 5.5, ומודלי Fable נתמכים שם. במודל אחר הסשן נפתח במצב Manual. מצב auto עם Haiku 5.5 אצל הספקים האלה דורש קלוד קוד v2.1.293 ומעלה.

disableAutoMode בערך "disable" בהגדרות מנוהלות מסיר את auto ממחזור Shift+Tab, וסשן שנפתח עם --permission-mode auto נפתח במצב Manual. סשן שכבר רץ במצב auto יוצא ממנו כשההגדרה מגיעה ממקור שמנהל פרס, ומציג auto mode disabled by settings. לפני v2.1.251 סשן רץ שמר את המצב עד שנתיים. מגרסה v2.1.158 עד v2.1.206 המצב היה כבוי אצל הספקים האלה עד CLAUDE_CODE_ENABLE_AUTO_MODE=1, וקלוד קוד התעלם מ-defaultMode: "auto" אלא אם המשתנה גם הוגדר. המשתנה עדיין מתקבל לתאימות ואין לו השפעה מגרסה v2.1.207.

#בדיקת מסווג בצד השרת

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

• חיבור ישיר ל-Anthropic API: בסשן טרמינל אינטראקטיבי, וגם בסשני -p, Agent SDK, הרחבת VS Code ואפליקציית Desktop, בכל תוכנית ובכל סוג חשבון, כש-Anthropic מפיצה את זה. בטרמינל אינטראקטיבי נדרש v2.1.271 ומעלה ב-Pro, Max ו-Team, ו-v2.1.278 ומעלה ב-Enterprise ובחשבונות Claude API. בסשני -p, Agent SDK, הרחבת VS Code ו-Desktop נדרש v2.1.281 ומעלה. מגרסה v2.1.282, סשן שאינו שולף דגלי תכונות, למשל כי טלמטריה כבויה, מבקש מהשרת כברירת מחדל בכל סוג סשן.
• ספק ענן, או שער או פרוקסי LLM: ב-Claude Platform on AWS, ב-Amazon Bedrock, ב-Agent Platform של Google Cloud, וב-Microsoft Foundry, וגם כש-ANTHROPIC_BASE_URL מצביע לשער או לפרוקסי, בכל תוכנית. בקשה כברירת מחדל דורשת v2.1.278 ומעלה.
• סשן Claude apps gateway מחובר: דורש v2.1.280 ומעלה.
• סשן ענן בסביבה ש-Anthropic מארחת: בכל תוכנית, כשמתחילים אותו מהאינטרנט, מהאפליקציה בנייד, או מאפליקציית Desktop כשנבחר Cloud. סשן שמשימה מתוזמנת בענן מתחילה מבקש מהשרת כש-Anthropic מפיצה את זה.

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

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

כדי לדלג על השרת ולהשתמש תמיד בבקשות המסווג של קלוד קוד, קובעים CLAUDE_CODE_AUTO_MODE_SERVER=0. בחיבור ישיר ל-Anthropic API המשתנה דורש v2.1.281 ומעלה. שם, ערך 1 מפעיל בדיקת שרת בסשן שעדיין אין לו אותה, אלא אם הוגדר גם CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1. אם המשתנה הזה מוגדר ו-CLAUDE_CODE_AUTO_MODE_SERVER לא הוגדר, קלוד קוד גם מפסיק לבקש מהשרת, חוץ מהמקרים שמתוארים בכיבוי יכולות טרום הפצה.

#מה המסווג חוסם ומה מותר

המסווג סומך על ספריית העבודה ועל ה-remotes שהיו מוגדרים לה כשהסשן התחיל. remote שנוסף או שהופנה מחדש במהלך הסשן עם git remote add או git remote set-url אינו מהימן. לפני v2.1.200 גם remote שנוסף באמצע סשן היה מהימן. כל השאר נחשב חיצוני עד שמגדירים תשתית מהימנה ב-autoMode.environment.

בין החסימות כברירת מחדל: הורדה והרצה של קוד כמו curl | bash, שליחת נתונים רגישים החוצה, פריסות ייצור ומיגרציות, מחיקה המונית באחסון ענן, הענקת הרשאות IAM או מאגר, שינוי תשתית משותפת, השמדה בלתי הפיכה של קבצים שהיו לפני הסשן, force push, קומיט או push שישלחו סודות או נתונים רגישים אל מחוץ למאגר כשהשינוי רץ, או ירחיבו מה שפריסה חושפת. זה כולל workflow של CI או הגדרת פריסה שמעבירים סוד ליעד שעדיין אינו מקבל אותו, סקריפט או שלב התקנה שקוראים ממחסן סודות ושולחים את הנתונים החוצה, ושינוי הגדרה שמרחיב מה שפריסה מפרסמת, כמו registry, visibility, artifact, או sourcemap. הבדיקה חלה על כל ענף, גם כשהמאגר ציבורי, ומופעלת בקומיט או ב-push בין שהם מפעילים את הצינור ובין שלא. כדי לנקות אותה צריך לנקוב באפקט ההרצה, לא רק בקומיט או ב-push. לפני v2.1.211 הבדיקה הזו הייתה מוגבלת לענף ברירת המחדל: דחיפה לשם נחסמה כשנשאה תוכן רגיש, שינויים שהוסתרו או תוארו לא נכון ביחס למה שביקשתם, תוכן שהובא מחוץ למאגר, או עקיפה של סקירה שביקשתם.

עוד חסימות: git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, ו-git stash clear, שהמסווג מניח שיזרקו עבודה שלא נשמרה, git commit --amend כשהקומיט ב-HEAD לא נוצר בסשן, וגם כשהקומיט כבר נדחף (מגרסה v2.1.198, חוץ מניסוח מחדש של ההודעה בלבד: --amend -m בלי דבר חדש ב-stage, על קומיט שקלוד יצר בסשן), terraform destroy, pulumi destroy, cdk destroy, terragrunt destroy, והחלת תוכנית שמשמידה משאבים, כתיבה למנהל סודות או שינוי DNS או אישורי TLS, מיזוג בקשת משיכה שאף אדם לא אישר, אישור בקשת המשיכה של קלוד עצמו, כיבוי בדיקות CI, תגובה שהיא פקודה לאוטומציה, כמו atlantis apply או /deploy ו-/merge של בוט, הפעלה, העלאה הדרגתית או מחיקה של דגל תכונה בייצור, החלת שינויי תשתית בהיקף IaC מוגן, או ריקון והסרת צמתי אשכול, כתיבה לאשכול חישוב משותף מעבר למשאב שצוין, כמו בורר תוויות או --all שתופס עבודות של משתמשים אחרים, יצירת משאבי Kubernetes שרצים על כל צומת או מיירטים תעבורת אשכול, כמו DaemonSet ו-admission webhook, מעטפת אינטראקטיבית או port-forward ליעד מרוחק רגיש, מנהרה או reverse shell שהופכים שירות מקומי נגיש מהאינטרנט הציבורי, הדפסת אישור חי לתמליל או לקובץ, גישה למיקום נתונים רגיש בסביבה, העתקת נתונים ממנו, או שליחה ממנו לקהל שהרשומה מוציאה, עקיפת מרשם חבילות פנימי כשהמרשם או מראה רשומים ב-environment או כשאמרתם לקלוד בשיחה שהוא קיים, דגל שמנטרל הגנה כמו --insecure, לולאת סוכן אוטונומית בלי אישור אנושי או sandbox, כולל כזו שהופעלה עם --dangerously-skip-permissions או --no-sandbox, וגם סוכן צד שלישי או eval harness עם --yes-always, ופעולות דפדפן של Claude in Chrome שעלולות לשלוח תוכן דף, עוגיות או אישורים אל מחוץ למקור.

מגרסאות מאוחרות נוספות חסימות, בין היתר מחיקת קבצים ב-/tmp, ב-$TMPDIR, או בתיקיית scratch או מטמון משותפת לפי wildcard, glob או מסנן גיל, ולא לפי נתיב מפורש, פרטים רגישים בתוכן יוצא, שליחת הקשות למקטע tmux של קלוד קוד עצמו כדי להפעיל את הממשק שלו (המסווג מתייחס לזה כשינוי ההרשאות או הפיקוח של קלוד על עצמו), הערה שמכבה, מחיקה, או העברה כפויה של בדיקה או assertion שמגנים על התנהגות אבטחה, כמו אימות, בקרת גישה, אימות קלט, או sandbox, מחיקה או פירוק של משאב stateful שקלוד לא יצר בסשן, כשאין כלל מחיקה ספציפי יותר ולא נקבתם במשאב, הפניית URL בסיס, פרוקסי, webhook או מראה של registry לצד שלישי, כולל בקובצי דוגמה כמו .env.example, שינוי יעד הדחיפה עם git remote set-url או git remote add אלא אם ציינתם את ה-remote החדש, דחיפת סודות או נתונים אישיים או שהופקדו למאגר ציבורי, או דחיפת חומר חסוי שאינו חלק מעבודת המאגר עצמו. חריג אחד לנתונים אישיים או שהופקדו הוא נושא המאגר עצמו כשמדובר ב-dotfiles. תוכן ממאגר פרטי שמגיע לכל משטח ציבורי נחסם באותו אופן. שני החידודים האלה דורשים v2.1.203 ומעלה. לפני v2.1.203 נתונים אישיים קובצו עם חומר חסוי ונחסמו רק כשלא היו חלק מעבודת המאגר. כשנראות המאגר אינה ידועה, המסווג אינו חוסם על זה לבדו ושופט את התוכן מול שאר הכללים. עוד: פתיחת בקשת משיכה למאגר או לארגון אחר, gh repo fork, או דחיפה למאגר צד שלישי, אלא אם ציינתם את היעד, תוכן מחנות מקומי רגיש, או מקובץ שהשם, הנתיב או הסוג שלו מסמנים אותו כרגיש, שנכנס לקומיט, ל-push, לטקסט של PR או issue, ל-gist או paste, או לפרסום חבילה, אלא אם ציינתם גם את המקור וגם את היעד (מגרסה v2.1.203, ומאגר פרטי אינו מנקה את זה). נספרים תמלילי סשן ויומני שיחה, תיקיות נקודה של אישורים והגדרות כמו מפתחות SSH, אישורי ענן, פרופילי דפדפן והיסטוריית מעטפת, וייצוא נתוני משתמש.

מגרסה v2.1.205 נחסמות גם כתיבה לתמלילי סשן, קובצי ההיסטוריה .jsonl תחת ~/.claude/projects/ או תיקיית ההגדרות שהוגדרה, ישירות או דרך פקודת מעטפת, כולל שורות ה-metadata שקלוד קוד מוסיף לכל רשומה לבדיקות שלו. קריאת תמליל אינה נחסמת. באותה גרסה נחסמת גם מחיקה רקורסיבית כפויה כמו rm -rf "$VAR" או Remove-Item -Recurse -Force $dir, כשהיעד הוא משתנה מעטפת בלי השמה בשיחה שהמסווג רואה, או glob שמושרש במשתנה כזה. הערך הגיע רק מפלט של פקודה קודמת, שהמסווג אינו מקבל, ולכן הוא אינו יכול לאמת את יעד המחיקה מול שאר כללי המחיקה. החסימה מתנקה כשמנקבים בנתיב המדויק, או כשקלוד מריץ שוב עם הנתיב המילולי בפקודה. מחיקה שהמסווג יכול לפענח את היעד שלה אינה מושפעת. glob ישירות מתחת למשתנה, כמו rm -rf "$VAR"/*, הוא נתיב קריטי. יעד Remove-Item שהוא * חשוף, או שמסתיים ב-/* או \*, נדחה לפני שהמסווג רואה אותו.

מגרסה v2.1.257 נחסמות גם בקשת אישורים מ-metadata של מכונת ענן כמו 169.254.169.254, או אימות מפורש של קריאת ענן, אשכול או registry בזהות service-account או הצומת של המכונה, הגעה למארח ציבורי בדרך שאינה בקשה ישירה, כמו מנהרה, reverse shell, או הגדרת resolver או פרוקסי שנכתבה מחדש כך שתצביע החוצה, קריאת אישורים של המארח ולא של המשימה, כמו אישורי צומת או אימות registry של הצומת, וחיבור או סריקה של מכולות, pods או מכונות אחיות שקלוד לא הפעיל, או של הצומת שמתחת למכולה. אם סביבה אמורה להתיר אחת מהחסימות האלה, מתארים אותה ברשומת Host containment ב-autoMode.environment.

מגרסה v2.1.261 נחסם גם פרסום או כתיבה של קישור לשירות הדבקה, תרשים או שיתוף נתונים ציבורי, בהודעה, בטקסט של PR או issue, במסמך, או בכל מקום אחר שבו הקישור ייפתח או יישלף, כשה-URL עצמו נושא את התוכן, אלא אם ציינתם את השירות.

פרטים רגישים בתוכן שנשלח, הועלה, פורסם או נכתב לאנשים אחרים או למערכות משותפות נחסמים כשההודעה שלכם לא אישרה את הפרטים לנמען הזה. גופי PR ו-issue, הודעות קומיט ותגובות נחשבים תוכן יוצא כשהמאגר מחוץ לגבול האמון או ציבורי, כולל מאגרים ציבוריים של הארגון עצמו. נתיבים פנימיים, שמות קוד, נתוני תשובת API חיים כמו דוא"ל או מזהי חשבון, ומזהי תשתית נחשבים פרטים רגישים. נתון אישי חי מתשובת API בגוף PR או issue, כמו כתובת דוא"ל, מזהה חשבון או ארגון, או מדד שימוש, דורש לנקוב בפרטים ובנמען בלי קשר לנראות המאגר או לגבול האמון. הבדיקה הזו דורשת v2.1.203 ומעלה.

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

הרשימות המלאות מודפסות כ-JSON עם:

claude auto-mode defaults

אם פעולות שגרתיות נחסמות, מנהל יכול להוסיף מאגרים, דליים ושירותים מהימנים דרך autoMode.environment.

מותר כברירת מחדל, בין היתר: פעולות קבצים מקומיות בספריית העבודה, התקנת תלויות שמוצהרות בקובצי נעילה או במניפסטים, קריאת .env ושליחת אישורים ל-API התואם שלהם, בקשות HTTP לקריאה בלבד, דחיפה לכל ענף של המאגר שעובדים בו כולל ענף ברירת המחדל, מחיקת העבודות המדויקות שקלוד יצר קודם באותו סשן, קריאה וכתיבה של קוד אבטחה כחלק מהמשימה, הודעות בין סוכנים באותו סשן מרובה סוכנים, שליחת נתונים לדומיינים, לדליים ולשירותים שרשומים ב-environment (זרימת נתונים בלבד, לא פעולות הרס או אישורים על אותה תשתית), וניווט של Claude in Chrome לדומיין פנימי מהימן, ל-localhost, או ל-URL שציינתם. ענף שאינו ברירת המחדל ושמו מסמן יעד פריסה או פרסום, כמו production או gh-pages, אינו מכוסה: המסווג שופט דחיפה לשם בפני עצמה. תוכן הדחיפה עדיין נבדק מול שאר הכללים, כללי permissions.deny עדיין יכולים לחסום את הפקודה כפי שנכתבה, והגנת הענף של ה-remote עדיין חלה. לפני v2.1.211 הותרו כברירת מחדל רק דחיפות לענף שהתחלתם עליו, לענפים שקלוד יצר, ולדחיפות שגרתיות לענף ברירת המחדל. לפני v2.1.203 כל דחיפה ישירה לענף ברירת המחדל נחסמה.

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

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

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

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

• חייבים לנקוב בפעולה ובפרט שהופך אותה למסוכנת, למשל הענף של force push. הפועל לבדו אינו מסיר דבר, כך שניסוח כמו you can force-push משאיר את החסימה.
• אישור מכסה את הפעולה ההרסנית שצוינה. פעולה מאוחרת נחסמת שוב, אלא אם האישור ניתן כעומד. לדפוס שגרתי מוסיפים ל-autoMode.allow.
• חלק מהחסימות נשארות לפי סדר העדיפות של המסווג. כדי להריץ צעד שהוא אינו מנקה, יוצאים ממצב auto ועונים לבקשת האישור.

#סדר ההחלטה של המסווג

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

1. פעולות שמתאימות לכללי allow, ask, או deny מוכרעות מיד, עם החריגים האלה:
   • כתיבה לנתיב מוגן מנותבת למסווג גם כשכלל allow מתאים. כשהנתיב המוגן הוא הקובץ שקובץ הגדרות שהוא symlink מצביע אליו, הכתיבה יכולה לבקש אישור במקום, כפי שרשימת הנתיבים המוגנים מתארת.
   • אף כלל allow אינו מאשר rm ו-rmdir לנתיב קריטי.
   • כלי MCP עם requiresUserInteraction, וכלי מחברים שהארגון הגדיר ל-ask בסשן שבו ההגדרה מגיעה, מבקשים אישור ישירות גם כשכלל allow מתאים.
   • פקודת מעטפת עם דומיינים מותרים לאותה פקודה מנותבת למסווג גם כשכלל allow מתאים, כי הכלל מאשר את הפקודה ולא את המארחים.
   • כלל ask שמתאים לתוכן הפקודה, כמו Bash(git push *), נופל לבקשת אישור.
   • כתיבה שבדיקת symlink מפענחת לנתיב מוגן מבקשת אישור כשהנתיב שקלוד ביקש אינו מוגן בעצמו.
   • קריאה מנתיב רשת מבקשת אישור גם כשכלל allow מתאים.
2. פעולות קריאה בלבד ועריכות קבצים בספריית העבודה מאושרות אוטומטית, חוץ מכתיבה לנתיב מוגן ומהקריאה הראשונה מחוץ לתיקיות העבודה, שמבקשת אישור.
   • בסשן עם בדיקת מסווג בצד השרת, פקודות מעטפת לקריאה בלבד ופקודות ב-sandbox ממתינות לבדיקה ונחסמות אם היא מסמנת אותן.
   • כתיבה בתוך ספריית העבודה שבדיקת symlink מפענחת אל מחוץ לה מבקשת אישור.
   • כשקלוד קורא artifact שמישהו אחר יצר, חלים מקרי האישור שמפורטים בתיעוד של artifacts.
   • קריאה מנתיב רשת מבקשת אישור.
3. כל השאר הולך למסווג, חוץ ממחיקות נתיב קריטי בטיפול ברירת המחדל שלהן. כלי המחברים וכלי MCP עם requiresUserInteraction שביקשו אישור בצעד 1 אינם מגיעים למסווג, כך שאישור שהארגון דורש וצעד הסכמה אינם מאושרים אוטומטית. מוד שמתקינים ומטפל ב-tool.check יכול לאשר פעולה לפני הצעד הזה, והמסווג אינו בודק פעולה שהמוד אישר.
4. אם המסווג חוסם, קלוד מקבל את הסיבה. ברוב הסשנים הסיבה מציינת את הכלל שהותאם, כמו [Data Exfiltration], ולא הסבר כתוב.

בהרחבת VS Code, אופן האישור של פעולות דפדפן של Claude in Chrome תלוי באופן שבו הסשן התחבר לדפדפן.

בכניסה למצב auto מושמטים כללי allow רחבים שמעניקים הרצת קוד שרירותית:

• Bash(*) או PowerShell(*) גורפים.
• מפרשים עם תו כללי כמו Bash(python*).
• פקודות הרצה של מנהלי חבילות.
• כללי allow של Agent.
• כללי allow של Monitor, כי קלוד קוד מריץ פקודות Monitor דרך המעטפת.

כלל צר כמו Bash(npm test) נשאר. הכללים שהושמטו חוזרים ביציאה ממצב auto. לפני v2.1.236 כללי allow של Monitor נשארו בתוקף, כך שכלל שהתאים לכלי כולו אישר פקודות Monitor בלי בדיקת מסווג.

לפני פקודה שתזרוק עבודה שלא נשמרה, כמו git reset --hard או rm -rf, קלוד קוד עצמו מריץ git status ומראה למסווג אם יש עבודה ב-stage, ששונתה, או שאינה במעקב. קבצים שאינם במעקב מדווחים גם כש-status.showUntrackedFiles=no.

בבקשות המסווג שקלוד קוד עצמו שולח, המסווג רואה הודעות משתמש, קריאות כלים שאינן חיפושי קריאה בלבד, ואת תוכן CLAUDE.md. תוצאות כלים מוסרות מהבקשות האלה, כדי שתוכן עוין בקובץ או בדף לא יוכל להשפיע על המסווג ישירות. שדה classifierContext ב-hook מסוג PostToolUse מוסיף הקשר שהאפליקציה מספקת. השדה דורש v2.1.236 ומעלה. בדיקה נפרדת בצד השרת סורקת תוצאות כלים נכנסות ומסמנת תוכן חשוד לפני שקלוד קורא אותו.

עבודת subagent נבדקת בשלוש נקודות:

1. לפני שה-subagent מתחיל, תיאור המשימה המוקצית נבדק, ומשימה שנראית מסוכנת נחסמת בהפעלה.
2. בזמן הריצה, כל פעולה עוברת את אותו סדר החלטה, עם אותם כללי חסימה והיתר. permissionMode ב-frontmatter של ה-subagent מתעלמים ממנו.
3. בסיום, המסווג בודק את העבודה ואת הדוח הסופי לפני שההורה קורא את הדוח. אם המסווג מסמן את העבודה או את הדוח, או שבדיקת בטיחות נפרדת של ה-API מסרבת לבדיקה, הדוח עדיין נמסר עם אזהרת אבטחה בהתחלה. אם המסווג אינו זמין לבדיקה, הדוח מגיע עם הערה לאמת את העבודה לפני שפועלים לפיה.

המסווג רץ על Claude Sonnet 5 כברירת מחדל, לא על הבחירה ב-/model. מודל מסווג ש-Anthropic מגדירה בצד השרת גובר על ברירת המחדל. כשמודל הסשן הוא Claude Sonnet 4.6, או כש-availableModels מוציא את Sonnet 5, המסווג רץ על מודל הסשן, או על מודל Opus כשהסשן רץ על מודל Fable. אצל ספק שאינו Anthropic API, נפילת ה-Opus היא המודל שב-ANTHROPIC_DEFAULT_OPUS_MODEL, או Opus 5 אם לא הוגדר אחד. בקשת ה-auto הראשונה של הסשן מאמתת את ברירת המחדל Sonnet 5: אם הבקשה מצליחה, Sonnet 5 נשאר מודל המסווג של הסשן, ואם היא נכשלת כי המודל אינו זמין, הסשן משתמש בנפילה.

בתוכניות Enterprise ובחשבונות שמשתמשים ב-Claude API, ב-Claude Platform on AWS, ב-Amazon Bedrock, ב-Agent Platform של Google Cloud, או ב-Microsoft Foundry, קריאות המסווג נספרות בשימוש בטוקנים. כל בדיקה שולחת חלק מהתמליל ואת הפעולה הממתינה, ומוסיפה הלוך ושוב לפני הריצה. קריאות ועריכות בספריית העבודה מחוץ לנתיבים מוגנים מדלגות על המסווג, כך שהעומס מגיע בעיקר מפקודות מעטפת ומפעולות רשת. כשהשרת בודק את הפעולות כחלק מבקשות המודל, אין קריאות מסווג נפרדות לספירה. גישת רשת ב-sandbox אינה מוסיפה בקשת מסווג לכל חיבור: המסווג שופט את המארחים יחד עם הפקודה בבדיקה אחת, וקלוד קוד בודק כל חיבור מול הרשימה שאושרה בלי לקרוא למסווג שוב.

#כשמצב auto אינו יכול לאשר

• פעולה חסומה: מוצגת הודעה, והפעולה מופיעה ב-/permissions בלשונית Recently denied. מקש r מנסה אותה שוב עם אישור ידני.
• חסימות חוזרות: אם המסווג חוסם פעולה 3 פעמים ברצף או 20 פעמים בסך הכל, מצב auto נעצר וקלוד קוד חוזר לבקש אישור. אישור הפעולה המבוקשת מחדש את המצב. הספים אינם ניתנים להגדרה. מונה הסך נשמר לסשן ומתאפס רק כשהמגבלה שלו עצמה מפעילה נפילה. דחייה שבדיקת בטיחות נפרדת ממצב auto סירבה בה לבקשת המסווג עצמה אינה נספרת. בהרצת -p לא אינטראקטיבית בלי --permission-prompt-tool אין בקשה ליפול אליה: הפעולה אינה רצה, קלוד ממשיך, וההרצה אינה נעצרת. חסימות חוזרות בדרך כלל אומרות שלמסווג חסר הקשר על התשתית. /feedback מדווח על חיוביות שגויות, או שמנהל מגדיר תשתית מהימנה.
• אין פסק דין מהמסווג: כשבדיקת בטיחות נפרדת מסרבת לבקשת המסווג, או שהתשובה אינה מפוענחת, הפעולה נדחית בלי ההודעה ובלי רשומה ב-Recently denied.
• אין פסק דין מהשרת: תחת בדיקה בצד השרת, הפעולה נדחית, והתור נעצר אחרי עשר תשובות ברצף בלי פסק דין.
• החלפת מצב באמצע בדיקה: אם מחליפים מצב בזמן שבדיקה ממתינה, פסק דין שהמצב החדש לא היה מבקש מושלך. מוצגת בקשת אישור, או שהפעולה נדחית אוטומטית במצב dontAsk.

#דילוג על בדיקות במצב bypassPermissions

מצב bypassPermissions מכבה בקשות אישור ובדיקות בטיחות כך שקריאות כלים רצות מיד, כולל כתיבה לנתיבים מוגנים. גם במצב הזה, כל אחת מהפעולות שאף מצב אינו מאשר אוטומטית מקבלת בקשה או דחייה במקום לרוץ לבד. קריאת artifact ציבורי של ארגון אחר דורשת את האישור שלכם, והמצב הזה אינו מבקש אותו, ולכן קלוד אינו יכול לקרוא artifact כזה. דחיות Remove-Item ב-PowerShell חלות גם כאן.

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

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

בסשן טרמינל אינטראקטיבי עם הרשאות bypass זמינות, קלוד קוד גם אינו אוכף את חסימות מצב plan. קלוד עדיין מקבל הוראה לתכנן בלי לערוך, אבל עריכת קובץ או פקודת מעטפת שהוא מנסה במהלך התכנון רצה בלי בקשה. כללי ask מפורשים ומחיקות נתיב קריטי עדיין מבקשים אישור. מצב plan שומר את החסימות בכל מקום בלי טרמינל אינטראקטיבי, כולל -p, סשני Agent SDK, ושיחות בחלונית הצ'אט של הרחבת VS Code. שם --allow-dangerously-skip-permissions הופך את bypassPermissions לניתן לבחירה אחר כך.

אי אפשר להיכנס למצב מסשן שנפתח בלי שהוא הופעל. מפעילים בהרצה עם permissions.defaultMode: "bypassPermissions" או עם דגל:

claude --permission-mode bypassPermissions

הדגל --dangerously-skip-permissions שקול. קלוד קוד מסרב למצב בסשן שנפתח עם --restricted. הדגל --restricted דורש v2.1.248 ומעלה.

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

• אם מקבלים: קלוד קוד קובע skipDangerousModePermissionPrompt ל-true ב-~/.claude/settings.json, וסשנים מאוחרים מדלגים על התיבה. כדי לראות אותה שוב מסירים את המפתח או קובעים false. אפשר לקבוע את המפתח גם בקובצי הגדרות אחרים, כפי שמפורט בתיעוד של המפתח.
• אם דוחים: קלוד קוד יוצא.

במצב לא אינטראקטיבי אין תיבה. סשן רקע מכבד קבלה כשהיא רשומה בהגדרות משתמש או מנוהלות:

• בלי קבלה רשומה, claude --bg --permission-mode bypassPermissions נדחה עד שמקבלים את התיבה בסשן אינטראקטיבי.
• כש-skipDangerousModePermissionPrompt נקבע רק ב-.claude/settings.local.json, סשן הרקע מתחיל כשהבקשה ל-bypass מתעלמים ממנה, ומוצמדת ההודעה Bypass permissions was requested at launch and ignored · if that was you, ~/.claude/settings.json needs "skipDangerousModePermissionPrompt": true. כדי שה-bypass יכובד, מוסיפים את המפתח ל-~/.claude/settings.json, ואחר כך פותחים סשן רקע חדש.

ב-Linux וב-macOS קלוד קוד מסרב להתחיל במצב הזה כ-root או תחת sudo:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

הבדיקה מדולגת אוטומטית בתוך sandbox מוכר. כדי לרוץ בלי השגחה בתוך מכולה, משתמשים בתצורת dev container, שמריצה את קלוד קוד כמשתמש שאינו root. סשנים בענן אינם מכבדים defaultMode: "bypassPermissions" או "dontAsk" מקובצי הגדרות, כך שהגדרות שנשמרו במאגר אינן יכולות לפתוח סשן בענן במצב הזה. הערך מתעלמים ממנו בשקט, והסשן נפתח במצב שמופיע בבורר. מנהלים יכולים לחסום את המצב עם permissions.disableBypassPermissionsMode בערך "disable" בהגדרות מנוהלות.

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

#הגדרות נפוצות

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

ההרשאות וה-sandbox הם שכבות משלימות. ההרשאות קובעות אילו כלים, קבצים ודומיינים מותרים. ה-sandbox אוכף במערכת ההפעלה גבול של מערכת קבצים ורשת על פקודות Bash, PowerShell ו-Monitor ועל תהליכי הבן שלהן, גם אם תוכן עוין עקף את שיקול הדעת של קלוד. נתיבים ודומיינים מהגדרות ה-sandbox וכללי ההרשאה מתמזגים לתצורת ה-sandbox הסופית. כלל deny או ask עדיין אינו חוסם את EndConversation כל עוד נשאר כלי אחר.

ה-sandbox של Bash ומצב auto פועלים בנפרד ומשתלבים זה בזה, עם החריגים המפורטים בתיעוד הרשמי על מצבי sandbox. האינטראקציה המלאה מתוארת בתיעוד הרשמי על הקשר בין ה-sandbox להרשאות ולמצבי הרשאה, ועל הקשר בין בידוד למצבי הרשאה.

כשה-sandbox פועל ו-autoAllowBashIfSandboxed נשאר בברירת המחדל true, פקודות Bash בתוך ה-sandbox רצות בלי בקשה גם אם יש כלל ask על השם Bash לבדו, או הצורה Bash(*): גבול ה-sandbox מחליף את הבקשה על הכלי כולו. במצב plan ההחלפה הזו אינה חלה. בלי כלל ask, פקודות הקריאה המובנות עדיין רצות בלי בקשה, וכל פקודת מעטפת אחרת עוברת את זרימת ההרשאה הרגילה. עם כלל ask על Bash לבדו, כל פקודת Bash מבקשת אישור, כולל פקודות קריאה ב-sandbox. לפני v2.1.212 ההחלפה חלה גם במצב plan. כלל ask על תוכן פקודה, כלל deny מפורש, ו-rm או rmdir לנתיב קריטי, ממשיכים בזרימה הרגילה. פקודות ב-sandbox אחרות יכולות גם הן לעבור את הזרימה הרגילה, כפי שמצב auto-allow מתאר. פקודות שאינן רצות ב-sandbox מכבדות את כלל ה-ask על Bash כרגיל.

#באיזה מצב סשן נפתח

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

1. הדגל --permission-mode, או --dangerously-skip-permissions.
2. permissions.defaultMode בקובץ הגדרות. אם מגדירים "auto" ב-.claude/settings.json או ב-.claude/settings.local.json, הערך אינו נכנס לתוקף, וקלוד קוד משתמש בברירת המחדל המובנית במקום ב-defaultMode מ-~/.claude/settings.json. מעבירים את "auto" אל ~/.claude/settings.json. אם מגדירים "bypassPermissions" בשני הקבצים האלה, הערך אינו נכנס לתוקף, והסשן נפתח במצב Manual. שאר הערכים חלים מכל קובץ הגדרות. לפני v2.1.257 ערך bypassPermissions נכנס לתוקף מכל קובץ הגדרות.
3. ברירת המחדל המובנית.

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

ברירת המחדל המובנית auto דורשת קלוד קוד v2.1.228 ומעלה ב-macOS, Linux ו-WSL, ו-v2.1.233 ומעלה ב-Windows מקורי. בגרסאות מוקדמות יותר ברירת המחדל המובנית היא Manual.

ברירת המחדל המובנית תלויה באופן ההפעלה של קלוד קוד. השורה הראשונה שמתאימה לסשן היא זו שחלה. הטבלה מכסה סשנים שנפתחים בטרמינל או דרך הרחבת VS Code. לאפליקציית Desktop ול-claude.ai ראו את הלשוניות Desktop ו-Web בתיעוד הרשמי על החלפת מצבי הרשאה.

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

כשהדגל, קובץ הגדרות או ברירת המחדל המובנית בוחרים auto, ומצב auto אינו זמין לסשן, קלוד קוד פותח את הסשן במצב Manual. מצב auto אינו זמין כשהסשן אינו עומד בדרישות הזמינות, למשל כשקובץ הגדרות מכבה אותו או כשהדגם אינו תומך בו, או כש-Anthropic כיבתה אותו זמנית בצד השרת.

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

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

אם ~/.claude/settings.json קובע defaultMode שאינו auto ואין קובץ הגדרות אחר שקובע ערך, הסשנים ממשיכים להיפתח במצב שהגדרת. בתוכניות Pro, Max ו-Team, ובסשנים שאינם שולפים דגלי תכונות, קלוד קוד שואל פעם אחת, בטרמינל או בהרחבת VS Code, האם לשנות את ההגדרה למצב auto. אם דוחים, ההגדרה נשארת כפי שהיא.

#פתיחה במצב הרשאה אחר

אפשר לקבוע את מצב הפתיחה לסשן אחד, או כברירת מחדל לכל סשן במחשב, בפרויקט או בארגון. כשיותר מקובץ הגדרות אחד קובע permissions.defaultMode, סדר העדיפות של ההגדרות מכריע, וערך של פרויקט או ערך מנוהל גובר על ~/.claude/settings.json. כדי להחליף מצב בסשן שכבר רץ, השתמשו ב-Shift+Tab ב-CLI, במחוון המצב ב-VS Code, או בבורר המצב באפליקציית Desktop.

הדוגמה הזו פותחת כל סשן טרמינל במחשב במצב Manual, שערך ההגדרה שלו הוא default. שומרים אותה ב-~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default"
  }
}

הסשן הבא שפותחים מציג בשורת המצב ⏸ manual mode on.

#מצבי הרשאה עם תצורת HIPAA

בארגון שהוחלה בו תצורת HIPAA, ברירת המחדל המובנית auto אינה חלה. סשן טרמינל או VS Code נפתח במצב Manual כששום דבר אחר אינו בוחר את מצב הפתיחה. סשן טרמינל גם מציג Auto mode isn't the default for your organization · Shift+Tab to switch. הרחבת VS Code אינה מציגה הודעה. אילו סשנים עומדים בתנאי ההתחברות מפורט בתיעוד הרשמי של HIPAA.

מצב auto ו-bypassPermissions נשארים זמינים:

• מעבר ל-auto: Shift+Tab, או בקרת המצב של הממשק.
• פתיחה ב-auto: --permission-mode auto, או permissions.defaultMode בערך auto בהגדרות המשתמש, או בהגדרות מנוהלות לכל הארגון.
• הסרת מצב auto: permissions.disableAutoMode בערך "disable" בהגדרות מנוהלות.
• חסימת bypassPermissions: permissions.disableBypassPermissionsMode בערך "disable" בהגדרות מנוהלות.

דורש קלוד קוד v2.1.285 ומעלה, גרסת המינימום לתצורת HIPAA.

#החלפת מצב במהלך סשן

#CLI

במהלך סשן לוחצים Shift+Tab. מ-auto, הלחיצה הראשונה עוברת ל-default, ואחר כך המחזור הוא default, אחר כך acceptEdits, אחר כך plan. מצבים אופציונליים נכנסים אחרי plan. כש-auto במחזור, אחרי plan חוזרים ל-auto, והלחיצה הבאה מ-auto חוזרת ל-default. שורת המצב מציגה ⏸ manual mode on באפור עבור default, או ⏵⏵ accept edits on, ⏸ plan mode on, ⏵⏵ auto mode on, ⏵⏵ don't ask on, או ⏵⏵ bypass permissions on.

לא כל מצב נמצא במחזור ברירת המחדל:

• auto מופיע כשהמצב זמין. מעבר אליו מחליף מצב בלי בקשת אישור.
• bypassPermissions מופיע אחרי שמתחילים עם --permission-mode bypassPermissions, --dangerously-skip-permissions, --allow-dangerously-skip-permissions, או permissions.defaultMode: "bypassPermissions" בהגדרות משתמש, ב---settings, או בהגדרות מנוהלות. גרסת --allow- מוסיפה את המצב למחזור בלי להפעיל אותו.
• dontAsk אינו מופיע במחזור. קובעים אותו עם --permission-mode dontAsk.

מצבים אופציונליים שמופעלים נכנסים אחרי plan, קודם bypassPermissions ובסוף auto. אם שניהם פעילים, עוברים דרך bypassPermissions בדרך אל auto.

מבקשת אישור של Bash, במצבי Manual ו-acceptEdits, כשמצב auto זמין, נוספת האפשרות Yes, and switch to auto mode. הבחירה מאשרת את הפקודה ומעבירה את הסשן למצב auto. בקשות של כלי PowerShell אינן מציעות את זה. דורש v2.1.247 ומעלה. האפשרות אינה נוספת לבקשות שכפה כלל ask או hook, כי מצב auto עדיין מציג את הבקשות האלה.

אותו דגל --permission-mode עובד עם -p. כברירת מחדל קובעים permissions.defaultMode בהיקף הרצוי, כפי שמתואר בסעיף פתיחה במצב הרשאה אחר.

#VS Code

לוחצים על מחוון המצב בתחתית תיבת הפרומפט.

כדי לקבע את מצב הפתיחה, קובעים claudeCode.initialPermissionMode בהגדרות המשתמש של VS Code לאחד מ-default, manual, acceptEdits, plan, או bypassPermissions. ההגדרה אינה מקבלת auto. כדי להתחיל ב-Auto משאירים אותה לא מוגדרת ובוחרים Auto במחוון פעם אחת, כמו בסעיף 2. כל שיחה חדשה נפתחת לפי הראשון שחל:

1. claudeCode.initialPermissionMode
2. המצב האחרון שנבחר במחוון, אם היה Manual, Edit automatically, או Auto. בחירת Plan או Bypass permissions חלה רק על אותה שיחה.
3. permissions.defaultMode מהגדרות מנוהלות או מ-~/.claude/settings.json
4. ברירת המחדל המובנית לפי התוכנית, הספק והגדרות הארגון

ההרחבה אינה קוראת את .claude/settings.json או .claude/settings.local.json של הפרויקט עבור מצב הפתיחה. כש-claudeCode.claudeProcessWrapper מוגדר, סעיפים 3 ו-4 אינם חלים: השיחות נפתחות ב-Manual אלא אם סעיף 1 או 2 קובעים מצב. לפני v2.1.283 סעיף 3 חל רק בתוכניות Pro, Max ו-Team בסשנים ששולפים דגלי תכונות.

Auto מופיע במחוון כשהמצב זמין. Bypass permissions דורש את המתג Allow dangerously skip permissions בהגדרות ההרחבה. בלעדיו המצב אינו מופיע, וערך bypassPermissions מסעיף 1 או 3 פותח את השיחה ב-Manual. Auto מכל סעיף פותח ב-Manual כשהמצב אינו זמין.

בהרחבת VS Code, אופן האישור של פעולות דפדפן של Claude in Chrome תלוי באופן שבו הסשן התחבר לדפדפן, כפי שמפורט בתיעוד של Claude in Chrome.

#JetBrains

התוסף מריץ את קלוד קוד בטרמינל של ה-IDE. מחליפים כמו ב-CLI: Shift+Tab, או --permission-mode בהפעלה.

#Desktop

בלשונית Code משתמשים בבורר ליד כפתור השליחה. Auto מופיע כשהמצב זמין. Bypass permissions דורש את המתג Allow bypass permissions mode בהגדרות Desktop בתוכניות Pro ו-Max. בתוכניות Team ו-Enterprise מדיניות הארגון שולטת בזה. לשונית Cowork אינה משתמשת במצבים האלה. יש לה מצבי הרשאה משלה, שמופעלים בנפרד, והבורר אינו מופיע עד שמצב מעבר לברירת המחדל שלה מופעל לחשבון.

כברירת מחדל קובעים defaultMode בקבצי ההגדרות. האפליקציה קוראת את אותם קבצים כמו ה-CLI ומחילה את המצב על סשנים מקומיים חדשים. מצב שנבחר בבורר נזכר לכל תיקייה וגובר על defaultMode לאותה תיקייה. Plan הוא החריג: הבחירה חלה רק על הסשן הנוכחי.

#Web ומובייל

ב-claude.ai/code משתמשים בתפריט ליד תיבת הפרומפט. באפליקציית המובייל מקישים על כפתור + בתיבת הפרומפט, ואחר כך על Permission. בקשות אישור מופיעות ב-claude.ai.

• סשנים בענן: Accept edits, Plan, ו-Auto. Accept edits מתאים למצב default: סשנים בענן מאשרים מראש עריכות קבצים בלי קשר למצב, ולכן התפריט מציג Accept edits במקום Manual. סשנים בענן עדיין מכבדים defaultMode: "acceptEdits" מההגדרות. מצב Auto מופיע רק כשהארגון מתיר אותו והמודל שנבחר תומך בו. Bypass permissions אינו זמין.
• סשני Remote Control על המכונה המקומית: Manual, Accept edits, Plan, ו-Auto לסשן שהתחלתם בעצמכם. אי אפשר לבחור Bypass permissions מהאפליקציה. כדי להשתמש ב-Auto הסשן צריך לעמוד בדרישות הזמינות של מצב auto. לשרשור פרויקט שרץ על המחשב, ראו בתיעוד הרשמי את הרצת שרשור על המחשב שלכם. חוץ מ-Bypass permissions, התפריט מציג את המצב של הסשן המקומי, כולל מצב שנקבע מהטרמינל, ומתעדכן כשהמצב משתנה באפליקציה או בטרמינל. סשנים שהאפליקציה או הרחבת VS Code מארחים מדווחים על שינוי מצב ל-claude.ai בזמן אמת, כמו סשן שרץ בטרמינל. לפני v2.1.202 סשנים שחוברו עם /remote-control או claude --remote-control לא דיווחו על המצב בכלל, כך שהתווית יכלה להציג מצב שהסשן לא היה בו. אי ההתאמה נגעה רק לתווית. בקשות האישור נוצרו מהמצב האמיתי.

ב-Remote Control המכונה המקומית חייבת להיות מחוברת לחשבון claude.ai. מפתחות API אינם נתמכים. אפשר גם לקבוע את מצב הפתיחה בהפעלת הסשן המקומי:

claude remote-control --permission-mode acceptEdits

#מה דורש אישור במצב Manual

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

בקשת אישור מציגה מה קלוד עומד לעשות, ואז את האפשרויות. בבקשת Bash במצב Manual הדוגמה הרשמית היא פקודה npm test עם התיאור Run the test suite, השורה This command requires approval, והאפשרויות Yes, Yes, and don't ask again for: npm test *, Yes, and switch to auto mode, ו-No. מעל הפקודה מופיע טיפ על מצב auto. Esc מבטל. Tab פותח הערה על Yes או על No. האפשרות לעבור למצב auto אינה מופיעה בכל בקשה.

כשבוחרים אישור קבוע לפקודת Bash או לדומיין של WebFetch, ב-CLI הכלל נשמר ככלל allow בקובץ .claude/settings.local.json בשורש מאגר ה-git, אחרי פתרון worktrees אל ה-checkout הראשי. בהרחבת VS Code כרטיס האישור מאפשר לבחור את קובץ היעד, כולל הקובץ המשותף של הפרויקט, וכלל שם משנה את ההתנהגות לכל מי שעובד בפרויקט. הכלל חל על סשנים עתידיים בכל המאגר, כולל סשן מתת תיקייה או מ-worktree. לפני גרסה v2.1.211 הכלל נשמר בתיקיית ההפעלה. אישור שנשמר אז בתת תיקייה או ב-worktree ממשיך לחול על סשנים שנפתחים משם. קלוד קוד עדיין קורא קובץ שהגרסה הישנה השאירה שם, לצד הקובץ בשורש. כששני הקבצים קובעים את אותו מפתח, הערך בשורש חל, וכללי הרשאה משני הקבצים חלים. העוזר resolveSettings() של ה-Agent SDK קורא את הקובץ תמיד מתיקיית ההפעלה. סשני Agent SDK טוענים את .claude/settings.local.json מספריית העבודה בכל הגרסאות.

כלל allow בקובץ המקומי אינו גובר על כלל ask מקובץ פרויקט או מהגדרות מנוהלות. אם אחרי "Yes, and don't ask again" עדיין מופיעה בקשה לאותו כלי, בודקים אם יש כלל ask בהיקף גבוה יותר.

במקרים כמו מחוץ למאגר git או ב-Windows, קלוד קוד אינו משתמש בשורש המאגר. הקובץ המקומי נשמר בתיקיית העבודה שבה הופעל קלוד קוד (לצד .claude/settings.json) במקום בשורש המאגר בארבעה מקרים: מחוץ למאגר git, כאשר שורש המאגר הוא תיקיית הבית שלך, ב-Windows, או כאשר שורש המאגר או הרשומות .git או .claude אינם בבעלות המשתמש שלך. נתיב שמתחיל ב-/ בכלל הרשאה בקובץ המקומי, וגם נתיב sandbox יחסי, מעוגנים לספריית העבודה הראשית של הסשן, ולא לשורש המאגר.

בפעם הראשונה שקלוד קוד כותב לקובץ .claude/settings.local.json במאגר git שאינו מתעלם ממנו, הוא מוסיף אוטומטית את הנתיב **/.claude/settings.local.json לקובץ ה-git excludes הגלובלי שלך. קובץ זה נקבע לפי core.excludesFile אם הוגדר בהגדרות git הגלובליות נתיב מוחלט או כזה שמתחיל ב-~, ואחרת הוא $XDG_CONFIG_HOME/git/ignore, או ~/.config/git/ignore כאשר המשתנה אינו מוגדר. אם יצרת את הקובץ ידנית לפני שקלוד קוד כתב בו, הוסף אותו בעצמך ל-.gitignore.

כללי ה-allow והרשומות additionalDirectories בקובץ המקומי נכנסים לתוקף בלי שלב האמון כל עוד הקובץ אינו במעקב git. אם הקובץ במעקב git, או ש-.claude הוא symlink, קלוד קוד מתייחס אליו כאל תוכן שהמאגר סיפק ומחזיק את הכללים עד שסומכים על התיקייה. כדי להבדיל בין השניים קלוד קוד מריץ git, ורק אחרי שהתיקייה מהימנה: קיבלתם את תיבת האמון עבורה או עבור תיקיית אב שהאמון שלה מכסה אותה, או שאתם בסשן -p או SDK, שנחשב מקובל. עד אז מקום ההפעלה קובע:

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

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

אישור לעריכת קבצים לא נכתב לקובץ: הוא תקף עד סוף הסשן בלבד.

קלוד קוד קורא את .claude/settings.json המשותף מספריית העבודה הראשית של הסשן. כדי להשתמש בקובץ שנשמר בשורש המאגר, מפעילים את קלוד קוד משם. לאחר /cd <path> קלוד קוד שומר את השיחה, טוען את CLAUDE.md של התיקייה החדשה, ומבקש לסמוך על מרחב העבודה אם לא עבדתם בה. אחר כך --resume מהתיקייה החדשה מוצא את הסשן שהועבר. הוא מחיל את הגדרות הפרויקט החדשות, כולל כללי הרשאה ו-hooks, שרתי .mcp.json בכפוף לאותו אישור כמו בהפעלה, שרתי MCP מקומיים שנרשמו בה, תוספים, skills ו-subagents, וערכי env מעל משתני הסביבה של התיקייה הקודמת, שנשארים בתוקף. הוא מנתק את שרתי ה-MCP של הפרויקט הקודם ושל תוספים שכבר אינם מופעלים, לוקח additionalDirectories מההגדרות החדשות, ושומר תיקיות שנוספו עם --add-dir או /add-dir. hooks שהמעבר מפעיל עדיין מקבלים ${CLAUDE_PROJECT_DIR} כשורש הפרויקט שבו הסשן התחיל. כשהתיקייה החדשה עדיין לא מהימנה, תיבת האמון מפרטת את כללי ה-allow, התיקיות הנוספות, ה-hooks ופקודות העזר שההגדרות יפעילו. דחייה משאירה את הסשן במקום. לפני v2.1.246 הפקודה /cd לא החילה את ההגדרות, ה-hooks, שרתי ה-MCP או ה-skills של התיקייה החדשה עד שחידשו את הסשן, ותיבת האמון לא פירטה מה יופעל. מגבילים או מכבים יעדי /cd עם כללי Cd.

לפעמים מוצג רק אישור חד פעמי, בלי "don't ask again" ובלי אישור לשאר הסשן. האפשרויות האלה מופיעות רק כשהבקשה יכולה להראות במלואן מה הכלל יכסה, כדי שכלל שנשמר מהבקשה יכסה רק את מה ששמו בתווית. כשמוצג רק אישור חד פעמי, אשרו את הפעולה פעם אחת, או הוסיפו את הכלל בעצמכם ב-/permissions. לפקודה שמתחילה בעטיפת exec כמו watch, או ל-find עם פעולה כמו -delete, ראו את סעיף עטיפות exec ופעולות find.

#הוספת הערה במענה לבקשת אישור

באפשרותך לצרף הערה לקלוד כאשר אתה מאשר או דוחה פעולה בודדת. ברוב בקשות האישור, כולל Bash, PowerShell, קבצים וכלי MCP, עבור אל Yes או No והקש Tab כדי לפתוח שדה הערה. בקשות של WebFetch ובקשות דפדפן אינן כוללות שדה זה, וגם אפשרויות ששומרות כלל קבוע או מאשרות לשאר הסשן אינן מקבלות הערה.

כאשר השדה פתוח, הקלד את ההערה והקש על אחד המקשים הבאים:

• Enter: שולח את התשובה בצירוף ההערה. אם השדה ריק, התשובה נשלחת ללא הערה.
• Tab: סוגר את השדה בלי לענות. הטקסט שהקלדת נשמר ויישלח אם תבחר באותה אפשרות.
• Shift+Tab: בבקשת קובץ (כגון Edit או Write), סוגר את השדה בדיוק כמו Tab. לפני גרסה v2.1.235, הקשה על Shift+Tab בתוך השדה בחרה באפשרות לאשר את הפעולה לשאר הסשן וההערה נמחקה.

אופן מסירת ההערה תלוי בתשובה:

• Yes: קלוד קוד מריץ את הפעולה ושולח את ההערה לקלוד מיד לאחר קבלת התוצאה.
• No: קלוד קוד שולח את ההערה כסיבת הדחייה וקלוד ממשיך לעבוד. בחירה ב-No בלי הערה בשיחה הראשית עוצרת את התור (turn).

#ניהול הרשאות

אפשר לראות ולנהל את הרשאות הכלים עם /permissions. הדיאלוג מציג את כל הכללים ואת קובץ ה-settings.json שממנו כל כלל מגיע. אפשר לפתוח את הדיאלוג בזמן שקלוד עובד: הוספה או הסרה של כלל נכנסת לתוקף החל מקריאת הכלי הבאה של קלוד באותו תור. לפני גרסה v2.1.234 הפקודה המתינה עד סיום התור.

• כללי Allow מאפשרים לקלוד קוד להשתמש בכלי שצוין בלי אישור ידני.
• כללי Ask מציגים בקשת אישור בכל פעם שקלוד קוד מנסה להשתמש בכלי שצוין.
• כללי Deny מונעים מקלוד קוד להשתמש בכלי שצוין.

קלוד קוד עוקב אחרי קבצי ההגדרות וטוען אותם מחדש כשהם משתנים, כך שרוב העריכות חלות על הסשן הרץ בלי הפעלה מחדש, כולל עריכות ל-permissions, ל-hooks, ולעוזרי אישורים כמו apiKeyHelper. קלוד קוד גם טוען קובץ הגדרות שנוצר באמצע סשן אם התיקייה שלו הייתה קיימת כשהסשן התחיל. לתיקיית .claude/ של הפרויקט הוא טוען את הקובץ גם כשיוצרים את התיקייה באותו סשן. הטעינה מחדש מכסה הגדרות משתמש, פרויקט, מקומיות ומנוהלות, וקלוד קוד מריץ hook מסוג ConfigChange לכל שינוי בקובץ הגדרות שהוא מזהה. הגדרות מנוהלות שמגיעות מ-MDM או מקונסולת claude.ai מגיעות לסשן רץ לפי לוח הזמנים של מקור המסירה, לא ברגע השמירה. בסשן Cowork על המכונה באפליקציית Desktop, קלוד קוד אינו שולף הגדרות מנוהלות מהשרת מקונסולת claude.ai, והוא קורא מדיניות שנפרסה למכשיר, אלא אם תצורת Claude Desktop של הארגון קובעת requireCoworkFullVmSandbox. מפתחות שנקראים רק בפתיחת הסשן נשארים כפי שהיו: את model מחליפים באמצע סשן עם /model, ואת effortLevel ו-modelSettings עם /effort. מפתחות בצד הניהול שממתינים גם הם להפעלה מחדש, כמו requiredMinimumVersion, מפורטים בתיעוד הרשמי על מקום וזמן תחולה של מדיניות.

כאשר מצב auto זמין לסשן, הדיאלוג כולל גם את כללי המסווג של מצב auto. בחרו בלשונית Auto mode כדי לראות אותם.

החלטת hook אינה עוקפת כללי הרשאה. כלל deny תואם חוסם גם כשה-hook החזיר "allow", וכלל ask תואם עדיין מבקש אישור גם כשה-hook החזיר "allow" או "ask". זה חל על hooks בקובצי הגדרות וב-hooks/hooks.json של תוסף. hook שיוצא בקוד 2 עוצר את הקריאה לפני שהכללים נבדקים, ולכן החסימה חלה גם כשכלל allow היה מתיר. כדי להריץ את כל פקודות Bash בלי בקשה ולחסום כמה מהן, מוסיפים "Bash" לרשימת ה-allow ורושמים hook מסוג PreToolUse שדוחה את הפקודות האלה.

מוד שמתקינים ומטפל ב-tool.check עונה אחרי הכללים ואחרי ה-hooks מסוג PreToolUse, והתשובה שלו יכולה להחליף את שלהם:

• כללי ask: המוד יכול לאשר קריאה שכלל ask היה מבקש עליה.
• חסימה מ-hook מסוג PreToolUse: המוד יכול לאשר את הקריאה, אלא אם ה-hook בהגדרות מנוהלות.
• המסווג במצב auto: קריאה שהמוד אישר רצה בלי בדיקת מסווג.
• כללי deny: במכונה עם הגדרות מנוהלות, או כשמחוברים בתוכנית Team או Enterprise, כללי deny גוברים על המוד כברירת מחדל, והארגון יכול לשנות זאת. בכל מקום אחר המוד יכול לאשר קריאה שכלל deny דוחה.

כלי MCP עם requiresUserInteraction, וכלי מחברים שהארגון הגדיר ל-ask, עדיין מבקשים אישור כש-hook מחזיר "allow". קריאות מנתיבי רשת גם הן עדיין מבקשות אישור כש-hook מחזיר "allow". עבור כלי שדורש אינטראקציה עם המשתמש, אישור tool.check של מוד אינו מדלג על הבקשה. דורש קלוד קוד v2.1.292 ומעלה. hooks מסוג PreToolUse רצים לפני בקשת האישור לכל כלי מלבד EndConversation. פלט ה-hook יכול לדחות את הקריאה, לכפות בקשה, או לדלג על הבקשה כדי שהקריאה תמשיך, בכפוף לכללים למעלה.

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

מארח שמשבץ את קלוד קוד יכול להעביר מדיניות מנוהלת נוספת דרך האפשרות managedSettings של ה-SDK, כולל כללי allow, אלא אם מנהל קבע את נעילות allowManaged*Only. מתי מדיניות של המטמיע חלה בכלל מפורט בתיעוד של Claude apps gateway.

אחד המפתחות שרק הגדרות מנוהלות יכולות לקבוע, allowManagedPermissionRulesOnly, הופך את ההגדרות המנוהלות למקור היחיד של כללי הרשאה. הרשומה של המפתח מונה כל מקור שקלוד קוד מתעלם ממנו אז.

רשימות כמו permissions.allow מתמזגות בין הקבצים: כל קובץ מוסיף רשומות בלי למחוק את הרשומות של קובץ אחר. אם הארגון קובע allowManagedPermissionRulesOnly, נשארים רק כללי ה-allow המנוהלים, וקלוד קוד מתעלם מכל שאר המקורות שהרשומה של המפתח מונה. רשימות מודל אינן כולן מתמזגות באותו אופן: fallbackModel נלקח בשלמותו מהקובץ בעל העדיפות הגבוהה ביותר שמגדיר אותו, ו-modelPicker נלקח בשלמותו מהגבוה מבין הגדרות מנוהלות, --settings, והגדרות משתמש, ומתעלמים ממנו בהגדרות פרויקט ומקומיות. modelPicker דורש v2.1.242 ומעלה. כשהגדרות מנוהלות שקלוד קוד מחיל מגדירות availableModels, הרשימה חלה כפי שהיא ומתעלמים מתוספות בהגדרות משתמש, פרויקט או מקומיות, אלא אם אפליקציה שמטמיעה את קלוד קוד מספקת רשימת מודלים משלה. גם בין מקורות מנוהלים הרשימה אינה מתמזגת: איזה מקור חל מפורט בתיעוד הרשמי על שילוב מקורות מנוהלים. בהיקפים שאינם מנוהלים המערכים מתמזגים כרגיל. modelSettings נפתר מודל אחר מודל, יחד עם effortLevel. איזה קובץ חל על מודל מפורט ברשומת modelSettings בתיעוד ההגדרות.

אפליקציה שמריצה את קלוד קוד בתוכה וקובעת CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST היא חריג נוסף. קלוד קוד לוקח את תצורת המודל של האפליקציה מעל המפתחות model, fallbackModel, modelPicker, ו-modelOverrides מכל מקור מנוהל, ומעל משתני בחירת המודל בבלוק env מנוהל, כמו ANTHROPIC_MODEL ומשפחת ANTHROPIC_DEFAULT_*_MODEL. רשימת availableModels מנוהלת נשארת בתוקף, אלא אם האפליקציה מספקת רשימה משלה. מפתח model מנוהל הוא ברירת מחדל לפתיחה. הנעילות הן availableModels ו-deniedModels. דגל כמו --model בוחר רק ממודלים שהארגון מתיר.

permissions.allow ו-permissions.additionalDirectories ב-.claude/settings.json של פרויקט מעניקים יכולת, ולכן חלים רק אחרי שסומכים על התיקייה. תיבת האמון מפרטת את הכללים והתיקיות שהתיקייה תעניק. כללי deny ו-ask אינם תלויים באמון, כי הם רק מגבילים. בסשן אינטראקטיבי בלבד מוצגת תיבת האמון. הרצת claude -p או סשן SDK אינם מציגים אותה, ואמון בתיקיית אב אינו נספר לכללי allow האלה, ולכן הם אינם בשימוש שם עד שסומכים על התיקייה עצמה. קלוד קוד מדפיס אזהרה שמרחב העבודה לא זכה לאמון אל stderr.

קלוד קוד קושר את האמון לפי מקום ההפעלה. במאגר, האמון נקשר לשורש מאגר ה-git ומכסה את כל המאגר חוץ ממאגר git מקונן בתוכו, כמו submodule. ב-worktree משתמשים בשורש ה-checkout הראשי. מחוץ למאגר, האמון נקשר לתיקייה שממנה הופעל קלוד קוד ומכסה תת תיקיות, חוץ ממאגר git מקונן. כשמתחילים בתיקיית הבית, האמון נשמר לסשן הנוכחי בלבד ואינו נכתב לדיסק.

לפני התחלה או הפעלה מחדש של סשן רקע, קלוד קוד בודק אמון בתיקייה שהסשן רץ בה. claude --bg מטרמינל בתיקייה שלא זכתה לאמון מציג קודם את תיבת האמון, והסשן מתחיל אחרי שמקבלים. כשאי אפשר להציג תיבה, למשל בסקריפט, הפקודה יוצאת בשגיאת Workspace not trusted.

מה שרץ לפני אמון בתיקייה עצמה, בין שאמון ניתן רק לתיקיית אב ובין שב-claude -p או ב-SDK: עמודת תיקיית האב אינה חלה בתוך מאגר מקונן. בסשן אינטראקטיבי קלוד קוד מציג שם את תיבת האמון, והרצת claude -p או SDK שם עוקבת אחרי עמודת claude -p.

לשורות שדורשות אמון בתיקייה הזו עצמה, אפשר לסמוך ידנית: קובעים projects["<path>"].hasTrustDialogAccepted ל-true ב-~/.claude.json, כאשר <path> הוא שורש המאגר, או התיקייה עצמה מחוץ למאגר. קלוד קוד מדפיס את המפתח המדויק בשורת ה-debug של hook או שרת MCP שדולגו, באזהרת stderr של כללי allow שדולגו, ובשורת headersHelper not run.

#לפני claude -p במאגר שלא כתבתם

לפני הרצה במאגר כזה מחליטים מה מותר לרוץ על המכונה:

• מעבירים --setting-sources user, או קובעים ב-SDK את settingSources בלי הגדרות פרויקט, כדי שקלוד קוד לא יקרא את קבצי ההגדרות של הפרויקט ולא את .mcp.json.
• מתחילים עם --bare, כדי שלא ייקראו hooks, skills, פקודות מותאמות, subagents, תוספים או שרתי .mcp.json מהפרויקט. בלוק env של הפרויקט ועוזרים כמו awsAuthRefresh בקובצי ההגדרות שלו עדיין חלים. apiKeyHelper נקרא רק מ---settings.
• מעבירים --settings '{"disableAllHooks": true}' כדי לכבות hooks להרצה הזו. קביעה בהגדרות המשתמש לבדה אינה מספיקה, כי הגדרות הפרויקט גוברות ויכולות להחזיר את הערך ל-false.
• מוסיפים רשומת disabledMcpjsonServers כדי לדחות שרת מ-.mcp.json לפי שם, בכל סוג סשן.

#מלכודות בהגדרות

כשמפתח אינו מתנהג כאילו הגדרתם אותו, מתחילים ב-/status ורואים אילו קבצים נטענו. שורת Setting sources מפרטת כל קובץ שנטען לסשן, וכשהגדרות מנוהלות בתוקף היא מציינת בסוגריים איך הגיעו למכונה. השורה מאשרת אילו קבצים נקראו, והיא אינה מראה איזה קובץ סיפק כל מפתח. רשומות שקלוד קוד דחה רואים עם claude doctor. המקרים הנפוצים שנוגעים להרשאות ולהגדרות:

• רמה גבוהה יותר קובעת את אותו מפתח. הסדר, מהגבוה לנמוך: הגדרות מנוהלות, --settings לסשן הזה, .claude/settings.local.json, .claude/settings.json המשותף, ~/.claude/settings.json. מפתח ברמה גבוהה דורס את אותו מפתח מתחתיו. מפתח שמשאירים מחוץ ל---settings שומר את הערך מהקבצים. דגלים אחרים, כמו --model, קובעים דבר אחד לסשן ואינם חלק מהמחסנית הזו: הרשומה של המפתח בתיעוד ההגדרות אומרת אילו דגלים דורסים אותו. משתני סביבה אינם רמה במחסנית. כשיש גם משתנה מעטפת וגם מפתח, מי חל נקבע לכל זוג: ANTHROPIC_MODEL שיוצא במעטפת חל מעל מפתח model מכל קובץ, ו-ANTHROPIC_DEFAULT_MODEL חל רק כשאף קובץ אינו קובע model. בלוק env בתוך קובץ הגדרות הוא מפתח רגיל ועוקב אחרי הרמות.
• הקובץ אינו יכול לקבוע את הערך. permissions.defaultMode בערכים auto ו-bypassPermissions אינו נכנס לתוקף מהגדרות פרויקט או מקומיות. קובעים אותם בהגדרות משתמש או מנוהלות, או מעבירים --permission-mode לסשן אחד. לפני v2.1.257 ערך bypassPermissions נכנס לתוקף מכל קובץ. משתנה ייצוא טלמטריה בבלוק env גם אינו נכנס לתוקף מהגדרות פרויקט או מקומיות, חוץ מכמה ערכי כיבוי. הרשימה והערכים האלה מפורטים בתיעוד הרשמי של משתנים שקלוד קוד מתעלם מהם ב-env.
• מפתח שמצמצם סשן נשמר גם כשמקור מנוהל קובע ערך רופף יותר. קלוד קוד מכבד את הערך המצמצם לפי הטבלה, גם כשהיקף אחר אינו יכול לדרוס הגדרה מנוהלת.

• מפתח בקובץ שבמאגר ממתין לאמון. permissions.allow, permissions.additionalDirectories, extraKnownMarketplaces, ורוב ערכי env חלים רק אחרי שסומכים על התיקייה. כללי deny ו-ask חלים מיד.
• מפתח בקובץ המאגר מתעלמים ממנו לפי ההיקף. בעמודת Scope באינדקס ההגדרות הרשמי, מפתח שמסומן User, local, or managed, User or managed, User, Managed, או Global config אינו חל מהקובץ המשותף, חוץ מכמה מפתחות שקובץ מאגר עדיין יכול לכבות. כל רשומה כזו אומרת זאת בשורת Scope שלה. מפתחות Global config חלים רק מ-~/.claude.json. בתוך env, משתני ייצוא הטלמטריה גם אינם חלים מהקובץ המשותף, חוץ מכמה ערכי כיבוי.
• הקובץ שבור. JSON לא תקין או ערך שהסכימה דוחה: בסשן אינטראקטיבי מוצגת Settings Error כשקובץ משתמש, פרויקט או מקומי פגום, ואפשר לתקן עם קלוד, לצאת, או להמשיך בלי ההגדרות השבורות. Settings Warning משאירה את שאר הקובץ ומדלגת על רשומות בודדות, כמו כלל הרשאה פגום או שם אירוע hook לא מוכר. בהגדרות מנוהלות קלוד קוד ממשיך לאכוף את שאר הקובץ. מה שמושמט, ואילו מפתחות נופלים לערך מחמיר יותר עד התיקון, מפורט בתיעוד הרשמי של רשומות לא תקינות בהגדרות מנוהלות. מסמך מנוהל שאינו JSON תקין מפורט בתיעוד השגיאות הרשמי. כשאי אפשר לפרק את ~/.claude.json, קלוד קוד מעתיק את הקובץ השבור אל ~/.claude/backups/.claude.json.corrupted.<timestamp> ושואל אם לצאת ולתקן ידנית או לאפס לתצורה המוגדרת. הרצת -p מדפיסה את השגיאה ויוצאת. כדי לשחזר מצב קודם מעתיקים חזרה אחד מחמשת קובצי .claude.json.backup.<timestamp> האחרונים ב-~/.claude/backups/, שקלוד קוד שומר לפני כתיבה. בהרצת -p אין תיבה, חוץ ממסמך מנוהל שאי אפשר לפרק: קלוד קוד מדלג על הקובץ או על הערכים וממשיך. אחר כך מריצים claude doctor.
• שינוי מתוך קלוד קוד נעלם בסשן הבא. בחירה שנשמרת לסשנים חדשים מתוך קלוד קוד, למשל מודל ברירת מחדל עם /model, נכתבת אל ~/.claude/settings.json. אם אי אפשר לכתוב לקובץ, למשל כי כלי אחר מייצר אותו או מקשר אותו לעותק לקריאה בלבד, השינוי חל על הסשן הנוכחי ונעלם בסשן הבא. קובעים את המפתח בכלי שמייצר את הקובץ, או מחליפים את הקובץ בקובץ שאפשר לכתוב אליו. אם הכתיבה אפשרית והשינוי עדיין אינו נשאר, בודקים אם הוא היה לסשן אחד בלבד, או אם רמה גבוהה יותר קובעת את אותו מפתח.
• שינוי מנוהל עדיין לא הגיע. מקורות מנוהלים מגיעים לסשן רץ לפי לוח הזמנים בטבלת המסירה בתיעוד הרשמי, ולכן קודם מפעילים מחדש את הסשן. אם /status מציין אחר כך מקור אחר מזה שהמנהל שינה, חל מקור בעדיפות גבוהה יותר. סדר השילוב מפורט בתיעוד הרשמי על שילוב מקורות מנוהלים.
• כללי allow מצטרפים אחרת מהצפוי. "Yes, and don't ask again" שומר כלל allow בקובץ המקומי, וכלל שם אינו גובר על כלל ask מקובץ פרויקט או מנוהל. בהרחבת VS Code כרטיס האישור מאפשר לבחור את קובץ היעד, כולל הקובץ המשותף, וכלל שם משנה את ההתנהגות לכולם. ב-CLI קלוד קוד כותב רק לקובץ המקומי. כללי allow של הארגון ממשיכים לחול לצד הכללים שלך, כי permissions.allow מתמזג בין היקפים, אלא אם הארגון קובע allowManagedPermissionRulesOnly.

סשן בענן רץ על שכפול חדש של המאגר, לא על המכונה שלך, ולכן מגיעות אליו רק חלק מההגדרות. .claude/settings.json המשותף נקרא כשיש מאגר אחד, כי הקובץ חלק מהשכפול והסשן מתחיל בתוכו. בסביבה ש-Anthropic מארחת, סשן עם כמה מאגרים מתחיל מעל השכפולים וקורא מכל מאגר רק את enabledPlugins ו-extraKnownMarketplaces, לא כללי הרשאה, hooks, env, או מפתחות אחרים. השווקים והתוספים ששני המפתחות האלה מכריזים עדיין אינם נטענים בסשן בענן. לסביבה באירוח עצמי, איזה קובץ הגדרות של מאגר חל מפורט בתיעוד הרשמי של סביבות באירוח עצמי. הגדרות משתמש והגדרות מקומיות אינן נקראות בענן: שתיהן נשארות על המכונה, והקובץ המקומי אינו בשכפול. קובץ managed-settings.json או פרופיל MDM על המכשיר אינם מגיעים לסשן בענן. הגדרות מנוהלות מהשרת מגיעות לסשני הענן שהכיסוי הרשמי שלהן כולל. סביבה באירוח עצמי קוראת גם את קובץ ההגדרות המנוהלות בתמונת ה-runner. מתי הקובץ הזה חל מפורט בתיעוד הרשמי על שילוב מקורות מנוהלים. ב-claude.ai/code, /config פותח את מקטע קלוד קוד בהגדרות claude.ai ואינו משנה ערך. כדי לשנות הגדרה לסשן בענן קובעים משתנה סביבה על הסביבה, או, בסשן עם מאגר אחד, מבצעים commit של המפתח אל .claude/settings.json של המאגר.

#תיקיות עבודה

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

• בהפעלה: --add-dir <path>
• במהלך הסשן: /add-dir
• באופן קבוע: additionalDirectories בקבצי ההגדרות

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

אי אפשר להוסיף את רוב נתיבי הרשת, כמו שיתוף UNC \\server\share, כתיקיות עבודה, כי איתור הנתיב יכול לפנות למארח שהוא מציין. ב-Windows ממפים את השיתוף לאות כונן ומעבירים את הכונן עם --add-dir בהפעלה.

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

בסשני רקע ב-macOS, מארח הסשן מבקש גישה לתיקיות מוגנות כמו ~/Desktop, ~/Documents ו-~/Downloads בנפרד מהטרמינל, כשקלוד צריך לקרוא או לכתוב שם. אם הקריאה נכשלת עם Operation not permitted, אופן מתן הגישה מפורט בתיעוד הרשמי של סשני רקע.

#תיקייה נוספת נותנת גישה לקבצים, לא הגדרות

הוספת תיקייה מרחיבה איפה קלוד קורא ועורך. היא אינה הופכת את התיקייה לשורש הגדרות מלא: רוב מה שב-.claude/ אינו מתגלה מתיקיות נוספות, חוץ מהסוגים בטבלה.

החריגים חלים רק על תיקיות שנוספו עם --add-dir או /add-dir, כולל תיקיות שה-Agent SDK מוסיף דרך הדגל. רשומות permissions.additionalDirectories בקובץ הגדרות נותנות גישת קבצים בלבד ואינן טוענות את ההגדרות שלמטה.

האפשרות additionalDirectories ב-TypeScript והאפשרות add_dirs ב-Python של ה-SDK מקבלות את אותם חריגים, אף שהשם ב-TypeScript זהה למפתח בהגדרות. ה-SDK מעביר כל רשומה אל קלוד קוד כ---add-dir. skills, פקודות ו-subagents מכל תיקייה שנוספה בדגל נטענים דרך מקור ההגדרות project, ולכן אינם נטענים כשמוציאים את המקור עם --setting-sources או עם settingSources. מצב bare מדלג על הפקודות וה-subagents מתוכם.

כדי לטעון skills, פקודות ו-subagents מתת תיקייה של ספריית העבודה הראשית באמצע סשן, מריצים /add-dir עם הנתיב שלה. קלוד קוד טוען אותם להמשך הסשן בלי לבקש ובלי להוסיף תיקיית עבודה, כי התת תיקייה כבר קריאה. דורש v2.1.257 ומעלה.

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

כדי לשתף את ההגדרה בין פרויקטים: שמים קבצים ב-~/.claude/agents/, ב-~/.claude/output-styles/, או ב-~/.claude/settings.json. אורזים אותה כתוסף. או מפעילים את קלוד קוד מהתיקייה שמכילה את .claude/ הרצוי.

#תחביר כללי הרשאה

כללי הרשאה עוקבים אחרי הפורמט Tool או Tool(specifier). סוגריים בתוך ה-specifier הם מילוליים, כך שפקודה או נתיב שמכילים אותם לא דורשים escaping.

#התאמה לכל השימושים בכלי

כדי להתאים לכל השימושים בכלי, השתמשו רק בשם הכלי בלי סוגריים:

Bash(*) שקול ל-Bash ומתאים לכל פקודות Bash. ככלל deny, שתי הצורות מסירות את הכלי מההקשר של Claude.

#שימוש ב-specifiers לשליטה עדינה

הוסיפו specifier בסוגריים כדי להתאים לשימושים ספציפיים בכלי:

#התאמה לפי פרמטר קלט

כללי deny ו-ask יכולים להתאים לפרמטר קלט ברמה העליונה בכל כלי מובנה עם Tool(param:value).

כדי להתאים לפרמטר בכלי MCP, העבירו כלל deny עם --disallowedTools. כש-Claude Code טוען קובץ הגדרות, הוא מדלג על כל כלל mcp__ שיש בו סוגריים. Claude Code מציג את הכלל שדולג בתיבת הדו-שיח invalid-settings כשמתחיל סשן אינטראקטיבי, וגם בפלט של claude doctor.

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

התאמת פרמטרים עוקבת אחרי הכללים האלה:

• שם הפרמטר חייב להיות שדה ישיר של קלט הכלי, למשל model בכלי Agent. שדות מקוננים בתוך אובייקט או מערך אינם ניתנים להתאמה
• כל כלל מציין פרמטר אחד. כדי לשלוט גם ב-model וגם ב-isolation, כתבו שני כללים, Agent(model:opus) ו-Agent(isolation:worktree), במקום לשלב אותם בכלל אחד
• הערך תומך ב-* כתו כללי שמתאים לכל רצף תווים, כך ש-Agent(isolation:*) מתאים לכל ערך isolation מפורש. בלי * ההתאמה מדויקת
• פרמטר שהמודל משמיט אף פעם לא מותאם, כך ש-Agent(model:*) לא מתאים לקריאה שמשאירה את model לא מוגדר
• הערך מושווה מול הקלט המילולי ש-Claude שולח, לפני כל נרמול. Agent(model:opus) מתאים לכינוי opus אבל לא למזהה מודל מלא. הריצו עם --verbose כדי לראות את שמות הפרמטרים והערכים המדויקים בכל קריאת כלי
• כלל deny מסוג Skill(skill:<name>) מתאים ל-skill תחת כל אחד מהשמות שלו, כמו כינוי או שם תצוגה
• רווחים סביב הנקודתיים מתעלמים מהם

אי אפשר להתאים כך לשדה התוכן הראשי של כלי: command עבור Bash ו-PowerShell, file_path עבור Read, Edit ו-Write, path עבור Grep ו-Glob, notebook_path עבור NotebookEdit, ו-url עבור WebFetch. כלל כמו Bash(command:rm *) היה ניתן לעקיפה באמצעות פקודה מורכבת, לכן Claude Code מתעלם ממנו ופולט אזהרת אתחול. השתמשו במקום זאת ב-Bash(rm *), Read(./path) או WebFetch(domain:host).

#תבניות תו כללי

* בכלל Bash מתאים לכל טקסט, כולל רווחים, כך שכלל אחד מכסה משפחה של פקודות. כלל בלי * מתאים לפקודה מדויקת אחת.

שימו את * אחרי תת-הפקודה. ב-git log --oneline main, git הוא התוכנית ו-log הוא תת-הפקודה, המילה שקובעת מה התוכנית עושה. Claude Code מתאים את כל מה שלפני ה-* הראשון כפי שנכתב, כך שהמילים האלה הן מה שמגביל את הכלל: Bash(git log *) מאפשר רק פקודות git log, ו-Bash(git *) מאפשר כל פקודת git. Claude Code מזהיר באתחול על כלל allow עם * לפני תת-הפקודה, למשל Bash(git * main).

כתבו את הפקודה שאתם רוצים ש-Claude יריץ בלי לשאול, והחליפו את החלקים שמשתנים ב-*. עם התצורה הזו, Claude Code מריץ סקריפטי npm ו-git commits בלי לשאול ומסרב לפקודות שמתחילות ב-git push. push שנכתב בדרך אחרת, למשל git -C . push, לא מותאם; ראו מה כלל Bash לא מתאים.

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

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

שלושה כללי התאמה מייצרים את השורות האלה:

• ה-* עומד במקום כל טקסט שנמצא במקומו. ב-Bash(git * main), הוא עומד במקום תת-הפקודה, כך ש-Claude Code מתאים לכל תת-פקודת git ולכל אפשרות שלפניה. זה כולל -c, שגורם ל-git להריץ תוכנית שאתם מציינים. ב-Bash(* --version), ה-* עומד במקום התוכנית, כך שכל תוכנית מתאימה.
• * בסוף, עם רווח לפניו, מתאים גם לפקודה החשופה. Bash(ls *) מתאים ל-ls, ו-Bash(git log *) מתאים ל-git log. זה תקף רק כשה-* הסופי הוא התו הכללי היחיד בכלל: Bash(* --help *) מתאים ל-npm --help x אבל לא ל-npm --help.
• הרווח לפני * סופי הוא חלק מהכלל. Bash(ls *) דורש רווח אחרי ls, כך ש-lsof לא מתאים. ל-Bash(ls*) אין רווח, כך שהוא מתאים גם ל-lsof.

הסיומת :* היא דרך שקולה לכתוב תו כללי סופי, כך ש-Bash(ls:*) מתאים לאותן פקודות כמו Bash(ls *).

תיבת הדו-שיח של הרשאות כותבת את הצורה המופרדת ברווחים כשאתם בוחרים "Yes, and don't ask again" לקידומת פקודה. הצורה :* מזוהה רק בסוף תבנית. בתבנית כמו Bash(git:* push), הנקודתיים מטופלות כתו מילולי ולא יתאימו לפקודות git.

#תווים כלליים בשם כלי

כללי deny ו-ask מקבלים גם תבניות glob בעמדת שם הכלי. התבנית חייבת להתאים לשם הכלי המלא: "*" מתאים לכל כלי, ו-"mcp__*" מתאים לכל כלי MCP בכל השרתים. כלי שמותאם על ידי כלל deny של glob בשם חשוף מוסר מההקשר של Claude, כמו שם כלי חשוף, כולל החריג של EndConversation: glob deny לא יכול להסיר אותו כל עוד נשאר כלי אחר, ו-glob ask אף פעם לא מבקש אישור עבורו. התצורה הזו דוחה כל כלי MCP:

{
  "permissions": {
    "deny": [
      "mcp__*"
    ]
  }
}

כללי allow מקבלים glob בשם כלי רק אחרי קידומת מילולית mcp__<server>__. מקטע השרת חייב להיות בלי glob כדי שהכלל יציין שרת ספציפי שהגדרתם. mcp__puppeteer__* מתאים לכל כלי משרת puppeteer, ו-mcp__github__get_* מתאים לכלי get_ שלו. glob allow לא מעוגן כמו "*", "B*", או "mcp__*" מדולג עם אזהרה ולא מאשר אוטומטית דבר.

כלל deny או ask ששם הכלי שלו לא מתאים לכלי ידוע מייצר אזהרת אתחול כדי לתפוס שגיאות הקלדה. שמות כלים שמכילים _ או * פטורים מהבדיקה, וכך גם שמות כלים ש-Claude Code הסיר, למשל TaskOutput.

התווית שמוצגת לכלי בתמליל ובתיבת הדו-שיח של הרשאות יכולה להיות שונה מהשם הקנוני שלו. למשל, הכלי שמסומן Stop Task בתמליל יש לו שם קנוני TaskStop. כללי הרשאה ו-מתאמי hook לא מתאימים לתווית, כך שכלל שנכתב כ-Stop Task לא מתאים. לכללי deny ו-ask, אזהרת האתחול למעלה תופסת את אי ההתאמה. השתמשו בשמות הקנוניים המופיעים ב-tools reference.

#מה כלל Bash לא מתאים

כלל Bash מתאים לטקסט הפקודה שקלוד כותב, אחרי שקלוד קוד מפצל פקודות מורכבות ומסיר עטיפות. הוא אינו מתאים לאותה תוכנית בצורה אחרת, ולכן כלל deny או ask מכסה את הצורה שקלוד בדרך כלל מייצר ואינו גבול אבטחה סביב התוכנית. שאר הכללים ומצב ההרשאה מכריעים את הפקודות בעמודה האחרונה. לאכיפה שאינה תלויה בטקסט הפקודה משתמשים ב-sandbox, ולבדיקה של הטקסט המלא לפני הריצה ב-hook מסוג PreToolUse.

המפרידים המוכרים הם &&, ||, ;, |, |&, &, ושורות חדשות. כלל צריך להתאים לכל תת פקודה בנפרד. כללי deny ו-ask חלים כשתת פקודה כלשהי מתאימה, כולל פקודה בתוך subshell, החלפת פקודה, או גוף לולאה כמו for. כלל ask כמו Bash(git clean *) עדיין מבקש אישור עבור cd /tmp && git clean -f או echo "$(git clean -f)", גם במצב auto. כש-&& או || בלי כלום אחריהם, למשל npm test &&, הפקודה נחשבת לא ניתנת לניתוח ואינה מפוצלת להתאמת כלל allow, כך ש-Bash(npm *) אינו מאשר אותה. אישור "Yes, and don't ask again" לפקודה מורכבת שומר כלל נפרד לכל תת פקודה שדורשת אישור, עד 5 כללים, ולא כלל אחד למחרוזת כולה. אישור של git status && npm test שומר כלל ל-npm test, כך שהרצות מאוחרות של npm test מזוהות בלי קשר למה שלפני ה-&&. תת פקודה כמו cd אל מחוץ לתיקיות העבודה מייצרת כלל Read משלה לאותו נתיב.

לפני התאמה מוסרות עטיפות קבועות: timeout, time, nice, nohup, ו-stdbuf, וגם ה-builtins command ו-builtin, ו-noglob של zsh. אינן מוסרות הצורה command -v ו-nocorrect של zsh. גם השמת משתני סביבה ידועים כבטוחים מוסרת, כך ש-Bash(npm test *) מתאים ל-NODE_ENV=test npm test. כלל allow אינו עובר השמה של משתנה אחר. כלל deny או ask עובר כל השמה מובילה. xargs חשוף בלי דגלים מוסר, כך ש-Bash(grep *) מתאים ל-xargs grep pattern. עם דגלים, כמו xargs -n1 grep pattern, ההתאמה היא לפקודת xargs. הרשימה מובנית ואינה ניתנת להגדרה. direnv exec, devbox run, mise exec, npx, ו-docker exec אינם בה. כלל כמו Bash(devbox run *) מתאים לכל מה שאחרי run, כולל devbox run rm -rf .. כדי לאשר עבודה בתוך רץ סביבה כותבים כלל שמכיל גם את הרץ וגם את הפקודה הפנימית, למשל Bash(devbox run npm test), כלל אחד לכל פקודה פנימית. עטיפות כמו watch, setsid, ionice, ו-flock אינן מאושרות אוטומטית על ידי כלל קידומת כמו Bash(watch *), ובמצב Manual הן תמיד מבקשות אישור. אותו דבר ל-find עם פעולה שמריצה פקודות, מוחקת קבצים או כותבת קבצים, כמו -exec, -delete, או -fprint, או עם -files0-from, שלוקח את הנתיבים לחיפוש מקובץ: כלל Bash(find *) אינו מכסה את הצורות האלה. לאישור קריאה מסוימת בלי * כותבים כלל התאמה מדויקת למחרוזת הפקודה המלאה, למשל Bash(find build -type f -delete). כשיש * בפקודה, כמו find . -name '*.tmp' -delete, קלוד קוד קורא את הכלל כתבנית תו כללי ולא כהתאמה מדויקת, והפקודה עדיין מבקשת אישור. מאשרים בכל פעם, או משתמשים ב-hook מסוג PreToolUse שמחזיר "allow".

תבנית שמנסה להגביל ארגומנטים שבירה. למשל Bash(curl http://github.com/ *) אינו מתאים ל-curl -X GET http://github.com/..., ל-curl https://github.com/..., להפניה, או למשתנה. לסינון URL אמין יותר חוסמים curl ו-wget בכלל deny ומשתמשים ב-WebFetch(domain:github.com), ומצמידים את רשימת הרשת של ה-sandbox כי כלל deny אינו תופס את התוכנית לפי נתיב או בתוך sh -c. אפשר גם hook מסוג PreToolUse. הנחיה ב-CLAUDE.md מעצבת מה קלוד מנסה ואינה אוכפת גבול. WebFetch לבדו אינו מונע גישת רשת אם Bash מותר.

פקודות קריאה מובנות רצות בלי בקשה בכל מצב, חוץ ממה ש-permissions.blockReadsOutsideWorkingDirectories משנה לנתיבים מחוץ לתיקיות העבודה. הקבוצה כוללת ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, וצורות קריאה בלבד של git. הקבוצה אינה ניתנת להגדרה. כדי לדרוש בקשה מוסיפים כלל ask או deny. במצב auto הפקודות האלה יכולות גם להמתין לבדיקת המסווג. תבנית glob לא מצוטטת מותרת כשכל דגל הוא לקריאה בלבד, כך ש-ls *.ts ו-wc -l src/*.py רצים בלי בקשה. הפניה כמו ls > out.txt מוסיפה בדיקה על היעד.

במצב Manual פקודות מהקבוצה עדיין מבקשות אישור במקרים האלה:

• glob לא מצוטט בפקודה עם דגלים שיכולים לכתוב או להריץ, כמו find, sort, sed, ו-git, כי ה-glob עלול להתפשט לדגל כמו -delete.
• docker עם דגל שבוחר daemon אחר, כמו -H, --context, או --url ו---connection של Podman.
• file עם -m או --magic-file, או -f או --files-from.
• ps כשאחד הארגומנטים יכול לפעול כאפשרות e, כמו ps auxe או ps aux -e, כי האפשרות מדפיסה משתני סביבה של תהליכים. ps aux ו-ps -ef רצים בלי בקשה. הבדיקה על צורות עם מקף כמו ps aux -e דורשת קלוד קוד v2.1.290 ומעלה.
• ארגומנט שהוא נתיב רשת UNC ב-Windows, כמו \\server\share\file. אותה בדיקה חלה על פקודות כלי PowerShell.
• פקודה שמגדירה, מבטלת, או רצה בלולאה על משתני מעטפת מיוחדים כמו PATH או IFS.
• פקודה שהניתוח אינו יכול לפרק במלואה. פקודה ארוכה מ-10,000 תווים תמיד מבקשת אישור.

cd לנתיב בתוך ספריית העבודה או ספרייה נוספת הוא גם קריאה בלבד, ופקודה מורכבת כמו cd packages/api && ls רצה בלי בקשה כשכל חלק עומד בפני עצמו. cd יחד עם git מבקש אישור כשה-cd עובר לתיקייה אחרת, כי git בתיקייה חדשה יכול להריץ hooks שלה. cd שהיעד שלו הוא ספריית העבודה הנוכחית אינו מפעיל את הבקשה. cd עם הפניה מבקש אישור כשאי אפשר לדעת לאיזו תיקייה יעד ההפניה מתייחס אחרי ה-cd. פקודה שהפניה היחידה שלה היא אל /dev/null, כמו cd app; grep -r pattern . 2>/dev/null, אינה מבקשת אישור.

כשפקודה מפנה פלט או קלט, היעד נבדק מול כללי הקבצים כאילו קלוד כתב או קרא את הקובץ ישירות. בהפניית פלט >, >>, או 2>, הבדיקה מכסה כללי Edit של allow ו-deny, נתיבים מוגנים, ותיקיות עבודה. כלל כמו Bash(git commit *) מתיר את הפקודה, לא את היעד. יעד שמתחיל ב-~ או מכיל תו glob דורש אישור. בהפניית קלט <, הבדיקה מכסה כללי Read ותיקיות עבודה. דורש v2.1.257 ומעלה. יעד מחוץ לתיקיות העבודה דורש אישור אלא אם כלל allow מכסה אותו. יעד עם תבנית glob, או נתיב יחסי שאחרי cd באותה פקודה, דורש אישור גם כשכלל allow מכסה אותו. יעדים בלי קובץ מאחוריהם אינם נבדקים: /dev/null, צורות מתאר קובץ כמו 2>&1 ו-<&3, ו-here-doc ו-here-string. קבצים ש-tee כותב נבדקים גם בצינור כמו make | tee build.log, מגרסה v2.1.269. כלל Bash(tee *) אינו מכסה יעד מחוץ לתיקיות העבודה. בדיקת tee מכסה כללי Edit של allow ו-deny, נתיבים מוגנים, ותיקיות עבודה.

כללי PowerShell באותה צורה. * מתאים בכל מקום, סיומת :* שקולה ל- * סופי, ו-PowerShell או PowerShell(*) מתאימים לכל פקודה. כינויים נפוצים מנורמלים לפני ההתאמה, כך שכלל על שם ה-cmdlet מתאים גם לכינויים: PowerShell(Get-ChildItem *) מתאים גם ל-gci, ל-ls ול-dir. ההתאמה אינה תלוית רישיות. העץ של PowerShell מפוצל לפי |, ;, וב-PowerShell 7 ומעלה גם && ו-||. הכלל צריך להתאים לכל תת פקודה.

{
  "permissions": {
    "allow": [
      "PowerShell(Get-ChildItem *)",
      "PowerShell(git commit *)"
    ],
    "deny": [
      "PowerShell(Remove-Item *)"
    ]
  }
}

#קריאה ועריכה

כדי לחסום קריאת קובץ או תיקייה מוסיפים כלל Read ב-deny, כמו Read(./.env) או Read(./secrets/**). אם בפרויקט יש קובץ .claudeignore, אין לו השפעה, ומעבירים את הרשומות שלו לכללי Read ב-deny. כללי Edit חלים על כל הכלים המובנים שעורכים קבצים. קלוד משתדל להחיל כללי Read על כלים מובנים שקוראים, כמו Grep ו-Glob, על אזכורי @file, ועל הקשר הבחירה והקובץ הפתוח ש-IDE מחובר משתף.

כלל Read ב-deny חל גם על נתיב תמונה שמדביקים בפרומפט ועל תיקייה שמזכירים עם @:

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

קלוד קוד בודק נתיבי תמונה שהודבקו ורשימות תיקיות בקלוד קוד v2.1.290 ומעלה.

כלל Read ב-deny חוסם גם את Edit ו-Write על אותו נתיב, כולל יצירת קובץ חדש שם. NotebookEdit אינו מכוסה, ולכן מוסיפים כלל Edit ב-deny לנתיב שאף כלי לא ישנה. הבדיקה דורשת v2.1.208 ומעלה בעריכות, ו-v2.1.228 ומעלה בכתיבות.

בדיקת הרשאות קבצים נעשית רק מול Edit(path) ו-Read(path). כלל נתיב ל-Write, NotebookEdit, Glob, או MultiEdit הישן מתקבל אבל אינו נבדק, ומוצגת אזהרת אתחול, חוץ מכלל Glob שמועבר ב---allowedTools. משתמשים ב-Edit(docs/**) במקום Write(docs/**), NotebookEdit(docs/**) או MultiEdit(docs/**), וב-Read(docs/**) במקום Glob(docs/**). כלל על שם כלי בלי נתיב, כמו deny ל-Write, כן מותאם ברמת הכלי. דורש v2.1.210 ומעלה.

כללי deny של Read ו-Edit חלים על כלי הקבצים המובנים, על פקודות קובץ מוכרות ב-Bash כמו cat, head, tail, sed, ו-tee, ועל יעדי הפניות. הם אינם חלים על פקודה שקוראת קבצים בלי לנקוב בשמם, כמו grep -r pattern . מהתיקייה שמחזיקה את הקובץ, ולא על תהליך משנה שפותח קבצים בעצמו. לאכיפה ברמת מערכת ההפעלה מפעילים את ה-sandbox.

שני סוגי הכללים משתמשים בתחביר gitignore, עם ארבעה סוגי תבנית:

תבנית כמו /Users/alice/file אינה נתיב מוחלט. לוכסן מוביל יחיד מעגן למקור ההגדרות, לא לשורש. לנתיב מוחלט משתמשים ב-//Users/alice/file.

כלל שמוסיפים דרך /permissions עוקב אחרי השורה של הקובץ ששומרים אליו. כללי הגדרות מקומיות מעוגנים לספריית העבודה הראשית של הסשן, לא לשורש המאגר שבו הקובץ נשמר מגרסה v2.1.211. בסשן worktree, כלל משותף כמו Edit(/src/**) מתאים ל-src/ של אותו worktree. כלל deny כמו Read(/secrets/**) בהגדרות משתמש חוסם ~/.claude/secrets/**, לא תיקיית secrets בפרויקט. כדי שכלל בהגדרות משתמש יחול בתוך כל פרויקט משתמשים בנתיב // או ~/.

ב-Windows נתיבים מנורמלים לצורת POSIX לפני ההתאמה. C:\Users\alice הופך ל-/c/Users/alice, ולכן //c/**/.env מתאים לקובצי .env בכל מקום בכונן. לכל הכוננים משתמשים ב-//**/.env.

כלל מתאים רק לקבצים מתחת לעוגן שלו. שם קובץ חשוף עוקב אחרי gitignore ומתאים בכל עומק, כך ש-Read(.env) ו-Read(**/.env) שקולים.

דוגמאות עוגן: Edit(/docs/**) מתאים ל-<primary working directory>/docs/, לא ל-/docs/ ולא ל-<primary working directory>/.claude/docs/. Read(~/.zshrc) קורא את .zshrc בתיקיית הבית. Edit(//tmp/scratch.txt) עורך את הנתיב המוחלט /tmp/scratch.txt.

תבנית יחסית עם מקטע תיקייה יחיד, כמו src/**, תלויה בסוג הכלל:

• כללי allow: Edit(src/**) מתאים רק ל-<cwd>/src ולקבצים שמתחתיו. לשם תיקייה בכל עומק כותבים Edit(**/src/**).
• כללי deny ו-ask: Read(secrets/**) מתאים לתיקייה בשם secrets בכל עומק מתחת לספרייה הנוכחית.

כל צורת תבנית אחרת מתאימה באותו עומק בכל סוג כלל. ב-gitignore, * מתאים בתוך מקטע נתיב אחד, ו-** מתאים לרוחב תיקיות.

כשמאשרים נתיב עם "Yes, and don't ask again", תווי תבנית gitignore בנתיב, כמו [, ], ו-*, עוברים escaping כדי שהכלל יתאים רק לנתיב המילולי. כללים שכותבים בעצמכם אינם עוברים escaping. לפני v2.1.202 הנתיב נשמר בלי escaping, כך שכלל שנוצר לתיקייה בשם [2024-06] Reports יכול היה לא להתאים לנתיב שלה או להתאים לתיקיות אחיות שלא התכוונו אליהן. אין צורך ב-escaping לסוגריים, כך ש-Edit(./Finance (2024)/**) מתאים לתיקייה כפי שהיא כתובה. כלל deny או ask שהנתיב שלו אינו שמיש כתבנית gitignore עדיין שומר על הנתיב המדויק. כלל allow עם תבנית לא שמישה אינו מאשר דבר.

תבנית deny או ask שמתחילה ב-! היא שלילת gitignore. היא מוציאה את הנתיבים שהיא מתאימה להם מכללי path או ./path שרשומים לפניה באותו קובץ. באותה רשימת deny, Read(*.env) ואחריו Read(!sample.env) חוסמים כל קובץ שהשם שלו מסתיים ב-.env בכל עומק, חוץ מקבצים בשם sample.env. ! ראשון אינו מוציא דבר. ההוצאה מגיעה רק לכללים מאותו מקור. Read(!.env) בהגדרות פרויקט או ב---disallowedTools אינו מבטל Read(./.env) מהגדרות מנוהלות או מקובץ אחר. קלוד קוד קורא תבנית ! יחסית לספרייה הנוכחית גם כשאחרי ! באים /, ~/, או //, ולכן אי אפשר להוציא מכלל שמעוגן באחת מהקידומות האלה. Read(!~/notes/public/**) אינו מוציא דבר מ-Read(~/notes/**). אי אפשר גם לפתוח מחדש קובץ בתוך תיקייה שכלל חוסם כולה: עם Read(secrets/**) ו-Read(!secrets/public/**), secrets/public נשאר חסום.

כשנתיב עובר דרך symlink, הבדיקה מכסה את הנתיב שקלוד ביקש ואת הקובץ שהוא מפוענח אליו. זה חל על symbolic links ב-macOS, Linux ו-Windows, ועל directory junctions ב-Windows.

• כללי allow: חלים רק כשגם הנתיב המבוקש וגם הקובץ שהוא מפוענח אליו מתאימים.
• כללי deny: חלים כשאחד מהשניים מתאים. עם Read(./project/**) מותר ו-Read(~/.ssh/**) אסור, symlink ב-./project/key שמצביע אל ~/.ssh/id_rsa נחסם.

ב-macOS וב-Linux, כלל deny או ask שנכתב דרך תיקיית symlink עם תבנית //, ~/, או / חל גם במיקום האמיתי. למשל כש-/etc מפוענח אל /private/etc, Read(//etc/**) חוסם גם את /private/etc/hosts. לפני v2.1.268 כלל כזה לא חל על נתיב שניתן במיקום האמיתי. Grep ו-Glob מחפשים בתיקייה שארגומנט path מפוענח אליה, וכללי Read ב-deny חלים עליה.

אם הנתיב שקלוד מבקש לערוך או לכתוב הוא עצמו symlink, כלי Edit ו-Write מסרבים לכתיבה ומפנים את קלוד אל יעד הקישור. כתיבה עדיין יכולה לעבור דרך symlink כשתיקייה בדרך היא symlink, או כשפקודת Bash או PowerShell כותבת. אם הנתיב המבוקש בתוך תיקיות העבודה והקובץ שהוא מפוענח אליו אינו, הכתיבה אינה מאושרת אוטומטית במצב acceptEdits. במצב auto, אלא אם כלל allow מאשר את הכתיבה, מוצגת בקשה במקום שהמסווג יכריע, והבקשה מציינת את הנתיב שהכתיבה מפוענחת אליו. אם הפענוח מגיע לנתיב מוגן שהנתיב המבוקש אינו מציין, במקום שהטבלה מנתבת למסווג מוצגת בקשה. כשאי אפשר לקבוע לאן נתיב מוביל, למשל בלולאת symlinks, כלי Read, Edit ו-Write מסרבים. כשהכלי פותח את הקובץ שאושר, הוא מוודא שהנתיב עדיין מפוענח למיקום שהבדיקה אישרה.

#נתיבי רשת

כשכלי קריאת קבצים כמו Read, Grep ו-Glob קוראים מנתיב רשת, הקריאה מקבלת בדיקת הרשאה משלה. נתיב רשת הוא נתיב שיכול להגיע למחשב אחר: ב-Windows נתיב UNC כמו \\server\share\file, וב-macOS וב-Linux נתיב automount של /net כמו /net/fileserver/notes.txt. איתור הנתיב יכול לפנות למארח שהוא מציין, וב-Windows הפנייה יכולה לשלוח למארח את האישורים שלך. לפקודות מעטפת יש בדיקה משלהן: במצב Manual, פקודת Bash או PowerShell לקריאה בלבד שהארגומנטים שלה כוללים נתיב UNC עדיין מבקשת אישור ב-Windows.

בקלוד קוד v2.1.292 ומעלה, אלה משאירים את הבקשה במקום:

• כללי allow: כלל אינו מאשר מראש את הקריאה, כולל כלל על הכלי כולו כמו Read.
• hooks מסוג PreToolUse: hook שמחזיר "allow" אינו מדלג על הבקשה.
• מצב auto: הבקשה מגיעה אליך, והמסווג אינו מכריע את הקריאה.

במצב dontAsk הקריאה נדחית. במצב bypassPermissions, ובסשן טרמינל אינטראקטיבי במצב plan עם הרשאות bypass זמינות, הקריאה רצה בלי הבקשה הזו.

כדי לקרוא קבצים בשיתוף רשת בלי הבקשה, נותנים לשיתוף נתיב מקומי קודם:

• Windows: ממפים את השיתוף לאות כונן ומעבירים את הכונן עם --add-dir בהפעלה.
• macOS ו-Linux: מרכיבים את השיתוף בנתיב מקומי, למשל תיקייה תחת /mnt או /Volumes, וקוראים את הקבצים משם.

#WebFetch, MCP, סוכנים ו-Cd

כללי WebFetch משתמשים בקידומת domain: ומתאימים ל-hostname, בלי תלות ברישיות, עם *, ותו . סופי מוסר מהכלל ומה-hostname, כך ש-example.com. ו-example.com נחשבים אותו דבר. WebFetch(domain:example.com) מתאים רק ל-example.com עצמו. כדי לכסות גם תת דומיינים מוסיפים WebFetch(domain:*.example.com). WebFetch(domain:*.example.com) מתאים לכל תת דומיין בכל עומק, לא ל-example.com עצמו. WebFetch(domain:*) מתאים לכל דומיין ואינו זהה לכלל WebFetch חשוף. בכל מקום שאינו *. מוביל או * חשוף, התו הכללי מתאים רק לטקסט בין שתי נקודות, כך ש-WebFetch(domain:example.*) מתאים ל-example.org ולא ל-example.evil.com. כך תו כללי בסוף אינו מתאים לדומיין שחוצה נקודה, וגם לא לדומיין שאפשר לרשום כדי לעבור את הנקודה. תווים כלליים בכללי WebFetch דורשים v2.1.172 ומעלה כדי להתאים לשליפות.

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

מצב הרשאה קובע אילו פעולות קלוד יכול לבצע בסשן בלי לשאול אותך קודם. מחליפים מצב עם Shift+Tab ב-CLI, עם מחוון המצב בהרחבת VS Code, או עם בורר המצב באפליקציית Desktop.

כאשר קלוד קוד פועל אצלך, הוא קורא קבצים, מריץ פקודות מעטפת ויכול לגשת לרשת. במצב Manual, קלוד קוד עוצר ושואל לפני רוב הפעולות שעורכות קבצים, מריצות פקודות מעטפת או ניגשות לרשת. במצב auto, מודל שני, המסווג (classifier), בודק את הפעולות במקומך. איך המסווג מעריך פעולות מפרט אילו פעולות הוא בודק ואילו מדלגות עליו.

החל מקלוד קוד v2.1.283, מצב auto הוא מצב הפתיחה המובנה לסשנים אינטראקטיביים בטרמינל ובהרחבת VS Code, בכל תוכנית ואצל כל ספק. בגרסאות מוקדמות יותר זה מצב הפתיחה המובנה רק בתוכניות Pro, Max ו-Team. הסעיף על מצב הפתיחה מפרט את המשטחים וההגדרות שמשנים את המצב שבו סשן נפתח. באפשרותך לשנות את מצב ההרשאה של סשן פעיל בכל עת.

מצב ההרשאה הוא קו הבסיס. מעל המצב אפשר להוסיף כללי הרשאה כדי לאשר מראש או לחסום כלים ספציפיים. כללי deny חוסמים בכל מצב, כולל במצב bypassPermissions. כללי allow אינם משפיעים במצב bypassPermissions. כללי deny ו-ask אינם חלים על EndConversation כל עוד נותר לקלוד כלי אחר לקרוא לו.

הכללים נבדקים בסדר קבוע: קודם deny, אחר כך ask, אחר כך allow. ההתאמה הראשונה מנצחת, ורוחב הכלל אינו משנה את הסדר. כלל deny רחב כמו Bash(aws *) חוסם כל קריאה תואמת, כולל קריאה שמתאימה גם לכלל allow צר יותר כמו Bash(aws s3 ls). כלל allow אינו יוצר חריג מתוך כלל deny. אותו סדר חל גם בין ask ל-allow: כלל ask תואם מציג בקשת אישור גם כשכלל allow ספציפי יותר מתאים לאותה קריאה.

כלל deny על שם כלי בלבד, כמו Bash, מסיר את הכלי לגמרי מההקשר של קלוד, וקלוד אינו רואה אותו. אם מוסיפים כלל כזה באמצע סשן, קלוד אינו יכול לקרוא לכלי החל מקריאת הכלי הבאה. כלל עם תחום, כמו Bash(rm *), משאיר את הכלי זמין וחוסם קריאות תואמות כשקלוד מנסה אותן. הסרה לפי שם בלבד חלה על כל כלי מלבד EndConversation.

ההרשאות נאכפות על ידי קלוד קוד, לא על ידי המודל. הוראות ב-CLAUDE.md או בפרומפט משפיעות על מה שקלוד מנסה לעשות. כדי להעניק או לבטל גישה השתמשו ב-/permissions, בכללים המתוארים כאן, במצב הרשאה, או ב-hook מסוג PreToolUse.

כתיבה לנתיבים מוגנים כמו .git ו-.claude אינה מאושרת אוטומטית, חוץ מבמצב bypassPermissions ובסשני plan שבהם הרשאות bypass זמינות: סשנים שהופעלו בטרמינל אינטראקטיבי באופן שמכניס את bypassPermissions למחזור המצבים. במצב bypassPermissions קלוד קוד מדלג על בקשות אישור, כולל כתיבה לנתיבים האלה. אמצעי ההגנה על הודעות בין סשנים ממשיכים לחול. השתמשו במצב זה רק בסביבות מבודדות כמו מכולות, מכונות וירטואליות, או dev containers בלי גישה לאינטרנט, שבהם קלוד קוד אינו יכול לפגוע במערכת המארחת. רשימת הנתיבים והתוצאה בכל מצב מופיעות בסעיף נתיבים מוגנים.

#פעולות שאף מצב אינו מאשר אוטומטית

קלוד קוד אינו מאשר אוטומטית את הפעולות הבאות באף מצב, כולל במצב bypassPermissions:

• כלים שמתאימים לכלל ask מפורש.
• כלי מחברים (connectors) שהארגון הגדיר למצב ask, בסשנים שבהם ההגדרה מגיעה לקלוד קוד.
• כלים הדורשים אינטראקציה עם המשתמש: הכלי המובנה AskUserQuestion, וכלי MCP המסומנים ב-requiresUserInteraction.
• מחיקות rm ו-rmdir המכוונות לנתיב קריטי, ופקודות Bash שסומנו Dangerous rm operation not ruled out, שאף כלל allow או hook מסוג PreToolUse עם "allow" אינם מאשרים.
• אמצעי ההגנה על הודעות בין סשנים (cross-session messaging).
• קריאות מחוץ לספריות העבודה כאשר ההגדרה permissions.blockReadsOutsideWorkingDirectories מופעלת: פקודות Bash מוכרות לקריאת קבצים מציגות בקשת אישור גם במצב auto וגם במצב bypassPermissions, וכך גם כל ניסיון ריצה חוזר מחוץ ל-sandbox שדורש אישור כדי לרוץ מחוץ ל-sandbox. דורש קלוד קוד v2.1.257 ומעלה. פקודה שמנתח המעטפת אינו יכול לעקוב אחריה, למשל פקודה שמשנה ספרייה יותר מפעם אחת או מריצה תת מעטפת (subshell), מציגה בקשת אישור באותו אופן גם כשהיא אינה מציינת נתיב חיצוני. בקשת האישור הזו אינה חלה כאשר הפקודה רצה בתוך ה-sandbox וה-sandbox אוכף את החסימה.

#מצבי הרשאות זמינים

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

המצב שבודק כל פעולה נקרא Manual ב-CLI, ב-claude --help, בהרחבות VS Code ו-JetBrains, ובאפליקציית Desktop. ערך ההגדרה שלו הוא default, וזה הערך שבו משתמשים ב-hooks ובאינטגרציות SDK. ה-CLI מקבל את הכינוי manual בכל מקום שבו מקלידים את הערך, למשל claude --permission-mode manual או "defaultMode": "manual".

כדי להסיר את מצב auto כך שאי אפשר לבחור אותו, קובעים את permissions.disableAutoMode לערך "disable". כדי למנוע שימוש במצב bypassPermissions, קובעים את permissions.disableBypassPermissionsMode לערך "disable". את שני המפתחות אפשר לקבוע בכל קובץ הגדרות. הם שימושיים במיוחד בהגדרות מנוהלות, שם אי אפשר לדרוס אותם. disableBypassPermissionsMode פועל מכל היקף, ומשתמש יכול לקבוע אותו בהגדרות שלו ולנעול את עצמו מחוץ למצב.

במצב dontAsk נדחים גם AskUserQuestion, כלי MCP עם requiresUserInteraction (דורש v2.1.199 ומעלה), וכלי מחברים שהארגון הגדיר ל-ask, גם אם כלל allow מתאים להם. הסימון הרשמי לכלי MCP כזה הוא _meta["anthropic/requiresUserInteraction"]: כרטיס האישור דורש תשובה, והמצב אינו אוסף אותה. מחיקת נתיב קריטי ב-rm או rmdir נדחית גם כשכלל allow או hook עם "allow" מתאימים. קריאה מנתיב רשת נדחית באותו אופן. קריאות ש-hook מסוג PreToolUse מאשר עדיין רצות, יחד עם פעולות שאינן דורשות אישור במצב Manual, כולל פקודות Bash לקריאה בלבד, ועם כלים שכלל permissions.allow מאשר. שורת המצב מציגה ⏵⏵ don't ask on. הסשן אינו ממתין לקלט. סשנים בענן מתעלמים מ-defaultMode: "dontAsk".

פותחים במצב dontAsk כך:

claude --permission-mode dontAsk

#אישור עריכות במצב acceptEdits

במצב acceptEdits קלוד יוצר ועורך קבצים בספריית העבודה בלי בקשה. שורת המצב מציגה ⏵⏵ accept edits on. בנוסף לעריכות, מאושרות אוטומטית פקודות Bash נפוצות: mkdir, touch, rm, rmdir, mv, cp, ו-sed. חוץ מ-touch, אותו אישור חל גם כשלפניהן משתני סביבה בטוחים כמו LANG=C או NO_COLOR=1, או עטיפות תהליך כמו timeout, nice, או nohup. האישור חל רק על נתיבים בתוך ספריית העבודה או additionalDirectories, ואחרי בדיקת symlink. נתיב מחוץ לתחום, כתיבה לנתיב מוגן, rm ו-rmdir לנתיב קריטי, touch עם משהו מעבר לנתיב קובץ פשוט (אפשרות, glob, או קידומת כמו timeout 5 או LANG=C), ושאר פקודות Bash מלבד קבוצת הקריאה המובנית, עדיין מבקשים אישור.

כשכלי PowerShell מופעל, מאושרים גם Set-Content, Add-Content, Clear-Content, ו-Remove-Item על נתיבים בתחום, יחד עם כינויים נפוצים. אותם כללי תחום ונתיב מוגן חלים, ול-Remove-Item יש בדיקה נפרדת. ארגומנט מיקומי שמכיל מרכאה, למשל הגרש ב-Set-Content .\notes.txt "It's done", עדיין מבקש אישור גם בנתיב בתחום, כי אי אפשר לאמת סטטית ארגומנט שהקריאה המצוטטת והלא מצוטטת שלו שונות. מעבירים את התוכן בפרמטר מפורש כמו -Value.

נכנסים ממצב Manual בלחיצת Shift+Tab אחת, או פותחים עם:

claude --permission-mode acceptEdits

המצב מתאים כשסוקרים את השינויים אחר כך בעורך או ב-git diff, בלי לאשר כל עריכה בתוך השיחה.

#תכנון לפני עריכה

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

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

1. סשן טרמינל אינטראקטיבי עם הרשאות bypass זמינות: לא המסווג ולא בקשת אישור חלים על פקודות התכנון. כללי ask מפורשים, ומחיקות rm ו-rmdir לנתיב קריטי, עדיין מבקשים אישור.
2. מצב auto זמין ו-useAutoModeDuringPlan פועל, וזו ברירת המחדל: המסווג בודק פקודות מעטפת שאינן מחיקת נתיב קריטי, במקום לבקש ממך. פקודה שאושרה רצה, ופקודה שנדחתה נחסמת. ערך false מכובד מכל מקור מנוהל, מ---settings, מ-~/.claude/settings.json, או מ-.claude/settings.local.json, גם כשהמקור המנוהל המנצח קובע true. ערך false בקובץ הפרויקט המשותף .claude/settings.json אינו נכנס לתוקף.
3. מצב auto אינו זמין, או שההגדרה כבויה: פקודות מחוץ לקבוצת הקריאה המובנית מבקשות אישור, גם כשמצב auto-allow של ה-sandbox פועל.

נכנסים עם Shift+Tab, עם קידומת /plan לפרומפט בודד, או עם claude --permission-mode plan. לחיצת Shift+Tab נוספת יוצאת בלי לאשר תוכנית.

כשהתוכנית מוכנה אפשר לבחור:

• Yes, and use auto mode: אישור ומעבר למצב auto. אם המצב אינו זמין לסשן, למשל כי הארגון כיבה אותו, האפשרות נקראת Yes, auto-accept edits. אם הסשן נפתח עם הרשאות bypass, האפשרות נקראת Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session.
• Yes, manually approve edits: אישור, וכל עריכה נבדקת בנפרד.
• No, keep planning: נשארים במצב plan.

אישור תוכנית יוצא ממצב plan ועובר למצב שכל אפשרות מתארת. כדי לתכנן שוב חוזרים עם Shift+Tab, או מוסיפים /plan לפרומפט הבא. Ctrl+G פותח את התוכנית בעורך ברירת המחדל לפני שקלוד ממשיך. כש-showClearContextOnPlanAccept פועל, נוסף בראש הרשימה אישור שמנקה את הקשר התכנון. קבלת תוכנית גם נותנת לסשן כותרת שנוצרה מהתוכנית, אלא אם כבר נתתם שם.

כדי שמצב plan יהיה ברירת המחדל לסשני טרמינל של פרויקט, קובעים defaultMode ל-plan ב-.claude/settings.json. שיחות שהרחבת VS Code פותחת אינן קוראות את הגדרות הפרויקט עבור מצב הפתיחה. שם קובעים claudeCode.initialPermissionMode ל-plan בהגדרות המשתמש של VS Code.

#זמינות מצב auto

מצב auto מריץ בלי בקשות שגרתיות. מסווג נפרד בודק פעולות לפני שהן רצות, וחוסם מה שחורג מהבקשה, מכוון לתשתית לא מוכרת, או נראה מונע מתוכן עוין שקלוד קרא. כלל ask מפורש עדיין כופה בקשה. עם קלוד קוד v2.1.283 ומעלה, מצב auto הוא מצב הפתיחה המובנה לסשן טרמינל אינטראקטיבי ולהרחבת VS Code, בכל תוכנית ואצל כל ספק. בגרסאות מוקדמות יותר זה מצב הפתיחה המובנה רק בתוכניות Pro, Max ו-Team. המסווג גם בודק כל הודעה שקלוד שולח לסוכן אחר עם SendMessage, טקסט רגיל או הודעת צוות סוכנים, לפני המסירה, גם במצב auto וגם במצב plan כשהמסווג בודק פקודות. בדיקת השליחה דורשת v2.1.222 ומעלה.

כברירת מחדל המסווג אינו בודק מחיקות rm ו-rmdir לנתיב קריטי כמו rm -rf / או rm -rf ~. מה שקורה להן מופיע בסעיף נתיבים קריטיים.

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

המצב זמין רק כשכל אלה מתקיימים:

• תוכנית: כל התוכניות.
• ארגון: ב-Team וב-Enterprise המצב זמין כברירת מחדל. מנהלים יכולים לכבות אותו עם permissions.disableAutoMode בערך "disable" בהגדרות מנוהלות.
• מודל: ב-Anthropic API וב-Claude Platform on AWS: Claude Opus 4.6 ומעלה, Sonnet 4.6 ומעלה, Haiku 5.5, או מודל Fable. ב-Amazon Bedrock, ב-Agent Platform של Google Cloud, ב-Microsoft Foundry, ובסשני Claude apps gateway מחוברים: רק Claude Sonnet 5 ומעלה, Opus 4.7 ומעלה, Haiku 5.5, ומודלי Fable. מודלים ישנים יותר, כולל Sonnet 4.5, Opus 4.5, Haiku 4.5, ומודלי claude-3, אינם נתמכים אצל אף ספק.
• ספק: זמין כברירת מחדל ב-Anthropic API, ב-Claude Platform on AWS, ב-Amazon Bedrock, ב-Agent Platform של Google Cloud, ב-Microsoft Foundry, ובסשני Claude apps gateway מחוברים.

אם קלוד קוד מדווח שהמצב אינו זמין, בודקים את הדרישות האלה ואם קובץ הגדרות קובע disableAutoMode. Anthropic יכולה גם לכבות את המצב זמנית בצד השרת, או שהשרת דחה אותו לחשבון. סשן שקיבל אחת מהתשובות האלה משאיר את המצב כבוי עד שהסשן נגמר.

הודעה נפרדת שמציינת מודל ואומרת שמצב auto אינו יכול לקבוע את הבטיחות של פעולה פירושה שבקשת מסווג נכשלה. זה בדרך כלל חולף, אבל ב-Amazon Bedrock זה יכול לחזור עד שהחשבון יכול להפעיל את המודל שצוין.

אם defaultMode: "auto" בקובץ הגדרות וסשן טרמינל נפתח במצב Manual בלי שגיאה, הערך כנראה ב-.claude/settings.json או ב-.claude/settings.local.json. משם "auto" אינו נכנס לתוקף. מעבירים אותו אל ~/.claude/settings.json. לשיחה שהרחבת VS Code פתחה, בודקים את רשימת ההרחבה בסעיף החלפת מצב.

אצל Bedrock, Agent Platform, Foundry, וסשני Claude apps gateway מחוברים, המצב זמין כברירת מחדל. עם v2.1.283 ומעלה הוא גם מצב הפתיחה המובנה לסשן טרמינל אינטראקטיבי ולהרחבת VS Code, בגרסאות שהטבלה בסעיף מצב הפתיחה מפרטת. רק Sonnet 5 ומעלה, Opus 4.7 ומעלה, Haiku 5.5, ומודלי Fable נתמכים שם. במודל אחר הסשן נפתח במצב Manual. מצב auto עם Haiku 5.5 אצל הספקים האלה דורש קלוד קוד v2.1.293 ומעלה.

disableAutoMode בערך "disable" בהגדרות מנוהלות מסיר את auto ממחזור Shift+Tab, וסשן שנפתח עם --permission-mode auto נפתח במצב Manual. סשן שכבר רץ במצב auto יוצא ממנו כשההגדרה מגיעה ממקור שמנהל פרס, ומציג auto mode disabled by settings. לפני v2.1.251 סשן רץ שמר את המצב עד שנתיים. מגרסה v2.1.158 עד v2.1.206 המצב היה כבוי אצל הספקים האלה עד CLAUDE_CODE_ENABLE_AUTO_MODE=1, וקלוד קוד התעלם מ-defaultMode: "auto" אלא אם המשתנה גם הוגדר. המשתנה עדיין מתקבל לתאימות ואין לו השפעה מגרסה v2.1.207.

#בדיקת מסווג בצד השרת

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

• חיבור ישיר ל-Anthropic API: בסשן טרמינל אינטראקטיבי, וגם בסשני -p, Agent SDK, הרחבת VS Code ואפליקציית Desktop, בכל תוכנית ובכל סוג חשבון, כש-Anthropic מפיצה את זה. בטרמינל אינטראקטיבי נדרש v2.1.271 ומעלה ב-Pro, Max ו-Team, ו-v2.1.278 ומעלה ב-Enterprise ובחשבונות Claude API. בסשני -p, Agent SDK, הרחבת VS Code ו-Desktop נדרש v2.1.281 ומעלה. מגרסה v2.1.282, סשן שאינו שולף דגלי תכונות, למשל כי טלמטריה כבויה, מבקש מהשרת כברירת מחדל בכל סוג סשן.
• ספק ענן, או שער או פרוקסי LLM: ב-Claude Platform on AWS, ב-Amazon Bedrock, ב-Agent Platform של Google Cloud, וב-Microsoft Foundry, וגם כש-ANTHROPIC_BASE_URL מצביע לשער או לפרוקסי, בכל תוכנית. בקשה כברירת מחדל דורשת v2.1.278 ומעלה.
• סשן Claude apps gateway מחובר: דורש v2.1.280 ומעלה.
• סשן ענן בסביבה ש-Anthropic מארחת: בכל תוכנית, כשמתחילים אותו מהאינטרנט, מהאפליקציה בנייד, או מאפליקציית Desktop כשנבחר Cloud. סשן שמשימה מתוזמנת בענן מתחילה מבקש מהשרת כש-Anthropic מפיצה את זה.

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

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

כדי לדלג על השרת ולהשתמש תמיד בבקשות המסווג של קלוד קוד, קובעים CLAUDE_CODE_AUTO_MODE_SERVER=0. בחיבור ישיר ל-Anthropic API המשתנה דורש v2.1.281 ומעלה. שם, ערך 1 מפעיל בדיקת שרת בסשן שעדיין אין לו אותה, אלא אם הוגדר גם CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1. אם המשתנה הזה מוגדר ו-CLAUDE_CODE_AUTO_MODE_SERVER לא הוגדר, קלוד קוד גם מפסיק לבקש מהשרת, חוץ מהמקרים שמתוארים בכיבוי יכולות טרום הפצה.

#מה המסווג חוסם ומה מותר

המסווג סומך על ספריית העבודה ועל ה-remotes שהיו מוגדרים לה כשהסשן התחיל. remote שנוסף או שהופנה מחדש במהלך הסשן עם git remote add או git remote set-url אינו מהימן. לפני v2.1.200 גם remote שנוסף באמצע סשן היה מהימן. כל השאר נחשב חיצוני עד שמגדירים תשתית מהימנה ב-autoMode.environment.

בין החסימות כברירת מחדל: הורדה והרצה של קוד כמו curl | bash, שליחת נתונים רגישים החוצה, פריסות ייצור ומיגרציות, מחיקה המונית באחסון ענן, הענקת הרשאות IAM או מאגר, שינוי תשתית משותפת, השמדה בלתי הפיכה של קבצים שהיו לפני הסשן, force push, קומיט או push שישלחו סודות או נתונים רגישים אל מחוץ למאגר כשהשינוי רץ, או ירחיבו מה שפריסה חושפת. זה כולל workflow של CI או הגדרת פריסה שמעבירים סוד ליעד שעדיין אינו מקבל אותו, סקריפט או שלב התקנה שקוראים ממחסן סודות ושולחים את הנתונים החוצה, ושינוי הגדרה שמרחיב מה שפריסה מפרסמת, כמו registry, visibility, artifact, או sourcemap. הבדיקה חלה על כל ענף, גם כשהמאגר ציבורי, ומופעלת בקומיט או ב-push בין שהם מפעילים את הצינור ובין שלא. כדי לנקות אותה צריך לנקוב באפקט ההרצה, לא רק בקומיט או ב-push. לפני v2.1.211 הבדיקה הזו הייתה מוגבלת לענף ברירת המחדל: דחיפה לשם נחסמה כשנשאה תוכן רגיש, שינויים שהוסתרו או תוארו לא נכון ביחס למה שביקשתם, תוכן שהובא מחוץ למאגר, או עקיפה של סקירה שביקשתם.

עוד חסימות: git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, ו-git stash clear, שהמסווג מניח שיזרקו עבודה שלא נשמרה, git commit --amend כשהקומיט ב-HEAD לא נוצר בסשן, וגם כשהקומיט כבר נדחף (מגרסה v2.1.198, חוץ מניסוח מחדש של ההודעה בלבד: --amend -m בלי דבר חדש ב-stage, על קומיט שקלוד יצר בסשן), terraform destroy, pulumi destroy, cdk destroy, terragrunt destroy, והחלת תוכנית שמשמידה משאבים, כתיבה למנהל סודות או שינוי DNS או אישורי TLS, מיזוג בקשת משיכה שאף אדם לא אישר, אישור בקשת המשיכה של קלוד עצמו, כיבוי בדיקות CI, תגובה שהיא פקודה לאוטומציה, כמו atlantis apply או /deploy ו-/merge של בוט, הפעלה, העלאה הדרגתית או מחיקה של דגל תכונה בייצור, החלת שינויי תשתית בהיקף IaC מוגן, או ריקון והסרת צמתי אשכול, כתיבה לאשכול חישוב משותף מעבר למשאב שצוין, כמו בורר תוויות או --all שתופס עבודות של משתמשים אחרים, יצירת משאבי Kubernetes שרצים על כל צומת או מיירטים תעבורת אשכול, כמו DaemonSet ו-admission webhook, מעטפת אינטראקטיבית או port-forward ליעד מרוחק רגיש, מנהרה או reverse shell שהופכים שירות מקומי נגיש מהאינטרנט הציבורי, הדפסת אישור חי לתמליל או לקובץ, גישה למיקום נתונים רגיש בסביבה, העתקת נתונים ממנו, או שליחה ממנו לקהל שהרשומה מוציאה, עקיפת מרשם חבילות פנימי כשהמרשם או מראה רשומים ב-environment או כשאמרתם לקלוד בשיחה שהוא קיים, דגל שמנטרל הגנה כמו --insecure, לולאת סוכן אוטונומית בלי אישור אנושי או sandbox, כולל כזו שהופעלה עם --dangerously-skip-permissions או --no-sandbox, וגם סוכן צד שלישי או eval harness עם --yes-always, ופעולות דפדפן של Claude in Chrome שעלולות לשלוח תוכן דף, עוגיות או אישורים אל מחוץ למקור.

מגרסאות מאוחרות נוספות חסימות, בין היתר מחיקת קבצים ב-/tmp, ב-$TMPDIR, או בתיקיית scratch או מטמון משותפת לפי wildcard, glob או מסנן גיל, ולא לפי נתיב מפורש, פרטים רגישים בתוכן יוצא, שליחת הקשות למקטע tmux של קלוד קוד עצמו כדי להפעיל את הממשק שלו (המסווג מתייחס לזה כשינוי ההרשאות או הפיקוח של קלוד על עצמו), הערה שמכבה, מחיקה, או העברה כפויה של בדיקה או assertion שמגנים על התנהגות אבטחה, כמו אימות, בקרת גישה, אימות קלט, או sandbox, מחיקה או פירוק של משאב stateful שקלוד לא יצר בסשן, כשאין כלל מחיקה ספציפי יותר ולא נקבתם במשאב, הפניית URL בסיס, פרוקסי, webhook או מראה של registry לצד שלישי, כולל בקובצי דוגמה כמו .env.example, שינוי יעד הדחיפה עם git remote set-url או git remote add אלא אם ציינתם את ה-remote החדש, דחיפת סודות או נתונים אישיים או שהופקדו למאגר ציבורי, או דחיפת חומר חסוי שאינו חלק מעבודת המאגר עצמו. חריג אחד לנתונים אישיים או שהופקדו הוא נושא המאגר עצמו כשמדובר ב-dotfiles. תוכן ממאגר פרטי שמגיע לכל משטח ציבורי נחסם באותו אופן. שני החידודים האלה דורשים v2.1.203 ומעלה. לפני v2.1.203 נתונים אישיים קובצו עם חומר חסוי ונחסמו רק כשלא היו חלק מעבודת המאגר. כשנראות המאגר אינה ידועה, המסווג אינו חוסם על זה לבדו ושופט את התוכן מול שאר הכללים. עוד: פתיחת בקשת משיכה למאגר או לארגון אחר, gh repo fork, או דחיפה למאגר צד שלישי, אלא אם ציינתם את היעד, תוכן מחנות מקומי רגיש, או מקובץ שהשם, הנתיב או הסוג שלו מסמנים אותו כרגיש, שנכנס לקומיט, ל-push, לטקסט של PR או issue, ל-gist או paste, או לפרסום חבילה, אלא אם ציינתם גם את המקור וגם את היעד (מגרסה v2.1.203, ומאגר פרטי אינו מנקה את זה). נספרים תמלילי סשן ויומני שיחה, תיקיות נקודה של אישורים והגדרות כמו מפתחות SSH, אישורי ענן, פרופילי דפדפן והיסטוריית מעטפת, וייצוא נתוני משתמש.

מגרסה v2.1.205 נחסמות גם כתיבה לתמלילי סשן, קובצי ההיסטוריה .jsonl תחת ~/.claude/projects/ או תיקיית ההגדרות שהוגדרה, ישירות או דרך פקודת מעטפת, כולל שורות ה-metadata שקלוד קוד מוסיף לכל רשומה לבדיקות שלו. קריאת תמליל אינה נחסמת. באותה גרסה נחסמת גם מחיקה רקורסיבית כפויה כמו rm -rf "$VAR" או Remove-Item -Recurse -Force $dir, כשהיעד הוא משתנה מעטפת בלי השמה בשיחה שהמסווג רואה, או glob שמושרש במשתנה כזה. הערך הגיע רק מפלט של פקודה קודמת, שהמסווג אינו מקבל, ולכן הוא אינו יכול לאמת את יעד המחיקה מול שאר כללי המחיקה. החסימה מתנקה כשמנקבים בנתיב המדויק, או כשקלוד מריץ שוב עם הנתיב המילולי בפקודה. מחיקה שהמסווג יכול לפענח את היעד שלה אינה מושפעת. glob ישירות מתחת למשתנה, כמו rm -rf "$VAR"/*, הוא נתיב קריטי. יעד Remove-Item שהוא * חשוף, או שמסתיים ב-/* או \*, נדחה לפני שהמסווג רואה אותו.

בקשת אישורים מ-metadata של מכונת ענן כמו 169.254.169.254, או אימות מפורש של קריאת ענן, אשכול או registry בזהות service-account או הצומת של המכונה, הגעה למארח ציבורי בדרך שאינה בקשה ישירה, קריאת אישורים של המארח ולא של המשימה, כמו אישורי צומת או אימות registry של הצומת, וחיבור או סריקה של מכולות, pods או מכונות אחיות שקלוד לא הפעיל, או של הצומת שמתחת למכולה. קישור לשירות הדבקה, תרשים או שיתוף נתונים ציבורי, כשה-URL עצמו נושא את התוכן, נחסם מגרסה v2.1.261, אלא אם ציינתם את השירות. אם סביבה אמורה להתיר אחת מהחסימות של v2.1.257 ומעלה, מתארים אותה ברשומת Host containment ב-autoMode.environment.

פרטים רגישים בתוכן שנשלח, הועלה, פורסם או נכתב לאנשים אחרים או למערכות משותפות נחסמים כשההודעה שלכם לא אישרה את הפרטים לנמען הזה. גופי PR ו-issue, הודעות קומיט ותגובות נחשבים תוכן יוצא כשהמאגר מחוץ לגבול האמון או ציבורי, כולל מאגרים ציבוריים של הארגון עצמו. נתיבים פנימיים, שמות קוד, נתוני תשובת API חיים כמו דוא"ל או מזהי חשבון, ומזהי תשתית נחשבים פרטים רגישים. נתון אישי חי מתשובת API בגוף PR או issue, כמו כתובת דוא"ל, מזהה חשבון או ארגון, או מדד שימוש, דורש לנקוב בפרטים ובנמען בלי קשר לנראות המאגר או לגבול האמון. הבדיקה הזו דורשת v2.1.203 ומעלה.

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

הרשימות המלאות מודפסות כ-JSON עם:

claude auto-mode defaults

אם פעולות שגרתיות נחסמות, מנהל יכול להוסיף מאגרים, דליים ושירותים מהימנים דרך autoMode.environment.

מותר כברירת מחדל, בין היתר: פעולות קבצים מקומיות בספריית העבודה, התקנת תלויות שמוצהרות בקובצי נעילה או במניפסטים, קריאת .env ושליחת אישורים ל-API התואם שלהם, בקשות HTTP לקריאה בלבד, דחיפה לכל ענף של המאגר שעובדים בו כולל ענף ברירת המחדל, מחיקת העבודות המדויקות שקלוד יצר קודם באותו סשן, קריאה, סקירה או כתיבה של קוד אבטחה, הגדרות ומודלי איום כחלק מהמשימה, הודעות בין סוכנים באותו סשן מרובה סוכנים, שליחת נתונים לדומיינים, לדליים ולשירותים שרשומים ב-environment (זרימת נתונים בלבד, לא פעולות הרס או אישורים על אותה תשתית), וניווט של Claude in Chrome לדומיין פנימי מהימן, ל-localhost, או ל-URL שציינתם. ענף שאינו ברירת המחדל ושמו מסמן יעד פריסה או פרסום, כמו production או gh-pages, אינו מכוסה: המסווג שופט דחיפה לשם בפני עצמה. תוכן הדחיפה עדיין נבדק מול שאר הכללים, כללי permissions.deny עדיין יכולים לחסום את הפקודה כפי שנכתבה, והגנת הענף של ה-remote עדיין חלה. לפני v2.1.211 הותרו כברירת מחדל רק דחיפות לענף שהתחלתם עליו, לענפים שקלוד יצר, ולדחיפות שגרתיות לענף ברירת המחדל.

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

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

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

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

• חייבים לנקוב בפעולה ובפרט שהופך אותה למסוכנת, למשל הענף של force push. הפועל לבדו אינו מסיר דבר.
• אישור מכסה את הפעולה ההרסנית שצוינה. פעולה מאוחרת נחסמת שוב, אלא אם האישור ניתן כעומד. לדפוס שגרתי מוסיפים ל-autoMode.allow.
• חלק מהחסימות נשארות לפי סדר העדיפות של המסווג. כדי להריץ צעד שהוא אינו מנקה, יוצאים ממצב auto ועונים לבקשת האישור.

#סדר ההחלטה של המסווג

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

1. פעולות שמתאימות לכללי allow, ask, או deny מוכרעות מיד, עם החריגים האלה:
   • כתיבה לנתיב מוגן מנותבת למסווג גם כשכלל allow מתאים. כשהנתיב המוגן הוא הקובץ שקובץ הגדרות שהוא symlink מצביע אליו, הכתיבה יכולה לבקש אישור במקום, כפי שרשימת הנתיבים המוגנים מתארת.
   • אף כלל allow אינו מאשר rm ו-rmdir לנתיב קריטי.
   • כלי MCP עם requiresUserInteraction, וכלי מחברים שהארגון הגדיר ל-ask בסשן שבו ההגדרה מגיעה, מבקשים אישור ישירות גם כשכלל allow מתאים.
   • פקודת מעטפת עם דומיינים מותרים לאותה פקודה מנותבת למסווג גם כשכלל allow מתאים, כי הכלל מאשר את הפקודה ולא את המארחים.
   • כלל ask שמתאים לתוכן הפקודה, כמו Bash(git push *), נופל לבקשת אישור.
   • כתיבה שבדיקת symlink מפענחת לנתיב מוגן מבקשת אישור כשהנתיב שקלוד ביקש אינו מוגן בעצמו.
   • קריאה מנתיב רשת מבקשת אישור גם כשכלל allow מתאים.
2. פעולות קריאה בלבד ועריכות קבצים בספריית העבודה מאושרות אוטומטית, חוץ מכתיבה לנתיב מוגן ומהקריאה הראשונה מחוץ לתיקיות העבודה, שמבקשת אישור.
   • בסשן עם בדיקת מסווג בצד השרת, פקודות מעטפת לקריאה בלבד ופקודות ב-sandbox ממתינות לבדיקה ונחסמות אם היא מסמנת אותן.
   • כתיבה בתוך ספריית העבודה שבדיקת symlink מפענחת אל מחוץ לה מבקשת אישור.
   • כשקלוד קורא artifact שמישהו אחר יצר, חלים מקרי האישור שמפורטים בתיעוד של artifacts.
   • קריאה מנתיב רשת מבקשת אישור.
3. כל השאר הולך למסווג, חוץ ממחיקות נתיב קריטי בטיפול ברירת המחדל שלהן. כלי המחברים וכלי MCP עם requiresUserInteraction שביקשו אישור בצעד 1 אינם מגיעים למסווג, כך שאישור שהארגון דורש וצעד הסכמה אינם מאושרים אוטומטית. מוד שמתקינים ומטפל ב-tool.check יכול לאשר פעולה לפני הצעד הזה, והמסווג אינו בודק פעולה שהמוד אישר.
4. אם המסווג חוסם, קלוד מקבל את הסיבה. ברוב הסשנים הסיבה מציינת את הכלל שהותאם, כמו [Data Exfiltration], ולא הסבר כתוב.

בהרחבת VS Code, אופן האישור של פעולות דפדפן של Claude in Chrome תלוי באופן שבו הסשן התחבר לדפדפן.

בכניסה למצב auto מושמטים כללי allow רחבים שמעניקים הרצת קוד שרירותית:

• Bash(*) או PowerShell(*) גורפים.
• מפרשים עם תו כללי כמו Bash(python*).
• פקודות הרצה של מנהלי חבילות.
• כללי allow של Agent.
• כללי allow של Monitor, כי קלוד קוד מריץ פקודות Monitor דרך המעטפת.

כלל צר כמו Bash(npm test) נשאר. הכללים שהושמטו חוזרים ביציאה ממצב auto. לפני v2.1.236 כללי allow של Monitor נשארו בתוקף, כך שכלל שהתאים לכלי כולו אישר פקודות Monitor בלי בדיקת מסווג.

לפני פקודה שתזרוק עבודה שלא נשמרה, כמו git reset --hard או rm -rf, קלוד קוד עצמו מריץ git status ומראה למסווג אם יש עבודה ב-stage, ששונתה, או שאינה במעקב. קבצים שאינם במעקב מדווחים גם כש-status.showUntrackedFiles=no.

בבקשות המסווג שקלוד קוד עצמו שולח, המסווג רואה הודעות משתמש, קריאות כלים שאינן חיפושי קריאה בלבד, ואת תוכן CLAUDE.md. תוצאות כלים מוסרות מהבקשות האלה, כדי שתוכן עוין בקובץ או בדף לא יוכל להשפיע על המסווג ישירות. שדה classifierContext ב-hook מסוג PostToolUse מוסיף הקשר שהאפליקציה מספקת. השדה דורש v2.1.236 ומעלה. בדיקה נפרדת בצד השרת סורקת תוצאות כלים נכנסות ומסמנת תוכן חשוד לפני שקלוד קורא אותו.

עבודת subagent נבדקת בשלוש נקודות:

1. לפני שה-subagent מתחיל, תיאור המשימה המוקצית נבדק, ומשימה שנראית מסוכנת נחסמת בהפעלה.
2. בזמן הריצה, כל פעולה עוברת את אותו סדר החלטה, עם אותם כללי חסימה והיתר. permissionMode ב-frontmatter של ה-subagent מתעלמים ממנו.
3. בסיום, המסווג בודק את העבודה ואת הדוח הסופי לפני שההורה קורא את הדוח. אם המסווג מסמן את העבודה או את הדוח, או שבדיקת בטיחות נפרדת של ה-API מסרבת לבדיקה, הדוח עדיין נמסר עם אזהרת אבטחה בהתחלה. אם המסווג אינו זמין לבדיקה, הדוח מגיע עם הערה לאמת את העבודה לפני שפועלים לפיה.

המסווג רץ על Claude Sonnet 5 כברירת מחדל, לא על הבחירה ב-/model. מודל מסווג ש-Anthropic מגדירה בצד השרת גובר על ברירת המחדל. כשמודל הסשן הוא Claude Sonnet 4.6, או כש-availableModels מוציא את Sonnet 5, המסווג רץ על מודל הסשן, או על מודל Opus כשהסשן רץ על מודל Fable. אצל ספק שאינו Anthropic API, נפילת ה-Opus היא המודל שב-ANTHROPIC_DEFAULT_OPUS_MODEL, או Opus 5 אם לא הוגדר אחד. בקשת ה-auto הראשונה של הסשן מאמתת את ברירת המחדל Sonnet 5: אם הבקשה מצליחה, Sonnet 5 נשאר מודל המסווג של הסשן, ואם היא נכשלת כי המודל אינו זמין, הסשן משתמש בנפילה.

בתוכניות Enterprise ובחשבונות שמשתמשים ב-Claude API, ב-Claude Platform on AWS, ב-Amazon Bedrock, ב-Agent Platform של Google Cloud, או ב-Microsoft Foundry, קריאות המסווג נספרות בשימוש בטוקנים. כל בדיקה שולחת חלק מהתמליל ואת הפעולה הממתינה, ומוסיפה הלוך ושוב לפני הריצה. קריאות ועריכות בספריית העבודה מחוץ לנתיבים מוגנים מדלגות על המסווג, כך שהעומס מגיע בעיקר מפקודות מעטפת ומפעולות רשת. כשהשרת בודק את הפעולות כחלק מבקשות המודל, אין קריאות מסווג נפרדות לספירה. גישת רשת ב-sandbox אינה מוסיפה בקשת מסווג לכל חיבור: המסווג שופט את המארחים יחד עם הפקודה בבדיקה אחת, וקלוד קוד בודק כל חיבור מול הרשימה שאושרה בלי לקרוא למסווג שוב.

#כשמצב auto אינו יכול לאשר

• פעולה חסומה: מוצגת הודעה, והפעולה מופיעה ב-/permissions בלשונית Recently denied. מקש r מנסה אותה שוב עם אישור ידני.
• חסימות חוזרות: אם המסווג חוסם פעולה 3 פעמים ברצף או 20 פעמים בסך הכל, מצב auto נעצר וקלוד קוד חוזר לבקש אישור. אישור הפעולה המבוקשת מחדש את המצב. הספים אינם ניתנים להגדרה. מונה הסך נשמר לסשן ומתאפס רק כשהמגבלה שלו עצמה מפעילה נפילה. דחייה שבדיקת בטיחות נפרדת ממצב auto סירבה בה לבקשת המסווג עצמה אינה נספרת. בהרצת -p לא אינטראקטיבית בלי --permission-prompt-tool אין בקשה ליפול אליה: הפעולה אינה רצה, קלוד ממשיך, וההרצה אינה נעצרת. חסימות חוזרות בדרך כלל אומרות שלמסווג חסר הקשר על התשתית. /feedback מדווח על חיוביות שגויות, או שמנהל מגדיר תשתית מהימנה.
• אין פסק דין מהמסווג: כשבדיקת בטיחות נפרדת מסרבת לבקשת המסווג, או שהתשובה אינה מפוענחת, הפעולה נדחית בלי ההודעה ובלי רשומה ב-Recently denied.
• אין פסק דין מהשרת: תחת בדיקה בצד השרת, הפעולה נדחית, והתור נעצר אחרי עשר תשובות ברצף בלי פסק דין.
• החלפת מצב באמצע בדיקה: אם מחליפים מצב בזמן שבדיקה ממתינה, פסק דין שהמצב החדש לא היה מבקש מושלך. מוצגת בקשת אישור, או שהפעולה נדחית אוטומטית במצב dontAsk.

#דילוג על בדיקות במצב bypassPermissions

מצב bypassPermissions מכבה בקשות אישור ובדיקות בטיחות כך שקריאות כלים רצות מיד, כולל כתיבה לנתיבים מוגנים. גם במצב הזה, כל אחת מהפעולות שאף מצב אינו מאשר אוטומטית מקבלת בקשה או דחייה במקום לרוץ לבד. קריאת artifact ציבורי של ארגון אחר דורשת את האישור שלכם, והמצב הזה אינו מבקש אותו, ולכן קלוד אינו יכול לקרוא artifact כזה. דחיות Remove-Item ב-PowerShell חלות גם כאן.

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

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

בסשן טרמינל אינטראקטיבי עם הרשאות bypass זמינות, קלוד קוד גם אינו אוכף את חסימות מצב plan. קלוד עדיין מקבל הוראה לתכנן בלי לערוך, אבל עריכת קובץ או פקודת מעטפת שהוא מנסה במהלך התכנון רצה בלי בקשה. כללי ask מפורשים ומחיקות נתיב קריטי עדיין מבקשים אישור. מצב plan שומר את החסימות בכל מקום בלי טרמינל אינטראקטיבי, כולל -p, סשני Agent SDK, ושיחות בחלונית הצ'אט של הרחבת VS Code. שם --allow-dangerously-skip-permissions הופך את bypassPermissions לניתן לבחירה אחר כך.

אי אפשר להיכנס למצב מסשן שנפתח בלי שהוא הופעל. מפעילים בהרצה עם permissions.defaultMode: "bypassPermissions" או עם דגל:

claude --permission-mode bypassPermissions

הדגל --dangerously-skip-permissions שקול. קלוד קוד מסרב למצב בסשן שנפתח עם --restricted. הדגל --restricted דורש v2.1.248 ומעלה.

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

• אם מקבלים: קלוד קוד קובע skipDangerousModePermissionPrompt ל-true ב-~/.claude/settings.json, וסשנים מאוחרים מדלגים על התיבה. כדי לראות אותה שוב מסירים את המפתח או קובעים false. אפשר לקבוע את המפתח גם בקובצי הגדרות אחרים, כפי שמפורט בתיעוד של המפתח.
• אם דוחים: קלוד קוד יוצא.

במצב לא אינטראקטיבי אין תיבה. סשן רקע מכבד קבלה כשהיא רשומה בהגדרות משתמש או מנוהלות:

• בלי קבלה רשומה, claude --bg --permission-mode bypassPermissions נדחה עד שמקבלים את התיבה בסשן אינטראקטיבי.
• כש-skipDangerousModePermissionPrompt נקבע רק ב-.claude/settings.local.json, סשן הרקע מתחיל כשהבקשה ל-bypass מתעלמים ממנה, ומוצמדת ההודעה Bypass permissions was requested at launch and ignored · if that was you, ~/.claude/settings.json needs "skipDangerousModePermissionPrompt": true. כדי שה-bypass יכובד, מוסיפים את המפתח ל-~/.claude/settings.json, ואחר כך פותחים סשן רקע חדש.

ב-Linux וב-macOS קלוד קוד מסרב להתחיל במצב הזה כ-root או תחת sudo:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

הבדיקה מדולגת אוטומטית בתוך sandbox מוכר. כדי לרוץ בלי השגחה בתוך מכולה, משתמשים בתצורת dev container, שמריצה את קלוד קוד כמשתמש שאינו root. סשנים בענן אינם מכבדים defaultMode: "bypassPermissions" או "dontAsk" מקובצי הגדרות, כך שהגדרות שנשמרו במאגר אינן יכולות לפתוח סשן בענן במצב הזה. הערך מתעלמים ממנו בשקט, והסשן נפתח במצב שמופיע בבורר. מנהלים יכולים לחסום את המצב עם permissions.disableBypassPermissionsMode בערך "disable" בהגדרות מנוהלות.

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

#הגדרות נפוצות

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

ההרשאות וה-sandbox הם שכבות משלימות. ההרשאות קובעות אילו כלים, קבצים ודומיינים מותרים. ה-sandbox אוכף במערכת ההפעלה גבול של מערכת קבצים ורשת על פקודות Bash, PowerShell ו-Monitor ועל תהליכי הבן שלהן, גם אם תוכן עוין עקף את שיקול הדעת של קלוד. נתיבים ודומיינים מהגדרות ה-sandbox וכללי ההרשאה מתמזגים לתצורת ה-sandbox הסופית. כלל deny או ask עדיין אינו חוסם את EndConversation כל עוד נשאר כלי אחר.

ה-sandbox של Bash ומצב auto פועלים בנפרד ומשתלבים זה בזה, עם החריגים המפורטים בתיעוד הרשמי על מצבי sandbox. האינטראקציה המלאה מתוארת בתיעוד הרשמי על הקשר בין ה-sandbox להרשאות ולמצבי הרשאה, ועל הקשר בין בידוד למצבי הרשאה.

כשה-sandbox פועל ו-autoAllowBashIfSandboxed נשאר בברירת המחדל true, פקודות Bash בתוך ה-sandbox רצות בלי בקשה גם אם יש כלל ask על השם Bash לבדו, או הצורה Bash(*): גבול ה-sandbox מחליף את הבקשה על הכלי כולו. במצב plan ההחלפה הזו אינה חלה. בלי כלל ask, פקודות הקריאה המובנות עדיין רצות בלי בקשה, וכל פקודת מעטפת אחרת עוברת את זרימת ההרשאה הרגילה. עם כלל ask על Bash לבדו, כל פקודת Bash מבקשת אישור, כולל פקודות קריאה ב-sandbox. לפני v2.1.212 ההחלפה חלה גם במצב plan. כלל ask על תוכן פקודה, כלל deny מפורש, ו-rm או rmdir לנתיב קריטי, ממשיכים בזרימה הרגילה. פקודות ב-sandbox אחרות יכולות גם הן לעבור את הזרימה הרגילה, כפי שמצב auto-allow מתאר. פקודות שאינן רצות ב-sandbox מכבדות את כלל ה-ask על Bash כרגיל.

#באיזה מצב סשן נפתח

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

1. הדגל --permission-mode, או --dangerously-skip-permissions.
2. permissions.defaultMode בקובץ הגדרות. אם מגדירים "auto" ב-.claude/settings.json או ב-.claude/settings.local.json, הערך אינו נכנס לתוקף, וקלוד קוד משתמש בברירת המחדל המובנית במקום ב-defaultMode מ-~/.claude/settings.json. מעבירים את "auto" אל ~/.claude/settings.json. אם מגדירים "bypassPermissions" בשני הקבצים האלה, הערך אינו נכנס לתוקף, והסשן נפתח במצב Manual. שאר הערכים חלים מכל קובץ הגדרות. לפני v2.1.257 ערך bypassPermissions נכנס לתוקף מכל קובץ הגדרות.
3. ברירת המחדל המובנית.

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

ברירת המחדל המובנית auto דורשת קלוד קוד v2.1.228 ומעלה ב-macOS, Linux ו-WSL, ו-v2.1.233 ומעלה ב-Windows מקורי. בגרסאות מוקדמות יותר ברירת המחדל המובנית היא Manual.

ברירת המחדל המובנית תלויה באופן ההפעלה של קלוד קוד. השורה הראשונה שמתאימה לסשן היא זו שחלה. הטבלה מכסה סשנים שנפתחים בטרמינל או דרך הרחבת VS Code. לאפליקציית Desktop ול-claude.ai ראו את הלשוניות Desktop ו-Web בתיעוד הרשמי על החלפת מצבי הרשאה.

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

כשהדגל, קובץ הגדרות או ברירת המחדל המובנית בוחרים auto, ומצב auto אינו זמין לסשן, קלוד קוד פותח את הסשן במצב Manual. מצב auto אינו זמין כשהסשן אינו עומד בדרישות הזמינות, למשל כשקובץ הגדרות מכבה אותו או כשהדגם אינו תומך בו, או כש-Anthropic כיבתה אותו זמנית בצד השרת.

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

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

אם ~/.claude/settings.json קובע defaultMode שאינו auto ואין קובץ הגדרות אחר שקובע ערך, הסשנים ממשיכים להיפתח במצב שהגדרת. בתוכניות Pro, Max ו-Team, ובסשנים שאינם שולפים דגלי תכונות, קלוד קוד שואל פעם אחת, בטרמינל או בהרחבת VS Code, האם לשנות את ההגדרה למצב auto. אם דוחים, ההגדרה נשארת כפי שהיא.

#פתיחה במצב הרשאה אחר

אפשר לקבוע את מצב הפתיחה לסשן אחד, או כברירת מחדל לכל סשן במחשב, בפרויקט או בארגון. כשיותר מקובץ הגדרות אחד קובע permissions.defaultMode, סדר העדיפות של ההגדרות מכריע, וערך של פרויקט או ערך מנוהל גובר על ~/.claude/settings.json. כדי להחליף מצב בסשן שכבר רץ, השתמשו ב-Shift+Tab ב-CLI, במחוון המצב ב-VS Code, או בבורר המצב באפליקציית Desktop.

הדוגמה הזו פותחת כל סשן טרמינל במחשב במצב Manual, שערך ההגדרה שלו הוא default. שומרים אותה ב-~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default"
  }
}

הסשן הבא שפותחים מציג בשורת המצב ⏸ manual mode on.

#מצבי הרשאה עם תצורת HIPAA

בארגון שהוחלה בו תצורת HIPAA, ברירת המחדל המובנית auto אינה חלה. סשן טרמינל או VS Code נפתח במצב Manual כששום דבר אחר אינו בוחר את מצב הפתיחה. סשן טרמינל גם מציג Auto mode isn't the default for your organization · Shift+Tab to switch. הרחבת VS Code אינה מציגה הודעה. אילו סשנים עומדים בתנאי ההתחברות מפורט בתיעוד הרשמי של HIPAA.

מצב auto ו-bypassPermissions נשארים זמינים:

• מעבר ל-auto: Shift+Tab, או בקרת המצב של הממשק.
• פתיחה ב-auto: --permission-mode auto, או permissions.defaultMode בערך auto בהגדרות המשתמש, או בהגדרות מנוהלות לכל הארגון.
• הסרת מצב auto: permissions.disableAutoMode בערך "disable" בהגדרות מנוהלות.
• חסימת bypassPermissions: permissions.disableBypassPermissionsMode בערך "disable" בהגדרות מנוהלות.

דורש קלוד קוד v2.1.285 ומעלה, גרסת המינימום לתצורת HIPAA.

#החלפת מצב במהלך סשן

#CLI

במהלך סשן לוחצים Shift+Tab. מ-auto, הלחיצה הראשונה עוברת ל-default, ואחר כך המחזור הוא default, אחר כך acceptEdits, אחר כך plan. מצבים אופציונליים נכנסים אחרי plan. כש-auto במחזור, אחרי plan חוזרים ל-auto, והלחיצה הבאה מ-auto חוזרת ל-default. שורת המצב מציגה ⏸ manual mode on באפור עבור default, או ⏵⏵ accept edits on, ⏸ plan mode on, ⏵⏵ auto mode on, ⏵⏵ don't ask on, או ⏵⏵ bypass permissions on.

לא כל מצב נמצא במחזור ברירת המחדל:

• auto מופיע כשהמצב זמין. מעבר אליו מחליף מצב בלי בקשת אישור.
• bypassPermissions מופיע אחרי שמתחילים עם --permission-mode bypassPermissions, --dangerously-skip-permissions, --allow-dangerously-skip-permissions, או permissions.defaultMode: "bypassPermissions" בהגדרות משתמש, ב---settings, או בהגדרות מנוהלות. גרסת --allow- מוסיפה את המצב למחזור בלי להפעיל אותו.
• dontAsk אינו מופיע במחזור. קובעים אותו עם --permission-mode dontAsk.

מצבים אופציונליים שמופעלים נכנסים אחרי plan, קודם bypassPermissions ובסוף auto. אם שניהם פעילים, עוברים דרך bypassPermissions בדרך אל auto.

מבקשת אישור של Bash, במצבי Manual ו-acceptEdits, כשמצב auto זמין, נוספת האפשרות Yes, and switch to auto mode. הבחירה מאשרת את הפקודה ומעבירה את הסשן למצב auto. בקשות של כלי PowerShell אינן מציעות את זה. דורש v2.1.247 ומעלה. האפשרות אינה נוספת לבקשות שכפה כלל ask או hook, כי מצב auto עדיין מציג את הבקשות האלה.

אותו דגל --permission-mode עובד עם -p. כברירת מחדל קובעים permissions.defaultMode בהיקף הרצוי, כפי שמתואר בסעיף פתיחה במצב הרשאה אחר.

#VS Code

לוחצים על מחוון המצב בתחתית תיבת הפרומפט.

כדי לקבע את מצב הפתיחה, קובעים claudeCode.initialPermissionMode בהגדרות המשתמש של VS Code לאחד מ-default, manual, acceptEdits, plan, או bypassPermissions. ההגדרה אינה מקבלת auto. כדי להתחיל ב-Auto משאירים אותה לא מוגדרת ובוחרים Auto במחוון פעם אחת, כמו בסעיף 2. כל שיחה חדשה נפתחת לפי הראשון שחל:

1. claudeCode.initialPermissionMode
2. המצב האחרון שנבחר במחוון, אם היה Manual, Edit automatically, או Auto. בחירת Plan או Bypass permissions חלה רק על אותה שיחה.
3. permissions.defaultMode מהגדרות מנוהלות או מ-~/.claude/settings.json
4. ברירת המחדל המובנית לפי התוכנית, הספק והגדרות הארגון

ההרחבה אינה קוראת את .claude/settings.json או .claude/settings.local.json של הפרויקט עבור מצב הפתיחה. כש-claudeCode.claudeProcessWrapper מוגדר, סעיפים 3 ו-4 אינם חלים: השיחות נפתחות ב-Manual אלא אם סעיף 1 או 2 קובעים מצב. לפני v2.1.283 סעיף 3 חל רק בתוכניות Pro, Max ו-Team בסשנים ששולפים דגלי תכונות.

Auto מופיע במחוון כשהמצב זמין. Bypass permissions דורש את המתג Allow dangerously skip permissions בהגדרות ההרחבה. בלעדיו המצב אינו מופיע, וערך bypassPermissions מסעיף 1 או 3 פותח את השיחה ב-Manual. Auto מכל סעיף פותח ב-Manual כשהמצב אינו זמין.

בהרחבת VS Code, אופן האישור של פעולות דפדפן של Claude in Chrome תלוי באופן שבו הסשן התחבר לדפדפן, כפי שמפורט בתיעוד של Claude in Chrome.

#JetBrains

התוסף מריץ את קלוד קוד בטרמינל של ה-IDE. מחליפים כמו ב-CLI: Shift+Tab, או --permission-mode בהפעלה.

#Desktop

בלשונית Code משתמשים בבורר ליד כפתור השליחה. Auto מופיע כשהמצב זמין. Bypass permissions דורש את המתג Allow bypass permissions mode בהגדרות Desktop בתוכניות Pro ו-Max. בתוכניות Team ו-Enterprise מדיניות הארגון שולטת בזה. לשונית Cowork אינה משתמשת במצבים האלה. יש לה מצבי הרשאה משלה, שמופעלים בנפרד, והבורר אינו מופיע עד שמצב מעבר לברירת המחדל שלה מופעל לחשבון.

כברירת מחדל קובעים defaultMode בקבצי ההגדרות. האפליקציה קוראת את אותם קבצים כמו ה-CLI ומחילה את המצב על סשנים מקומיים חדשים. מצב שנבחר בבורר נזכר לכל תיקייה וגובר על defaultMode לאותה תיקייה. Plan הוא החריג: הבחירה חלה רק על הסשן הנוכחי.

#Web ומובייל

ב-claude.ai/code משתמשים בתפריט ליד תיבת הפרומפט. באפליקציית המובייל מקישים על כפתור + בתיבת הפרומפט, ואחר כך על Permission. בקשות אישור מופיעות ב-claude.ai.

• סשנים בענן: Accept edits, Plan, ו-Auto. Accept edits מתאים למצב default: סשנים בענן מאשרים מראש עריכות קבצים בלי קשר למצב, ולכן התפריט מציג Accept edits במקום Manual. סשנים בענן עדיין מכבדים defaultMode: "acceptEdits" מההגדרות. מצב Auto מופיע רק כשהארגון מתיר אותו והמודל שנבחר תומך בו. Bypass permissions אינו זמין.
• סשני Remote Control על המכונה המקומית: Manual, Accept edits, Plan, ו-Auto לסשן שהתחלתם בעצמכם. אי אפשר לבחור Bypass permissions מהאפליקציה. כדי להשתמש ב-Auto הסשן צריך לעמוד בדרישות הזמינות של מצב auto. לשרשור פרויקט שרץ על המחשב, ראו בתיעוד הרשמי את הרצת שרשור על המחשב שלכם. חוץ מ-Bypass permissions, התפריט מציג את המצב של הסשן המקומי, כולל מצב שנקבע מהטרמינל, ומתעדכן כשהמצב משתנה באפליקציה או בטרמינל. סשנים שהאפליקציה או הרחבת VS Code מארחים מדווחים על שינוי מצב ל-claude.ai בזמן אמת, כמו סשן שרץ בטרמינל. לפני v2.1.202 סשנים שחוברו עם /remote-control או claude --remote-control לא דיווחו על המצב בכלל, כך שהתווית יכלה להציג מצב שהסשן לא היה בו. אי ההתאמה נגעה רק לתווית. בקשות האישור נוצרו מהמצב האמיתי.

ב-Remote Control המכונה המקומית חייבת להיות מחוברת לחשבון claude.ai. מפתחות API אינם נתמכים. אפשר גם לקבוע את מצב הפתיחה בהפעלת הסשן המקומי:

claude remote-control --permission-mode acceptEdits

#מה דורש אישור במצב Manual

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

בקשת אישור מציגה מה קלוד עומד לעשות, ואז את האפשרויות. בבקשת Bash במצב Manual הדוגמה הרשמית היא פקודה npm test עם התיאור Run the test suite, השורה This command requires approval, והשאלה Do you want to proceed, מתחת לטיפ על מצב auto. האפשרויות הן Yes, Yes, and don't ask again for: npm test *, Yes, and switch to auto mode, ו-No. Esc מבטל. Tab פותח הערה על Yes או על No. האפשרות לעבור למצב auto אינה מופיעה בכל בקשה.

כשבוחרים אישור קבוע לפקודת Bash או לדומיין של WebFetch, ב-CLI הכלל נשמר ככלל allow בקובץ .claude/settings.local.json בשורש מאגר ה-git, אחרי פתרון worktrees אל ה-checkout הראשי. בהרחבת VS Code כרטיס האישור מאפשר לבחור את קובץ היעד, כולל הקובץ המשותף של הפרויקט, וכלל שם משנה את ההתנהגות לכל מי שעובד בפרויקט. הכלל חל על סשנים עתידיים בכל המאגר, כולל סשן מתת תיקייה או מ-worktree. לפני גרסה v2.1.211 הכלל נשמר בתיקיית ההפעלה. אישור שנשמר אז בתת תיקייה או ב-worktree ממשיך לחול על סשנים שנפתחים משם. קלוד קוד עדיין קורא קובץ שהגרסה הישנה השאירה שם, לצד הקובץ בשורש. כששני הקבצים קובעים את אותו מפתח, הערך בשורש חל, וכללי הרשאה משני הקבצים חלים. העוזר resolveSettings() של ה-Agent SDK קורא את הקובץ תמיד מתיקיית ההפעלה. סשני Agent SDK טוענים את .claude/settings.local.json מספריית העבודה בכל הגרסאות.

כלל allow בקובץ המקומי אינו גובר על כלל ask מקובץ פרויקט או מהגדרות מנוהלות. אם אחרי "Yes, and don't ask again" עדיין מופיעה בקשה לאותו כלי, בודקים אם יש כלל ask בהיקף גבוה יותר.

במקרים כמו מחוץ למאגר git או ב-Windows, קלוד קוד אינו משתמש בשורש המאגר. הקובץ המקומי נשמר בתיקיית העבודה שבה הופעל קלוד קוד (לצד .claude/settings.json) במקום בשורש המאגר בארבעה מקרים: מחוץ למאגר git, כאשר שורש המאגר הוא תיקיית הבית שלך, ב-Windows, או כאשר שורש המאגר או הרשומות .git או .claude אינם בבעלות המשתמש שלך. נתיב שמתחיל ב-/ בכלל הרשאה בקובץ המקומי, וגם נתיב sandbox יחסי, מעוגנים לספריית העבודה הראשית של הסשן, ולא לשורש המאגר.

בפעם הראשונה שקלוד קוד כותב לקובץ .claude/settings.local.json במאגר git שאינו מתעלם ממנו, הוא מוסיף אוטומטית את הנתיב **/.claude/settings.local.json לקובץ ה-git excludes הגלובלי שלך. קובץ זה נקבע לפי core.excludesFile אם הוגדר בהגדרות git הגלובליות נתיב מוחלט או כזה שמתחיל ב-~, ואחרת הוא $XDG_CONFIG_HOME/git/ignore, או ~/.config/git/ignore כאשר המשתנה אינו מוגדר. אם יצרת את הקובץ ידנית לפני שקלוד קוד כתב בו, הוסף אותו בעצמך ל-.gitignore.

כללי ה-allow והרשומות additionalDirectories בקובץ המקומי נכנסים לתוקף בלי שלב האמון כל עוד הקובץ אינו במעקב git. אם הקובץ במעקב git, או ש-.claude הוא symlink, קלוד קוד מתייחס אליו כאל תוכן שהמאגר סיפק ומחזיק את הכללים עד שסומכים על התיקייה. כדי להבדיל בין השניים קלוד קוד מריץ git, ורק אחרי שהתיקייה מהימנה: קיבלתם את תיבת האמון עבורה או עבור תיקיית אב שהאמון שלה מכסה אותה, או שאתם בסשן -p או SDK, שנחשב מקובל. עד אז מקום ההפעלה קובע:

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

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

אישור לעריכת קבצים לא נכתב לקובץ: הוא תקף עד סוף הסשן בלבד.

קלוד קוד קורא את .claude/settings.json המשותף מספריית העבודה הראשית של הסשן. כדי להשתמש בקובץ שנשמר בשורש המאגר, מפעילים את קלוד קוד משם. לאחר /cd <path> קלוד קוד שומר את השיחה, טוען את CLAUDE.md של התיקייה החדשה, ומבקש לסמוך על מרחב העבודה אם לא עבדתם בה. אחר כך --resume מהתיקייה החדשה מוצא את הסשן שהועבר. הוא מחיל את הגדרות הפרויקט החדשות, כולל כללי הרשאה ו-hooks, שרתי .mcp.json בכפוף לאותו אישור כמו בהפעלה, שרתי MCP מקומיים שנרשמו בה, תוספים, skills ו-subagents, וערכי env מעל משתני הסביבה של התיקייה הקודמת, שנשארים בתוקף. הוא מנתק את שרתי ה-MCP של הפרויקט הקודם ושל תוספים שכבר אינם מופעלים, לוקח additionalDirectories מההגדרות החדשות, ושומר תיקיות שנוספו עם --add-dir או /add-dir. hooks שהמעבר מפעיל עדיין מקבלים ${CLAUDE_PROJECT_DIR} כשורש הפרויקט שבו הסשן התחיל. כשהתיקייה החדשה עדיין לא מהימנה, תיבת האמון מפרטת את כללי ה-allow, התיקיות הנוספות, ה-hooks ופקודות העזר שההגדרות יפעילו. דחייה משאירה את הסשן במקום. לפני v2.1.246 הפקודה /cd לא החילה את ההגדרות, ה-hooks, שרתי ה-MCP או ה-skills של התיקייה החדשה עד שחידשו את הסשן, ותיבת האמון לא פירטה מה יופעל. מגבילים או מכבים יעדי /cd עם כללי Cd.

לפעמים מוצג רק אישור חד פעמי, בלי "don't ask again" ובלי אישור לשאר הסשן. האפשרויות האלה מופיעות רק כשהבקשה יכולה להראות במלואן מה הכלל יכסה, כדי שכלל שנשמר מהבקשה יכסה רק את מה ששמו בתווית. כשמוצג רק אישור חד פעמי, אשרו את הפעולה פעם אחת, או הוסיפו את הכלל בעצמכם ב-/permissions. לפקודה שמתחילה בעטיפת exec כמו watch, או ל-find עם פעולה כמו -delete, ראו את סעיף עטיפות exec ופעולות find.

#הוספת הערה במענה לבקשת אישור

באפשרותך לצרף הערה לקלוד כאשר אתה מאשר או דוחה פעולה בודדת. ברוב בקשות האישור, כולל Bash, PowerShell, קבצים וכלי MCP, עבור אל Yes או No והקש Tab כדי לפתוח שדה הערה. בקשות של WebFetch ובקשות דפדפן אינן כוללות שדה זה, וגם אפשרויות ששומרות כלל קבוע או מאשרות לשאר הסשן אינן מקבלות הערה.

כאשר השדה פתוח, הקלד את ההערה והקש על אחד המקשים הבאים:

• Enter: שולח את התשובה בצירוף ההערה. אם השדה ריק, התשובה נשלחת ללא הערה.
• Tab: סוגר את השדה בלי לענות. הטקסט שהקלדת נשמר ויישלח אם תבחר באותה אפשרות.
• Shift+Tab: בבקשת קובץ (כגון Edit או Write), סוגר את השדה בדיוק כמו Tab. לפני גרסה v2.1.235, הקשה על Shift+Tab בתוך השדה בחרה באפשרות לאשר את הפעולה לשאר הסשן וההערה נמחקה.

אופן מסירת ההערה תלוי בתשובה:

• Yes: קלוד קוד מריץ את הפעולה ושולח את ההערה לקלוד מיד לאחר קבלת התוצאה.
• No: קלוד קוד שולח את ההערה כסיבת הדחייה וקלוד ממשיך לעבוד. בחירה ב-No בלי הערה בשיחה הראשית עוצרת את התור (turn).

#ניהול הרשאות

אפשר לראות ולנהל את הרשאות הכלים עם /permissions. הדיאלוג מציג את כל הכללים ואת קובץ ה-settings.json שממנו כל כלל מגיע. אפשר לפתוח את הדיאלוג בזמן שקלוד עובד: הוספה או הסרה של כלל נכנסת לתוקף החל מקריאת הכלי הבאה של קלוד באותו תור. לפני גרסה v2.1.234 הפקודה המתינה עד סיום התור.

• כללי Allow מאפשרים לקלוד קוד להשתמש בכלי שצוין בלי אישור ידני.
• כללי Ask מציגים בקשת אישור בכל פעם שקלוד קוד מנסה להשתמש בכלי שצוין.
• כללי Deny מונעים מקלוד קוד להשתמש בכלי שצוין.

קלוד קוד עוקב אחרי קבצי ההגדרות וטוען אותם מחדש כשהם משתנים, כך שרוב העריכות חלות על הסשן הרץ בלי הפעלה מחדש, כולל עריכות ל-permissions, ל-hooks, ולעוזרי אישורים כמו apiKeyHelper. קלוד קוד גם טוען קובץ הגדרות שנוצר באמצע סשן אם התיקייה שלו הייתה קיימת כשהסשן התחיל. לתיקיית .claude/ של הפרויקט הוא טוען את הקובץ גם כשיוצרים את התיקייה באותו סשן. הטעינה מחדש מכסה הגדרות משתמש, פרויקט, מקומיות ומנוהלות, וקלוד קוד מריץ hook מסוג ConfigChange לכל שינוי בקובץ הגדרות שהוא מזהה. הגדרות מנוהלות שמגיעות מ-MDM או מקונסולת claude.ai מגיעות לסשן רץ לפי לוח הזמנים של מקור המסירה, לא ברגע השמירה. בסשן Cowork על המכונה באפליקציית Desktop, קלוד קוד אינו שולף הגדרות מנוהלות מהשרת מקונסולת claude.ai, והוא קורא מדיניות שנפרסה למכשיר, אלא אם תצורת Claude Desktop של הארגון קובעת requireCoworkFullVmSandbox. מפתחות שנקראים רק בפתיחת הסשן נשארים כפי שהיו: את model מחליפים באמצע סשן עם /model, ואת effortLevel ו-modelSettings עם /effort. מפתחות בצד הניהול שממתינים גם הם להפעלה מחדש, כמו requiredMinimumVersion, מפורטים בתיעוד הרשמי על מקום וזמן תחולה של מדיניות.

כאשר מצב auto זמין לסשן, הדיאלוג כולל גם את כללי המסווג של מצב auto. בחרו בלשונית Auto mode כדי לראות אותם.

החלטת hook אינה עוקפת כללי הרשאה. כלל deny תואם חוסם גם כשה-hook החזיר "allow", וכלל ask תואם עדיין מבקש אישור גם כשה-hook החזיר "allow" או "ask". זה חל על hooks בקובצי הגדרות וב-hooks/hooks.json של תוסף. hook שיוצא בקוד 2 עוצר את הקריאה לפני שהכללים נבדקים, ולכן החסימה חלה גם כשכלל allow היה מתיר. כדי להריץ את כל פקודות Bash בלי בקשה ולחסום כמה מהן, מוסיפים "Bash" לרשימת ה-allow ורושמים hook מסוג PreToolUse שדוחה את הפקודות האלה.

מוד שמתקינים ומטפל ב-tool.check עונה אחרי הכללים ואחרי ה-hooks מסוג PreToolUse, והתשובה שלו יכולה להחליף את שלהם:

• כללי ask: המוד יכול לאשר קריאה שכלל ask היה מבקש עליה.
• חסימה מ-hook מסוג PreToolUse: המוד יכול לאשר את הקריאה, אלא אם ה-hook בהגדרות מנוהלות.
• המסווג במצב auto: קריאה שהמוד אישר רצה בלי בדיקת מסווג.
• כללי deny: במכונה עם הגדרות מנוהלות, או כשמחוברים בתוכנית Team או Enterprise, כללי deny גוברים על המוד כברירת מחדל, והארגון יכול לשנות זאת. בכל מקום אחר המוד יכול לאשר קריאה שכלל deny דוחה.

כלי MCP עם requiresUserInteraction, וכלי מחברים שהארגון הגדיר ל-ask, עדיין מבקשים אישור כש-hook מחזיר "allow". קריאות מנתיבי רשת גם הן עדיין מבקשות אישור כש-hook מחזיר "allow". עבור כלי שדורש אינטראקציה עם המשתמש, אישור tool.check של מוד אינו מדלג על הבקשה. דורש קלוד קוד v2.1.292 ומעלה. hooks מסוג PreToolUse רצים לפני בקשת האישור לכל כלי מלבד EndConversation. פלט ה-hook יכול לדחות את הקריאה, לכפות בקשה, או לדלג על הבקשה כדי שהקריאה תמשיך, בכפוף לכללים למעלה.

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

מארח שמשבץ את קלוד קוד יכול להעביר מדיניות מנוהלת נוספת דרך האפשרות managedSettings של ה-SDK, כולל כללי allow, אלא אם מנהל קבע את נעילות allowManaged*Only. מתי מדיניות של המטמיע חלה בכלל מפורט בתיעוד של Claude apps gateway.

אחד המפתחות שרק הגדרות מנוהלות יכולות לקבוע, allowManagedPermissionRulesOnly, הופך את ההגדרות המנוהלות למקור היחיד של כללי הרשאה. הרשומה של המפתח מונה כל מקור שקלוד קוד מתעלם ממנו אז.

רשימות כמו permissions.allow מתמזגות בין הקבצים: כל קובץ מוסיף רשומות בלי למחוק את הרשומות של קובץ אחר. אם הארגון קובע allowManagedPermissionRulesOnly, נשארים רק כללי ה-allow המנוהלים, וקלוד קוד מתעלם מכל שאר המקורות שהרשומה של המפתח מונה. רשימות מודל אינן כולן מתמזגות באותו אופן: fallbackModel נלקח בשלמותו מהקובץ בעל העדיפות הגבוהה ביותר שמגדיר אותו, ו-modelPicker נלקח בשלמותו מהגבוה מבין הגדרות מנוהלות, --settings, והגדרות משתמש, ומתעלמים ממנו בהגדרות פרויקט ומקומיות. modelPicker דורש v2.1.242 ומעלה. כשהגדרות מנוהלות שקלוד קוד מחיל מגדירות availableModels, הרשימה חלה כפי שהיא ומתעלמים מתוספות בהגדרות משתמש, פרויקט או מקומיות, אלא אם אפליקציה שמטמיעה את קלוד קוד מספקת רשימת מודלים משלה. גם בין מקורות מנוהלים הרשימה אינה מתמזגת: איזה מקור חל מפורט בתיעוד הרשמי על שילוב מקורות מנוהלים. בהיקפים שאינם מנוהלים המערכים מתמזגים כרגיל. modelSettings נפתר מודל אחר מודל, יחד עם effortLevel. איזה קובץ חל על מודל מפורט ברשומת modelSettings בתיעוד ההגדרות.

אפליקציה שמריצה את קלוד קוד בתוכה וקובעת CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST היא חריג נוסף. קלוד קוד לוקח את תצורת המודל של האפליקציה מעל המפתחות model, fallbackModel, modelPicker, ו-modelOverrides מכל מקור מנוהל, ומעל משתני בחירת המודל בבלוק env מנוהל, כמו ANTHROPIC_MODEL ומשפחת ANTHROPIC_DEFAULT_*_MODEL. רשימת availableModels מנוהלת נשארת בתוקף, אלא אם האפליקציה מספקת רשימה משלה. מפתח model מנוהל הוא ברירת מחדל לפתיחה. הנעילות הן availableModels ו-deniedModels. דגל כמו --model בוחר רק ממודלים שהארגון מתיר.

permissions.allow ו-permissions.additionalDirectories ב-.claude/settings.json של פרויקט מעניקים יכולת, ולכן חלים רק אחרי שסומכים על התיקייה. תיבת האמון מפרטת את הכללים והתיקיות שהתיקייה תעניק. כללי deny ו-ask אינם תלויים באמון, כי הם רק מגבילים. בסשן אינטראקטיבי בלבד מוצגת תיבת האמון. הרצת claude -p או סשן SDK אינם מציגים אותה, ואמון בתיקיית אב אינו נספר לכללי allow האלה, ולכן הם אינם בשימוש שם עד שסומכים על התיקייה עצמה. קלוד קוד מדפיס אזהרה שמרחב העבודה לא זכה לאמון אל stderr.

קלוד קוד קושר את האמון לפי מקום ההפעלה. במאגר, האמון נקשר לשורש מאגר ה-git ומכסה את כל המאגר חוץ ממאגר git מקונן בתוכו, כמו submodule. ב-worktree משתמשים בשורש ה-checkout הראשי. מחוץ למאגר, האמון נקשר לתיקייה שממנה הופעל קלוד קוד ומכסה תת תיקיות, חוץ ממאגר git מקונן. כשמתחילים בתיקיית הבית, האמון נשמר לסשן הנוכחי בלבד ואינו נכתב לדיסק.

לפני התחלה או הפעלה מחדש של סשן רקע, קלוד קוד בודק אמון בתיקייה שהסשן רץ בה. claude --bg מטרמינל בתיקייה שלא זכתה לאמון מציג קודם את תיבת האמון, והסשן מתחיל אחרי שמקבלים. כשאי אפשר להציג תיבה, למשל בסקריפט, הפקודה יוצאת בשגיאת Workspace not trusted.

מה שרץ לפני אמון בתיקייה עצמה, בין שאמון ניתן רק לתיקיית אב ובין שב-claude -p או ב-SDK: עמודת תיקיית האב אינה חלה בתוך מאגר מקונן. בסשן אינטראקטיבי קלוד קוד מציג שם את תיבת האמון, והרצת claude -p או SDK שם עוקבת אחרי עמודת claude -p.

לשורות שדורשות אמון בתיקייה הזו עצמה, אפשר לסמוך ידנית: קובעים projects["<path>"].hasTrustDialogAccepted ל-true ב-~/.claude.json, כאשר <path> הוא שורש המאגר, או התיקייה עצמה מחוץ למאגר. קלוד קוד מדפיס את המפתח המדויק בשורת ה-debug של hook או שרת MCP שדולגו, באזהרת stderr של כללי allow שדולגו, ובשורת headersHelper not run.

#לפני claude -p במאגר שלא כתבתם

לפני הרצה במאגר כזה מחליטים מה מותר לרוץ על המכונה:

• מעבירים --setting-sources user, או קובעים ב-SDK את settingSources בלי הגדרות פרויקט, כדי שקלוד קוד לא יקרא את קבצי ההגדרות של הפרויקט ולא את .mcp.json.
• מתחילים עם --bare, כדי שלא ייקראו hooks, skills, פקודות מותאמות, subagents, תוספים או שרתי .mcp.json מהפרויקט. בלוק env של הפרויקט ועוזרים כמו awsAuthRefresh בקובצי ההגדרות שלו עדיין חלים. apiKeyHelper נקרא רק מ---settings.
• מעבירים --settings '{"disableAllHooks": true}' כדי לכבות hooks להרצה הזו. קביעה בהגדרות המשתמש לבדה אינה מספיקה, כי הגדרות הפרויקט גוברות ויכולות להחזיר את הערך ל-false.
• מוסיפים רשומת disabledMcpjsonServers כדי לדחות שרת מ-.mcp.json לפי שם, בכל סוג סשן.

#מלכודות בהגדרות

כשמפתח אינו מתנהג כאילו הגדרתם אותו, מתחילים ב-/status ורואים אילו קבצים נטענו. שורת Setting sources מפרטת כל קובץ שנטען לסשן, וכשהגדרות מנוהלות בתוקף היא מציינת בסוגריים איך הגיעו למכונה. השורה מאשרת אילו קבצים נקראו, והיא אינה מראה איזה קובץ סיפק כל מפתח. רשומות שקלוד קוד דחה רואים עם claude doctor. המקרים הנפוצים שנוגעים להרשאות ולהגדרות:

• רמה גבוהה יותר קובעת את אותו מפתח. הסדר, מהגבוה לנמוך: הגדרות מנוהלות, --settings לסשן הזה, .claude/settings.local.json, .claude/settings.json המשותף, ~/.claude/settings.json. מפתח ברמה גבוהה דורס את אותו מפתח מתחתיו. מפתח שמשאירים מחוץ ל---settings שומר את הערך מהקבצים. דגלים אחרים, כמו --model, קובעים דבר אחד לסשן ואינם חלק מהמחסנית הזו: הרשומה של המפתח בתיעוד ההגדרות אומרת אילו דגלים דורסים אותו. משתני סביבה אינם רמה במחסנית. כשיש גם משתנה מעטפת וגם מפתח, מי חל נקבע לכל זוג: ANTHROPIC_MODEL שיוצא במעטפת חל מעל מפתח model מכל קובץ, ו-ANTHROPIC_DEFAULT_MODEL חל רק כשאף קובץ אינו קובע model. בלוק env בתוך קובץ הגדרות הוא מפתח רגיל ועוקב אחרי הרמות.
• הקובץ אינו יכול לקבוע את הערך. permissions.defaultMode בערכים auto ו-bypassPermissions אינו נכנס לתוקף מהגדרות פרויקט או מקומיות. קובעים אותם בהגדרות משתמש או מנוהלות, או מעבירים --permission-mode לסשן אחד. לפני v2.1.257 ערך bypassPermissions נכנס לתוקף מכל קובץ. משתנה ייצוא טלמטריה בבלוק env גם אינו נכנס לתוקף מהגדרות פרויקט או מקומיות, חוץ מכמה ערכי כיבוי. הרשימה והערכים האלה מפורטים בתיעוד הרשמי של משתנים שקלוד קוד מתעלם מהם ב-env.
• מפתח שמצמצם סשן נשמר גם כשמקור מנוהל קובע ערך רופף יותר. קלוד קוד מכבד את הערך המצמצם לפי הטבלה, גם כשהיקף אחר אינו יכול לדרוס הגדרה מנוהלת.

• מפתח בקובץ שבמאגר ממתין לאמון. permissions.allow, permissions.additionalDirectories, extraKnownMarketplaces, ורוב ערכי env חלים רק אחרי שסומכים על התיקייה. כללי deny ו-ask חלים מיד.
• מפתח בקובץ המאגר מתעלמים ממנו לפי ההיקף. בעמודת Scope באינדקס ההגדרות הרשמי, מפתח שמסומן User, local, or managed, User or managed, User, Managed, או Global config אינו חל מהקובץ המשותף, חוץ מכמה מפתחות שקובץ מאגר עדיין יכול לכבות. כל רשומה כזו אומרת זאת בשורת Scope שלה. מפתחות Global config חלים רק מ-~/.claude.json. בתוך env, משתני ייצוא הטלמטריה גם אינם חלים מהקובץ המשותף, חוץ מכמה ערכי כיבוי.
• הקובץ שבור. JSON לא תקין או ערך שהסכימה דוחה: בסשן אינטראקטיבי מוצגת Settings Error כשקובץ משתמש, פרויקט או מקומי פגום, ואפשר לתקן עם קלוד, לצאת, או להמשיך בלי ההגדרות השבורות. Settings Warning משאירה את שאר הקובץ ומדלגת על רשומות בודדות, כמו כלל הרשאה פגום או שם אירוע hook לא מוכר. בהגדרות מנוהלות קלוד קוד ממשיך לאכוף את שאר הקובץ. מה שמושמט, ואילו מפתחות נופלים לערך מחמיר יותר עד התיקון, מפורט בתיעוד הרשמי של רשומות לא תקינות בהגדרות מנוהלות. מסמך מנוהל שאינו JSON תקין מפורט בתיעוד השגיאות הרשמי. כשאי אפשר לפרק את ~/.claude.json, קלוד קוד מעתיק את הקובץ השבור אל ~/.claude/backups/.claude.json.corrupted.<timestamp> ושואל אם לצאת ולתקן ידנית או לאפס לתצורה המוגדרת. הרצת -p מדפיסה את השגיאה ויוצאת. כדי לשחזר מצב קודם מעתיקים חזרה אחד מחמשת קובצי .claude.json.backup.<timestamp> האחרונים ב-~/.claude/backups/, שקלוד קוד שומר לפני כתיבה. בהרצת -p אין תיבה, חוץ ממסמך מנוהל שאי אפשר לפרק: קלוד קוד מדלג על הקובץ או על הערכים וממשיך. אחר כך מריצים claude doctor.
• שינוי מתוך קלוד קוד נעלם בסשן הבא. בחירה שנשמרת לסשנים חדשים מתוך קלוד קוד, למשל מודל ברירת מחדל עם /model, נכתבת אל ~/.claude/settings.json. אם אי אפשר לכתוב לקובץ, למשל כי כלי אחר מייצר אותו או מקשר אותו לעותק לקריאה בלבד, השינוי חל על הסשן הנוכחי ונעלם בסשן הבא. קובעים את המפתח בכלי שמייצר את הקובץ, או מחליפים את הקובץ בקובץ שאפשר לכתוב אליו. אם הכתיבה אפשרית והשינוי עדיין אינו נשאר, בודקים אם הוא היה לסשן אחד בלבד, או אם רמה גבוהה יותר קובעת את אותו מפתח.
• שינוי מנוהל עדיין לא הגיע. מקורות מנוהלים מגיעים לסשן רץ לפי לוח הזמנים בטבלת המסירה בתיעוד הרשמי, ולכן קודם מפעילים מחדש את הסשן. אם /status מציין אחר כך מקור אחר מזה שהמנהל שינה, חל מקור בעדיפות גבוהה יותר. סדר השילוב מפורט בתיעוד הרשמי על שילוב מקורות מנוהלים.
• כללי allow מצטרפים אחרת מהצפוי. "Yes, and don't ask again" שומר כלל allow בקובץ המקומי, וכלל שם אינו גובר על כלל ask מקובץ פרויקט או מנוהל. בהרחבת VS Code כרטיס האישור מאפשר לבחור את קובץ היעד, כולל הקובץ המשותף, וכלל שם משנה את ההתנהגות לכולם. ב-CLI קלוד קוד כותב רק לקובץ המקומי. כללי allow של הארגון ממשיכים לחול לצד הכללים שלך, כי permissions.allow מתמזג בין היקפים, אלא אם הארגון קובע allowManagedPermissionRulesOnly.

סשן בענן רץ על שכפול חדש של המאגר, לא על המכונה שלך, ולכן מגיעות אליו רק חלק מההגדרות. .claude/settings.json המשותף נקרא כשיש מאגר אחד, כי הקובץ חלק מהשכפול והסשן מתחיל בתוכו. בסביבה ש-Anthropic מארחת, סשן עם כמה מאגרים מתחיל מעל השכפולים וקורא מכל מאגר רק את enabledPlugins ו-extraKnownMarketplaces, לא כללי הרשאה, hooks, env, או מפתחות אחרים. השווקים והתוספים ששני המפתחות האלה מכריזים עדיין אינם נטענים בסשן בענן. לסביבה באירוח עצמי, איזה קובץ הגדרות של מאגר חל מפורט בתיעוד הרשמי של סביבות באירוח עצמי. הגדרות משתמש והגדרות מקומיות אינן נקראות בענן: שתיהן נשארות על המכונה, והקובץ המקומי אינו בשכפול. קובץ managed-settings.json או פרופיל MDM על המכשיר אינם מגיעים לסשן בענן. הגדרות מנוהלות מהשרת מגיעות לסשני הענן שהכיסוי הרשמי שלהן כולל. סביבה באירוח עצמי קוראת גם את קובץ ההגדרות המנוהלות בתמונת ה-runner. מתי הקובץ הזה חל מפורט בתיעוד הרשמי על שילוב מקורות מנוהלים. ב-claude.ai/code, /config פותח את מקטע קלוד קוד בהגדרות claude.ai ואינו משנה ערך. כדי לשנות הגדרה לסשן בענן קובעים משתנה סביבה על הסביבה, או, בסשן עם מאגר אחד, מבצעים commit של המפתח אל .claude/settings.json של המאגר.

#תיקיות עבודה

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

• בהפעלה: --add-dir <path>
• במהלך הסשן: /add-dir
• באופן קבוע: additionalDirectories בקבצי ההגדרות

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

אי אפשר להוסיף את רוב נתיבי הרשת, כמו שיתוף UNC \\server\share, כתיקיות עבודה, כי איתור הנתיב יכול לפנות למארח שהוא מציין. ב-Windows ממפים את השיתוף לאות כונן ומעבירים את הכונן עם --add-dir בהפעלה.

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

בסשני רקע ב-macOS, מארח הסשן מבקש גישה לתיקיות מוגנות כמו ~/Desktop, ~/Documents ו-~/Downloads בנפרד מהטרמינל, כשקלוד צריך לקרוא או לכתוב שם. אם הקריאה נכשלת עם Operation not permitted, אופן מתן הגישה מפורט בתיעוד הרשמי של סשני רקע.

#תיקייה נוספת נותנת גישה לקבצים, לא הגדרות

הוספת תיקייה מרחיבה איפה קלוד קורא ועורך. היא אינה הופכת את התיקייה לשורש הגדרות מלא: רוב מה שב-.claude/ אינו מתגלה מתיקיות נוספות, חוץ מהסוגים בטבלה.

החריגים חלים רק על תיקיות שנוספו עם --add-dir או /add-dir, כולל תיקיות שה-Agent SDK מוסיף דרך הדגל. רשומות permissions.additionalDirectories בקובץ הגדרות נותנות גישת קבצים בלבד ואינן טוענות את ההגדרות שלמטה.

האפשרות additionalDirectories ב-TypeScript והאפשרות add_dirs ב-Python של ה-SDK מקבלות את אותם חריגים, אף שהשם ב-TypeScript זהה למפתח בהגדרות. ה-SDK מעביר כל רשומה אל קלוד קוד כ---add-dir. skills, פקודות ו-subagents מכל תיקייה שנוספה בדגל נטענים דרך מקור ההגדרות project, ולכן אינם נטענים כשמוציאים את המקור עם --setting-sources או עם settingSources. מצב bare מדלג על הפקודות וה-subagents מתוכם.

כדי לטעון skills, פקודות ו-subagents מתת תיקייה של ספריית העבודה הראשית באמצע סשן, מריצים /add-dir עם הנתיב שלה. קלוד קוד טוען אותם להמשך הסשן בלי לבקש ובלי להוסיף תיקיית עבודה, כי התת תיקייה כבר קריאה. דורש v2.1.257 ומעלה.

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

כדי לשתף את ההגדרה בין פרויקטים: שמים קבצים ב-~/.claude/agents/, ב-~/.claude/output-styles/, או ב-~/.claude/settings.json. אורזים אותה כתוסף. או מפעילים את קלוד קוד מהתיקייה שמכילה את .claude/ הרצוי.

#תחביר כללי הרשאה

כללי הרשאה עוקבים אחרי הפורמט Tool או Tool(specifier). סוגריים בתוך ה-specifier הם מילוליים, כך שפקודה או נתיב שמכילים אותם לא דורשים escaping.

#התאמה לכל השימושים בכלי

כדי להתאים לכל השימושים בכלי, השתמשו רק בשם הכלי בלי סוגריים:

Bash(*) שקול ל-Bash ומתאים לכל פקודות Bash. ככלל deny, שתי הצורות מסירות את הכלי מההקשר של Claude.

#שימוש ב-specifiers לשליטה עדינה

הוסיפו specifier בסוגריים כדי להתאים לשימושים ספציפיים בכלי:

#התאמה לפי פרמטר קלט

כללי deny ו-ask יכולים להתאים לפרמטר קלט ברמה העליונה בכל כלי מובנה עם Tool(param:value).

כדי להתאים לפרמטר בכלי MCP, העבירו כלל deny עם --disallowedTools. כש-Claude Code טוען קובץ הגדרות, הוא מדלג על כל כלל mcp__ שיש בו סוגריים. Claude Code מציג את הכלל שדולג בתיבת הדו-שיח invalid-settings כשמתחיל סשן אינטראקטיבי, וגם בפלט של claude doctor.

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

התאמת פרמטרים עוקבת אחרי הכללים האלה:

• שם הפרמטר חייב להיות שדה ישיר של קלט הכלי, למשל model בכלי Agent. שדות מקוננים בתוך אובייקט או מערך אינם ניתנים להתאמה
• כל כלל מציין פרמטר אחד. כדי לשלוט גם ב-model וגם ב-isolation, כתבו שני כללים, Agent(model:opus) ו-Agent(isolation:worktree), במקום לשלב אותם בכלל אחד
• הערך תומך ב-* כתו כללי שמתאים לכל רצף תווים, כך ש-Agent(isolation:*) מתאים לכל ערך isolation מפורש. בלי * ההתאמה מדויקת
• פרמטר שהמודל משמיט אף פעם לא מותאם, כך ש-Agent(model:*) לא מתאים לקריאה שמשאירה את model לא מוגדר
• הערך מושווה מול הקלט המילולי ש-Claude שולח, לפני כל נרמול. Agent(model:opus) מתאים לכינוי opus אבל לא למזהה מודל מלא. הריצו עם --verbose כדי לראות את שמות הפרמטרים והערכים המדויקים בכל קריאת כלי
• כלל deny מסוג Skill(skill:<name>) מתאים ל-skill תחת כל אחד מהשמות שלו, כמו כינוי או שם תצוגה
• רווחים סביב הנקודתיים מתעלמים מהם

אי אפשר להתאים כך לשדה התוכן הראשי של כלי: command עבור Bash ו-PowerShell, file_path עבור Read, Edit ו-Write, path עבור Grep ו-Glob, notebook_path עבור NotebookEdit, ו-url עבור WebFetch. כלל כמו Bash(command:rm *) היה ניתן לעקיפה באמצעות פקודה מורכבת, לכן Claude Code מתעלם ממנו ופולט אזהרת אתחול. השתמשו במקום זאת ב-Bash(rm *), Read(./path) או WebFetch(domain:host).

#תבניות תו כללי

* בכלל Bash מתאים לכל טקסט, כולל רווחים, כך שכלל אחד מכסה משפחה של פקודות. כלל בלי * מתאים לפקודה מדויקת אחת.

שימו את * אחרי תת-הפקודה. ב-git log --oneline main, git הוא התוכנית ו-log הוא תת-הפקודה, המילה שקובעת מה התוכנית עושה. Claude Code מתאים את כל מה שלפני ה-* הראשון כפי שנכתב, כך שהמילים האלה הן מה שמגביל את הכלל: Bash(git log *) מאפשר רק פקודות git log, ו-Bash(git *) מאפשר כל פקודת git. Claude Code מזהיר באתחול על כלל allow עם * לפני תת-הפקודה, למשל Bash(git * main).

כתבו את הפקודה שאתם רוצים ש-Claude יריץ בלי לשאול, והחליפו את החלקים שמשתנים ב-*. עם התצורה הזו, Claude Code מריץ סקריפטי npm ו-git commits בלי לשאול ומסרב לפקודות שמתחילות ב-git push. push שנכתב בדרך אחרת, למשל git -C . push, לא מותאם; ראו מה כלל Bash לא מתאים.

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

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

שלושה כללי התאמה מייצרים את השורות האלה:

• ה-* עומד במקום כל טקסט שנמצא במקומו. ב-Bash(git * main), הוא עומד במקום תת-הפקודה, כך ש-Claude Code מתאים לכל תת-פקודת git ולכל אפשרות שלפניה. זה כולל -c, שגורם ל-git להריץ תוכנית שאתם מציינים. ב-Bash(* --version), ה-* עומד במקום התוכנית, כך שכל תוכנית מתאימה.
• * בסוף, עם רווח לפניו, מתאים גם לפקודה החשופה. Bash(ls *) מתאים ל-ls, ו-Bash(git log *) מתאים ל-git log. זה תקף רק כשה-* הסופי הוא התו הכללי היחיד בכלל: Bash(* --help *) מתאים ל-npm --help x אבל לא ל-npm --help.
• הרווח לפני * סופי הוא חלק מהכלל. Bash(ls *) דורש רווח אחרי ls, כך ש-lsof לא מתאים. ל-Bash(ls*) אין רווח, כך שהוא מתאים גם ל-lsof.

הסיומת :* היא דרך שקולה לכתוב תו כללי סופי, כך ש-Bash(ls:*) מתאים לאותן פקודות כמו Bash(ls *).

תיבת הדו-שיח של הרשאות כותבת את הצורה המופרדת ברווחים כשאתם בוחרים "Yes, and don't ask again" לקידומת פקודה. הצורה :* מזוהה רק בסוף תבנית. בתבנית כמו Bash(git:* push), הנקודתיים מטופלות כתו מילולי ולא יתאימו לפקודות git.

#תווים כלליים בשם כלי

כללי deny ו-ask מקבלים גם תבניות glob בעמדת שם הכלי. התבנית חייבת להתאים לשם הכלי המלא: "*" מתאים לכל כלי, ו-"mcp__*" מתאים לכל כלי MCP בכל השרתים. כלי שמותאם על ידי כלל deny של glob בשם חשוף מוסר מההקשר של Claude, כמו שם כלי חשוף, כולל החריג של EndConversation: glob deny לא יכול להסיר אותו כל עוד נשאר כלי אחר, ו-glob ask אף פעם לא מבקש אישור עבורו. התצורה הזו דוחה כל כלי MCP:

{
  "permissions": {
    "deny": [
      "mcp__*"
    ]
  }
}

כללי allow מקבלים glob בשם כלי רק אחרי קידומת מילולית mcp__<server>__. מקטע השרת חייב להיות בלי glob כדי שהכלל יציין שרת ספציפי שהגדרתם. mcp__puppeteer__* מתאים לכל כלי משרת puppeteer, ו-mcp__github__get_* מתאים לכלי get_ שלו. glob allow לא מעוגן כמו "*", "B*", או "mcp__*" מדולג עם אזהרה ולא מאשר אוטומטית דבר.

כלל deny או ask ששם הכלי שלו לא מתאים לכלי ידוע מייצר אזהרת אתחול כדי לתפוס שגיאות הקלדה. שמות כלים שמכילים _ או * פטורים מהבדיקה, וכך גם שמות כלים ש-Claude Code הסיר, למשל TaskOutput.

התווית שמוצגת לכלי בתמליל ובתיבת הדו-שיח של הרשאות יכולה להיות שונה מהשם הקנוני שלו. למשל, הכלי שמסומן Stop Task בתמליל יש לו שם קנוני TaskStop. כללי הרשאה ו-מתאמי hook לא מתאימים לתווית, כך שכלל שנכתב כ-Stop Task לא מתאים. לכללי deny ו-ask, אזהרת האתחול למעלה תופסת את אי ההתאמה. השתמשו בשמות הקנוניים המופיעים ב-tools reference.

#מה כלל Bash לא מתאים

כלל Bash מתאים לטקסט הפקודה שקלוד כותב, אחרי שקלוד קוד מפצל פקודות מורכבות ומסיר עטיפות. הוא אינו מתאים לאותה תוכנית בצורה אחרת, ולכן כלל deny או ask מכסה את הצורה שקלוד בדרך כלל מייצר ואינו גבול אבטחה סביב התוכנית. שאר הכללים ומצב ההרשאה מכריעים את הפקודות בעמודה האחרונה. לאכיפה שאינה תלויה בטקסט הפקודה משתמשים ב-sandbox, ולבדיקה של הטקסט המלא לפני הריצה ב-hook מסוג PreToolUse.

המפרידים המוכרים הם &&, ||, ;, |, |&, &, ושורות חדשות. כלל צריך להתאים לכל תת פקודה בנפרד. כללי deny ו-ask חלים כשתת פקודה כלשהי מתאימה, כולל פקודה בתוך subshell, החלפת פקודה, או גוף לולאה כמו for. כלל ask כמו Bash(git clean *) עדיין מבקש אישור עבור cd /tmp && git clean -f או echo "$(git clean -f)", גם במצב auto. כש-&& או || בלי כלום אחריהם, למשל npm test &&, הפקודה נחשבת לא ניתנת לניתוח ואינה מפוצלת להתאמת כלל allow, כך ש-Bash(npm *) אינו מאשר אותה. אישור "Yes, and don't ask again" לפקודה מורכבת שומר כלל נפרד לכל תת פקודה שדורשת אישור, עד 5 כללים, ולא כלל אחד למחרוזת כולה. אישור של git status && npm test שומר כלל ל-npm test, כך שהרצות מאוחרות של npm test מזוהות בלי קשר למה שלפני ה-&&. תת פקודה כמו cd אל מחוץ לתיקיות העבודה מייצרת כלל Read משלה לאותו נתיב.

לפני התאמה מוסרות עטיפות קבועות: timeout, time, nice, nohup, ו-stdbuf, וגם ה-builtins command ו-builtin, ו-noglob של zsh. אינן מוסרות הצורה command -v ו-nocorrect של zsh. גם השמת משתני סביבה ידועים כבטוחים מוסרת, כך ש-Bash(npm test *) מתאים ל-NODE_ENV=test npm test. כלל allow אינו עובר השמה של משתנה אחר. כלל deny או ask עובר כל השמה מובילה. xargs חשוף בלי דגלים מוסר, כך ש-Bash(grep *) מתאים ל-xargs grep pattern. עם דגלים, כמו xargs -n1 grep pattern, ההתאמה היא לפקודת xargs. הרשימה מובנית ואינה ניתנת להגדרה. direnv exec, devbox run, mise exec, npx, ו-docker exec אינם בה. כלל כמו Bash(devbox run *) מתאים לכל מה שאחרי run, כולל devbox run rm -rf .. כדי לאשר עבודה בתוך רץ סביבה כותבים כלל שמכיל גם את הרץ וגם את הפקודה הפנימית, למשל Bash(devbox run npm test), כלל אחד לכל פקודה פנימית. עטיפות כמו watch, setsid, ionice, ו-flock אינן מאושרות אוטומטית על ידי כלל קידומת כמו Bash(watch *), ובמצב Manual הן תמיד מבקשות אישור. אותו דבר ל-find עם פעולה שמריצה פקודות, מוחקת קבצים או כותבת קבצים, כמו -exec, -delete, או -fprint, או עם -files0-from, שלוקח את הנתיבים לחיפוש מקובץ: כלל Bash(find *) אינו מכסה את הצורות האלה. לאישור קריאה מסוימת בלי * כותבים כלל התאמה מדויקת למחרוזת הפקודה המלאה, למשל Bash(find build -type f -delete). כשיש * בפקודה, כמו find . -name '*.tmp' -delete, קלוד קוד קורא את הכלל כתבנית תו כללי ולא כהתאמה מדויקת, והפקודה עדיין מבקשת אישור. מאשרים בכל פעם, או משתמשים ב-hook מסוג PreToolUse שמחזיר "allow".

תבנית שמנסה להגביל ארגומנטים שבירה. למשל Bash(curl http://github.com/ *) אינו מתאים ל-curl -X GET http://github.com/..., ל-curl https://github.com/..., להפניה, או למשתנה. לסינון URL אמין יותר חוסמים curl ו-wget בכלל deny ומשתמשים ב-WebFetch(domain:github.com), ומצמידים את רשימת הרשת של ה-sandbox כי כלל deny אינו תופס את התוכנית לפי נתיב או בתוך sh -c. אפשר גם hook מסוג PreToolUse. הנחיה ב-CLAUDE.md מעצבת מה קלוד מנסה ואינה אוכפת גבול. WebFetch לבדו אינו מונע גישת רשת אם Bash מותר.

פקודות קריאה מובנות רצות בלי בקשה בכל מצב, חוץ ממה ש-permissions.blockReadsOutsideWorkingDirectories משנה לנתיבים מחוץ לתיקיות העבודה. הקבוצה כוללת ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, וצורות קריאה בלבד של git. הקבוצה אינה ניתנת להגדרה. כדי לדרוש בקשה מוסיפים כלל ask או deny. במצב auto הפקודות האלה יכולות גם להמתין לבדיקת המסווג. תבנית glob לא מצוטטת מותרת כשכל דגל הוא לקריאה בלבד, כך ש-ls *.ts ו-wc -l src/*.py רצים בלי בקשה. הפניה כמו ls > out.txt מוסיפה בדיקה על היעד.

במצב Manual פקודות מהקבוצה עדיין מבקשות אישור במקרים האלה:

• glob לא מצוטט בפקודה עם דגלים שיכולים לכתוב או להריץ, כמו find, sort, sed, ו-git, כי ה-glob עלול להתפשט לדגל כמו -delete.
• docker עם דגל שבוחר daemon אחר, כמו -H, --context, או --url ו---connection של Podman.
• file עם -m או --magic-file, או -f או --files-from.
• ps כשאחד הארגומנטים יכול לפעול כאפשרות e, כמו ps auxe או ps aux -e, כי האפשרות מדפיסה משתני סביבה של תהליכים. ps aux ו-ps -ef רצים בלי בקשה. הבדיקה על צורות עם מקף כמו ps aux -e דורשת קלוד קוד v2.1.290 ומעלה.
• ארגומנט שהוא נתיב רשת UNC ב-Windows, כמו \\server\share\file. אותה בדיקה חלה על פקודות כלי PowerShell.
• פקודה שמגדירה, מבטלת, או רצה בלולאה על משתני מעטפת מיוחדים כמו PATH או IFS.
• פקודה שהניתוח אינו יכול לפרק במלואה. פקודה ארוכה מ-10,000 תווים תמיד מבקשת אישור.

cd לנתיב בתוך ספריית העבודה או ספרייה נוספת הוא גם קריאה בלבד, ופקודה מורכבת כמו cd packages/api && ls רצה בלי בקשה כשכל חלק עומד בפני עצמו. cd יחד עם git מבקש אישור כשה-cd עובר לתיקייה אחרת, כי git בתיקייה חדשה יכול להריץ hooks שלה. cd שהיעד שלו הוא ספריית העבודה הנוכחית אינו מפעיל את הבקשה. cd עם הפניה מבקש אישור כשאי אפשר לדעת לאיזו תיקייה יעד ההפניה מתייחס אחרי ה-cd. פקודה שהפניה היחידה שלה היא אל /dev/null, כמו cd app; grep -r pattern . 2>/dev/null, אינה מבקשת אישור.

כשפקודה מפנה פלט או קלט, היעד נבדק מול כללי הקבצים כאילו קלוד כתב או קרא את הקובץ ישירות. בהפניית פלט >, >>, או 2>, הבדיקה מכסה כללי Edit של allow ו-deny, נתיבים מוגנים, ותיקיות עבודה. כלל כמו Bash(git commit *) מתיר את הפקודה, לא את היעד. יעד שמתחיל ב-~ או מכיל תו glob דורש אישור. בהפניית קלט <, הבדיקה מכסה כללי Read ותיקיות עבודה. דורש v2.1.257 ומעלה. יעד מחוץ לתיקיות העבודה דורש אישור אלא אם כלל allow מכסה אותו. יעד עם תבנית glob, או נתיב יחסי שאחרי cd באותה פקודה, דורש אישור גם כשכלל allow מכסה אותו. יעדים בלי קובץ מאחוריהם אינם נבדקים: /dev/null, צורות מתאר קובץ כמו 2>&1 ו-<&3, ו-here-doc ו-here-string. קבצים ש-tee כותב נבדקים גם בצינור כמו make | tee build.log, מגרסה v2.1.269. כלל Bash(tee *) אינו מכסה יעד מחוץ לתיקיות העבודה. בדיקת tee מכסה כללי Edit של allow ו-deny, נתיבים מוגנים, ותיקיות עבודה.

כללי PowerShell באותה צורה. * מתאים בכל מקום, סיומת :* שקולה ל- * סופי, ו-PowerShell או PowerShell(*) מתאימים לכל פקודה. כינויים נפוצים מנורמלים לפני ההתאמה, כך שכלל על שם ה-cmdlet מתאים גם לכינויים: PowerShell(Get-ChildItem *) מתאים גם ל-gci, ל-ls ול-dir. ההתאמה אינה תלוית רישיות. העץ של PowerShell מפוצל לפי |, ;, וב-PowerShell 7 ומעלה גם && ו-||. הכלל צריך להתאים לכל תת פקודה.

{
  "permissions": {
    "allow": [
      "PowerShell(Get-ChildItem *)",
      "PowerShell(git commit *)"
    ],
    "deny": [
      "PowerShell(Remove-Item *)"
    ]
  }
}

#קריאה ועריכה

כדי לחסום קריאת קובץ או תיקייה מוסיפים כלל Read ב-deny, כמו Read(./.env) או Read(./secrets/**). אם בפרויקט יש קובץ .claudeignore, אין לו השפעה, ומעבירים את הרשומות שלו לכללי Read ב-deny. כללי Edit חלים על כל הכלים המובנים שעורכים קבצים. קלוד משתדל להחיל כללי Read על כלים מובנים שקוראים, כמו Grep ו-Glob, על אזכורי @file, ועל הקשר הבחירה והקובץ הפתוח ש-IDE מחובר משתף.

כלל Read ב-deny חל גם על נתיב תמונה שמדביקים בפרומפט או שגוררים לטרמינל, ועל תיקייה שמזכירים עם @. בקלוד קוד v2.1.290 ומעלה:

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

כלל Read ב-deny חוסם גם את Edit ו-Write על אותו נתיב, כולל יצירת קובץ חדש שם. NotebookEdit אינו מכוסה, ולכן מוסיפים כלל Edit ב-deny לנתיב שאף כלי לא ישנה. הבדיקה דורשת v2.1.208 ומעלה בעריכות, ו-v2.1.228 ומעלה בכתיבות.

בדיקת הרשאות קבצים נעשית רק מול Edit(path) ו-Read(path). כלל נתיב ל-Write, NotebookEdit, Glob, או MultiEdit הישן מתקבל אבל אינו נבדק, ומוצגת אזהרת אתחול, חוץ מכלל Glob שמועבר ב---allowedTools. משתמשים ב-Edit(docs/**) במקום Write(docs/**), NotebookEdit(docs/**) או MultiEdit(docs/**), וב-Read(docs/**) במקום Glob(docs/**). כלל על שם כלי בלי נתיב, כמו deny ל-Write, כן מותאם ברמת הכלי. דורש v2.1.210 ומעלה.

כללי deny של Read ו-Edit חלים על כלי הקבצים המובנים, על פקודות קובץ מוכרות ב-Bash כמו cat, head, tail, sed, ו-tee, ועל יעדי הפניות. הם אינם חלים על פקודה שקוראת קבצים בלי לנקוב בשמם, כמו grep -r pattern . מהתיקייה שמחזיקה את הקובץ, ולא על תהליך משנה שפותח קבצים בעצמו. לאכיפה ברמת מערכת ההפעלה מפעילים את ה-sandbox.

שני סוגי הכללים משתמשים בתחביר gitignore, עם ארבעה סוגי תבנית:

תבנית כמו /Users/alice/file אינה נתיב מוחלט. לוכסן מוביל יחיד מעגן למקור ההגדרות, לא לשורש. לנתיב מוחלט משתמשים ב-//Users/alice/file.

כלל שמוסיפים דרך /permissions עוקב אחרי השורה של הקובץ ששומרים אליו. כללי הגדרות מקומיות מעוגנים לספריית העבודה הראשית של הסשן, לא לשורש המאגר שבו הקובץ נשמר מגרסה v2.1.211. בסשן worktree, כלל משותף כמו Edit(/src/**) מתאים ל-src/ של אותו worktree. כלל deny כמו Read(/secrets/**) בהגדרות משתמש חוסם ~/.claude/secrets/**, לא תיקיית secrets בפרויקט. כדי שכלל בהגדרות משתמש יחול בתוך כל פרויקט משתמשים בנתיב // או ~/.

ב-Windows נתיבים מנורמלים לצורת POSIX לפני ההתאמה. C:\Users\alice הופך ל-/c/Users/alice, ולכן //c/**/.env מתאים לקובצי .env בכל מקום בכונן. לכל הכוננים משתמשים ב-//**/.env.

כלל מתאים רק לקבצים מתחת לעוגן שלו. שם קובץ חשוף עוקב אחרי gitignore ומתאים בכל עומק, כך ש-Read(.env) ו-Read(**/.env) שקולים.

דוגמאות עוגן: Edit(/docs/**) מתאים ל-<primary working directory>/docs/, לא ל-/docs/ ולא ל-<primary working directory>/.claude/docs/. Read(~/.zshrc) קורא את .zshrc בתיקיית הבית. Edit(//tmp/scratch.txt) עורך את הנתיב המוחלט /tmp/scratch.txt.

תבנית יחסית עם מקטע תיקייה יחיד, כמו src/**, תלויה בסוג הכלל:

• כללי allow: Edit(src/**) מתאים רק ל-<cwd>/src ולקבצים שמתחתיו. לשם תיקייה בכל עומק כותבים Edit(**/src/**).
• כללי deny ו-ask: Read(secrets/**) מתאים לתיקייה בשם secrets בכל עומק מתחת לספרייה הנוכחית.

כל צורת תבנית אחרת מתאימה באותו עומק בכל סוג כלל. ב-gitignore, * מתאים בתוך מקטע נתיב אחד, ו-** מתאים לרוחב תיקיות.

כשמאשרים נתיב עם "Yes, and don't ask again", תווי תבנית gitignore בנתיב, כמו [, ], ו-*, עוברים escaping כדי שהכלל יתאים רק לנתיב המילולי. כללים שכותבים בעצמכם אינם עוברים escaping. לפני v2.1.202 הנתיב נשמר בלי escaping, כך שכלל שנוצר לתיקייה בשם [2024-06] Reports יכול היה לא להתאים לנתיב שלה או להתאים לתיקיות אחיות שלא התכוונו אליהן. אין צורך ב-escaping לסוגריים, כך ש-Edit(./Finance (2024)/**) מתאים לתיקייה כפי שהיא כתובה. כלל deny או ask שהנתיב שלו אינו שמיש כתבנית gitignore עדיין שומר על הנתיב המדויק. כלל allow עם תבנית לא שמישה אינו מאשר דבר.

תבנית deny או ask שמתחילה ב-! היא שלילת gitignore. היא מוציאה את הנתיבים שהיא מתאימה להם מכללי path או ./path שרשומים לפניה באותו קובץ. באותה רשימת deny, Read(*.env) ואחריו Read(!sample.env) חוסמים כל קובץ שהשם שלו מסתיים ב-.env בכל עומק, חוץ מקבצים בשם sample.env. ! ראשון אינו מוציא דבר. ההוצאה מגיעה רק לכללים מאותו מקור. Read(!.env) בהגדרות פרויקט או ב---disallowedTools אינו מבטל Read(./.env) מהגדרות מנוהלות או מקובץ אחר. קלוד קוד קורא תבנית ! יחסית לספרייה הנוכחית גם כשאחרי ! באים /, ~/, או //, ולכן אי אפשר להוציא מכלל שמעוגן באחת מהקידומות האלה. Read(!~/notes/public/**) אינו מוציא דבר מ-Read(~/notes/**). אי אפשר גם לפתוח מחדש קובץ בתוך תיקייה שכלל חוסם כולה: עם Read(secrets/**) ו-Read(!secrets/public/**), secrets/public נשאר חסום.

כשנתיב עובר דרך symlink, הבדיקה מכסה את הנתיב שקלוד ביקש ואת הקובץ שהוא מפוענח אליו. זה חל על symbolic links ב-macOS, Linux ו-Windows, ועל directory junctions ב-Windows.

• כללי allow: חלים רק כשגם הנתיב המבוקש וגם הקובץ שהוא מפוענח אליו מתאימים.
• כללי deny: חלים כשאחד מהשניים מתאים. עם Read(./project/**) מותר ו-Read(~/.ssh/**) אסור, symlink ב-./project/key שמצביע אל ~/.ssh/id_rsa נחסם.

ב-macOS וב-Linux, כלל deny או ask שנכתב דרך תיקיית symlink עם תבנית //, ~/, או / חל גם במיקום האמיתי. למשל כש-/etc מפוענח אל /private/etc, Read(//etc/**) חוסם גם את /private/etc/hosts. לפני v2.1.268 כלל כזה לא חל על נתיב שניתן במיקום האמיתי. Grep ו-Glob מחפשים בתיקייה שארגומנט path מפוענח אליה, וכללי Read ב-deny חלים עליה.

אם הנתיב שקלוד מבקש לערוך או לכתוב הוא עצמו symlink, כלי Edit ו-Write מסרבים לכתיבה ומפנים את קלוד אל יעד הקישור. כתיבה עדיין יכולה לעבור דרך symlink כשתיקייה בדרך היא symlink, או כשפקודת Bash או PowerShell כותבת. אם הנתיב המבוקש בתוך תיקיות העבודה והקובץ שהוא מפוענח אליו אינו, הכתיבה אינה מאושרת אוטומטית במצב acceptEdits. במצב auto, אלא אם כלל allow מאשר את הכתיבה, מוצגת בקשה במקום שהמסווג יכריע, והבקשה מציינת את הנתיב שהכתיבה מפוענחת אליו. אם הפענוח מגיע לנתיב מוגן שהנתיב המבוקש אינו מציין, במקום שהטבלה מנתבת למסווג מוצגת בקשה. כשאי אפשר לקבוע לאן נתיב מוביל, למשל בלולאת symlinks, כלי Read, Edit ו-Write מסרבים. כשהכלי פותח את הקובץ שאושר, הוא מוודא שהנתיב עדיין מפוענח למיקום שהבדיקה אישרה.

#נתיבי רשת

כשכלי קריאת קבצים כמו Read, Grep ו-Glob קוראים מנתיב רשת, הקריאה מקבלת בדיקת הרשאה משלה. נתיב רשת הוא נתיב שיכול להגיע למחשב אחר: ב-Windows נתיב UNC כמו \\server\share\file, וב-macOS וב-Linux נתיב automount של /net כמו /net/fileserver/notes.txt. איתור הנתיב יכול לפנות למארח שהוא מציין, וב-Windows הפנייה יכולה לשלוח למארח את האישורים שלך. לפקודות מעטפת יש בדיקה משלהן: במצב Manual, פקודת Bash או PowerShell לקריאה בלבד שהארגומנטים שלה כוללים נתיב UNC עדיין מבקשת אישור ב-Windows.

בקלוד קוד v2.1.292 ומעלה, אלה משאירים את הבקשה במקום:

• כללי allow: כלל אינו מאשר מראש את הקריאה, כולל כלל על הכלי כולו כמו Read.
• hooks מסוג PreToolUse: hook שמחזיר "allow" אינו מדלג על הבקשה.
• מצב auto: הבקשה מגיעה אליך, והמסווג אינו מכריע את הקריאה.

במצב dontAsk הקריאה נדחית. במצב bypassPermissions, ובסשן טרמינל אינטראקטיבי במצב plan עם הרשאות bypass זמינות, הקריאה רצה בלי הבקשה הזו.

כדי לקרוא קבצים בשיתוף רשת בלי הבקשה, נותנים לשיתוף נתיב מקומי קודם:

• Windows: ממפים את השיתוף לאות כונן ומעבירים את הכונן עם --add-dir בהפעלה.
• macOS ו-Linux: מרכיבים את השיתוף בנתיב מקומי, למשל תיקייה תחת /mnt או /Volumes, וקוראים את הקבצים משם.

#WebFetch, MCP, סוכנים ו-Cd

כללי WebFetch משתמשים בקידומת domain: ומתאימים ל-hostname, בלי תלות ברישיות, עם *, ותו . סופי מוסר מהכלל ומה-hostname, כך ש-example.com. ו-example.com נחשבים אותו דבר. WebFetch(domain:*.example.com) מתאים לכל תת דומיין בכל עומק, לא ל-example.com עצמו. WebFetch(domain:*) מתאים לכל דומיין ואינו זהה לכלל WebFetch חשוף. בכל מקום שאינו *. מוביל או * חשוף, התו הכללי מתאים רק לטקסט בין שתי נקודות, כך ש-WebFetch(domain:example.*) מתאים ל-example.org ולא ל-example.evil.com. כך תו כללי בסוף אינו מתאים לדומיין שחוצה נקודה. תווים כלליים בכללי WebFetch דורשים v2.1.172 ומעלה כדי להתאים לשליפות.

כלל WebFetch חשוף ב-deny או ב-ask אינו חל על קריאת artifacts. כלל domain: שמכסה את claude.ai או את *.claudeusercontent.com, כמו WebFetch(domain:claude.ai) או WebFetch(domain:*), דוחה כל קריאה או מבקש לפניה. כלל Artifact עושה אותו דבר. כשכלל חוסם קריאה, הדחייה מציינת את הכלל. לפני v2.1.268 כלל deny חשוף חסם כל קריאת artifact, וכלל ask חשוף ביקש לפני כל אחת. כדי לאפשר שליפה חופשית בלי לשנות את רשימת ה-sandbox משתמשים בצורה החשופה:

{
  "permissions": {
    "allow": ["WebFetch"]
  }
}

עם הכלל הזה שליפת דף רצה בלי בקשה. curl ב-sandbox אל מארח שמחוץ לרשימת ההיתר עדיין מבקש אישור, כי הצורה החשופה אינה מוסיפה את המארח לרשימה. במצב auto קלוד מציין את המארח בדומיינים המותרים לאותה פקודה, לבדיקת המסווג.

כללי MCP משתמשים בשם השרת כפי שהוא מוגדר, ואפשר להוסיף שם כלי: mcp__puppeteer, mcp__puppeteer__*, או mcp__puppeteer__puppeteer_navigate. אם הארגון קבע כלי מחבר של claude.ai ל-ask וההגדרה מגיעה לסשן, כללי allow לכלי אינם נכנסים לתוקף: יש בקשה בכל קריאה, גם ב-auto וב-bypassPermissions. במצב dontAsk הקריאה נדחית. כלים ממחברים שקלוד קוד שולף בעצמו מופיעים כ-mcp__claude_ai_<server>__<tool>.

בסשן Cowork באפליקציית Desktop, קלוד מריץ מעטפת דרך mcp__workspace__bash ולא דרך Bash, ו-mcp__workspace__web_fetch לשליפות. כללי deny על הכלי Bash או WebFetch כולו חלים גם על כלי Cowork האלה, כך שכלל deny מנוהל על Bash עוצר פקודות מעטפת ב-Cowork. כשקלוד קוד חוסם קריאה כזו, ההודעה מציינת את כלי Cowork: Permission to use mcp__workspace__bash has been denied. כללי allow אינם עוברים: כלל allow של Bash אינו חל על mcp__workspace__bash.

כללי Agent(AgentName) שולטים ב-subagents: Agent(Explore), Agent(Plan), Agent(my-custom-agent). שמים אותם במערך deny או מעבירים ב---disallowedTools. כדי לכבות את Explore:

{
  "permissions": {
    "deny": ["Agent(Explore)"]
  }
}

כללי Cd שולטים לאן הפקודה /cd יכולה להעביר את הסשן. Cd אינו כלי שהמודל יכול לקרוא לו. הכללים חלים רק כשמריצים /cd בעצמכם. כלל Cd חשוף ב-deny מכבה את /cd לגמרי. כלל Cd(<path-pattern>) ב-deny חוסם יעדים תואמים, כולל כל כתיב וכל קפיצת symlink. הוספת כלל Cd כלשהו ב-allow מעבירה את /cd למצב רשימת היתר: תיקיית היעד המפוענחת חייבת להתאים לאחד מכללי ה-allow, אחרת /cd מסרב. בלי כללי Cd, /cd שומר את ברירת המחדל ומבקש לסמוך על תיקייה לא מוכרת. תבניות הנתיב חולקות את העוגנים //, ~/ ו-/ של כללי Read ו-Edit, אבל ההתאמה היא לנתיב התיקייה כולו ולא בסגנון gitignore. * מתאים למקטע אחד בדיוק, ** לרוחב מקטעים, ו-/** סופי מתאים גם לשורש שצוין.

נקודות פתיחה רשמיות לתצורות נפוצות נמצאות בתיקיית הדוגמאות examples/settings במאגר claude-code. מתאימים אותן לצורך.

#נתיבים מוגנים

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

בסשן שנפתח עם --restricted, שדורש v2.1.248 ומעלה, המסווג אינו יכול לאשר כתיבה לנתיב מוגן. במצבים שמנתבים כתיבה כזו למסווג, כתיבה שבדיקת symlink מפענחת לנתיב מוגן מבקשת אישור כשהנתיב שקלוד ביקש אינו מוגן בעצמו.

כללי permissions.allow אינם מאשרים מראש כתיבה לנתיב מוגן. בדיקת הבטיחות רצה לפני כללי allow מההגדרות, כך שרשומה כמו Edit(.claude/**) אינה משנה את התוצאה בטבלה. במצבים שמבקשים אישור, הבקשה לכתיבה אל .claude/ של הפרויקט או אל ~/.claude/ יכולה להציע אישור להיקף הסשן בלבד:

• לתיקיית .claude/ של הפרויקט: Yes, and allow Claude to edit files in this project's .claude folder for this session
• ל-~/.claude/: Yes, and allow Claude to edit files in its ~/.claude folder for this session

תיקיות מוגנות:

• .git
• .config/git
• .vscode
• .idea
• .husky
• .cargo
• .devcontainer
• .yarn
• .mvn
• .claude, עם החריגים האלה:
  • ה-worktrees של קלוד עצמו תחת .claude/worktrees/
  • קובצי התוכנית של הסשן הנוכחי ב-~/.claude/plans/, או ב-plansDirectory שהוגדר
  • תיקיית ה-scratch של סשן רקע ב-~/.claude/jobs/<id>/tmp/
  • קובצי Markdown בתיקיית ה-auto memory של הפרויקט, כמו ~/.claude/projects/<project>/memory/, בסשן שנפתח בלי --restricted
  • קובצי Markdown בתיקיית זיכרון של subagent, כמו .claude/agent-memory/, בסשן שנפתח בלי --restricted
• תיקייה שנטענה עם --plugin-dir, כי קלוד קוד טוען מחדש ומריץ משם את קוד המוד כשקובץ משתנה

קבצים מוגנים:

• .gitconfig, .gitmodules
• .bashrc, .bash_profile, .bash_login, .bash_aliases, .bash_logout, .zshrc, .zprofile, .zshenv, .zlogin, .zlogout, .profile, .envrc
• .npmrc, .yarnrc, .yarnrc.yml, .pnp.cjs, .pnp.loader.mjs, .pnpmfile.cjs, bunfig.toml, .bunfig.toml
• .bazelrc, .bazelversion, .bazeliskrc
• .pre-commit-config.yaml, lefthook.yml, lefthook.yaml, .lefthook.yml, .lefthook.yaml
• gradle-wrapper.properties, maven-wrapper.properties
• .devcontainer.json
• .ripgreprc, pyrightconfig.json
• .mcp.json, .claude.json
• קובץ שהועבר ל---settings, ל---mcp-config, או ל---agents בפתיחת הסשן
• הקובץ שקובץ ההגדרות של המשתמש, של הפרויקט, או המקומי מצביע אליו, כשקובץ ההגדרות עצמו הוא symbolic link, למשל אל מאגר dotfiles. במצבים שמנתבים כתיבה לנתיב מוגן אל המסווג, כתיבה לקובץ הזה מבקשת אישור גם כשכלל allow מתאים. אם הנתיב של הקובץ עצמו הוא גם נתיב של קובץ הגדרות, כמו .claude/settings.json בתיקייה אחרת, הכתיבה הולכת למסווג כמו שאר הכתיבות לנתיב מוגן

#נתיבים קריטיים

נתיבים קריטיים הם התיקיות שקלוד קוד מגן עליהן מפני rm ו-rmdir: שורש מערכת הקבצים, תיקיית הבית, וספריית העבודה. אף כלל permissions.allow ולא hook מסוג PreToolUse שמחזיר "allow" מאשרים rm או rmdir ליעד כזה, גם במצבים שמדלגים על בקשות אחרות. זה מפסק שמגן מפני טעות של המודל. כלל deny תואם עדיין חוסם את הפקודה לגמרי. ל-Remove-Item ולפקודות ההסרה של cmd יש בדיקות נפרדות.

יעד נחשב קריטי כשהוא אחד מאלה:

• שורש מערכת הקבצים
• תיקייה ברמה העליונה, כלומר בן ישיר של השורש, כמו /usr, /etc, או /data
• תיקיית הבית. ב-Windows גם השם הקצר 8.3 שלה נספר, כמו C:\Users\LONGNA~1
• שורשי כוננים ב-Windows והתיקיות העליונות שלהם, כמו C:\ ו-C:\Windows. כתיבים כמו \\?\C:\ ו-\\localhost\C$ נספרים כ-C:\
• ספריית העבודה וההורים שלה
• ספריות עבודה נוספות וההורים שלהן, אבל רק כשהמחיקה היא glob מתחת לאחת מהן, כמו rm -rf <dir>/*. rm -rf <dir> על התיקייה עצמה אינו מפעיל את הבדיקה הזו

הבדיקות על השם הקצר 8.3 ועל הכתיבים \\?\C:\ ו-\\localhost\C$ דורשות קלוד קוד v2.1.292 ומעלה.

יעדים נוספים נספרים גם הם:

כדי לכבות את הבדיקה על יעד שהוא רק פלט של החלפת פקודה, קובעים CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1 בסביבה שמפעילה את קלוד קוד.

קלוד קוד מסתכל גם בתוך פקודות מקוננות: subshell עם (...), קבוצת סוגריים מסולסלים, החלפת פקודה, והחלפת תהליך. הוא מוצא מחיקת נתיב קריטי בין שהיא בתוך הצורה המקוננת ובין שהיא במקום אחר באותה פקודה. בסקריפט שמועבר ל-sh, bash, zsh, או מעטפת POSIX דומה עם -c, נבדקים גם נתיבים קריטיים שכתובים בסקריפט. כשהסקריפט במירכאות כפולות, המעטפת הקוראת מרחיבה משתנים לפני שהמעטפת הפנימית מקבלת את הסקריפט. ב-find . -name '*.tmp' -exec sh -c "rm -rf \"$1\"/*" _ {} \; הפקודה מתפשטת למחיקה משורש מערכת הקבצים לכל התאמה, וקלוד קוד מתייחס לזה כמחיקת נתיב קריטי. סקריפט במירכאות בודדות שקושר את $1 לערך אמיתי, כמו sh -c 'rm -rf "$1"/*' _ {}, אינו מסומן.

כדי לכבות את הבדיקה על נתיב קריטי שכתוב ישירות בסקריפט -c, כמו ~, קובעים CLAUDE_CODE_DISABLE_INLINE_SHELL_RM_PROMPT=1 בסביבה שמפעילה את קלוד קוד.

כדי שפקודה תעבור את הבדיקה:

• glob או לוכסן סופי מתחת למשתנה כמו $DIR: שומרים כל הרחבה כך שהמעטפת נעצרת בשגיאה כשהמשתנה לא מוגדר או ריק, כמו rm -rf "${DIR:?}"/*, או משתמשים בנתיב מילולי. במצב bypassPermissions מחיקה שכל ההרחבות שלה שמורות כך רצה בלי בקשה, אלא אם בדיקת נתיב קריטי אחרת מסמנת אותה. בבקשה מהסוג הזה קלוד קוד מציין את ה-rm שסומן ואומר איך לכתוב את הפקודה מחדש כדי שהבדיקה תעבור.
• glob או לוכסן מתחת למשתנה שבדרך כלל מוגדר, כמו $HOME: משתמשים בנתיב מילולי.
• משתנה שהוצב מהחלפה שמדפיסה תיקייה: משתמשים בנתיב מילולי. שמירה "${D:?}" אינה מנקה את הבדיקה, כי המשתנה אינו ריק.
• יעד שהוא רק פלט של החלפת פקודה: מריצים את ההחלפה לבד, ואחר כך מוחקים את הנתיבים המילוליים שהיא מדפיסה. הבקשה אומרת לקלוד לעשות אותו דבר.

#הבקשה Dangerous rm operation not ruled out

הניסוח המלא אומר שהמעטפת עלולה לקרוא את הפקודה אחרת מאיך שקלוד קוד ניתח אותה. הסיבה הזו אומרת שמחיקה יכולה לשבת בחלק שלא נבדק, גם כשאין rm בפקודה. במצב auto או bypassPermissions, דחייה עם המשפט This command could not be checked for dangerous rm operations: the shell may read it differently than it was parsed. מגיעה מאותה בדיקה.

מקבלים את אותה בקשה או דחייה שמחיקת נתיב קריטי מקבלת במצב ההרשאה, כולל bypassPermissions. אי אפשר לאשר את הפקודה עם כלל Bash או Bash(*), עם מצב auto-allow של ה-sandbox, או עם hook מסוג PreToolUse שמחזיר "allow". קוראים את הפקודה, ואז מאשרים את הבקשה, או אחרי דחייה מריצים אותה במעטפת.

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

במצבי auto ו-bypassPermissions הבקשה בטרמינל מציגה ספירה לאחור של שתי דקות:

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

מגבלת הזמן חלה בקלוד קוד v2.1.281 ומעלה, וכך גם הדחייה של מצב auto מחוץ לטרמינל.

מחוץ לטרמינל אין את הבקשה הזו:

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

כדי לשנות מה מתקבל בכל מצב, קובעים CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT ל-1:

• ב-bypassPermissions: לבקשה בטרמינל אין מגבלת זמן, וחלונית הצ'אט של VS Code שואלת
• ב-auto: המסווג מכריע, בטרמינל, בחלונית הצ'אט של VS Code, בהרצות -p ובסשני Agent SDK

קובעים את המשתנה בסביבה שמפעילה את קלוד קוד, למשל במעטפת או באפשרות env של ה-SDK, לא בקובץ הגדרות של קלוד קוד. לחלונית הצ'אט מוסיפים אותו ל-claudeCode.environmentVariables בקובץ settings.json של VS Code עצמו, ואז פותחים שיחה חדשה:

{
  "claudeCode.environmentVariables": [
    { "name": "CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT", "value": "1" }
  ]
}

#Remove-Item ב-PowerShell

כשכלי PowerShell מופעל, ל-Remove-Item ולפקודות cmd המובנות rd, rmdir, del, ו-erase יש בדיקות נפרדות מרשימת rm. ל-Remove-Item המקרה הראשון שמתאים הוא זה שחל:

• נתיבי מערכת: שורש מערכת הקבצים והתיקיות העליונות שלו, שורשי כוננים והתיקיות העליונות שלהם, ותיקיית הבית. הפקודה נדחית בכל מצב, בלי לשאול.
• תווים כלליים: * חשוף, או כל יעד שמסתיים ב-/* או \*, כולל glob מתחת למשתנה כמו $dir/*. הפקודה נדחית בכל מצב, בלי לשאול, לפני שהמסווג רואה אותה.
• ספריית העבודה או אחד מההורים שלה, עם -Recurse: הפקודה מטופלת כמו כל פקודה שדורשת אישור במצב שלך. יש בקשה במצבים שמבקשים, שליחה למסווג במצב auto, ודחייה במצב dontAsk. מצב bypassPermissions מדלג על הבדיקה הזו.

מקרה נתיבי המערכת חל גם על rd, rmdir, del, ו-erase כשקלוד מריץ אותם דרך cmd, כמו cmd /c rd /s /q C:\Users. כברירת מחדל פקודה כזו נדחית בכל מצב, בלי לשאול. בדיקת cmd דורשת v2.1.283 ומעלה. בשיפוט יעד cmd, משתנה PowerShell שאחרי טקסט מילולי נחשב ריק, ולכן cmd /c rd /s /q "C:\$name" הוא מחיקה של C:\ וגם הוא נדחה. תו כללי סופי נספר כתיקייה שהוא מרוקן, כך ש-cmd /c del /q C:\* נדחה ו-cmd /c del /q dist\* בפרויקט אינו נדחה.

כדי לכבות את בדיקת cmd קובעים CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY=1 בסביבה שמפעילה את קלוד קוד. קלוד קוד מתעלם מהמשתנה בבלוק env של קובץ הגדרות. Remove-Item על נתיב מערכת נשאר דחוי בכל מקרה.

#קריאה מחוץ לתיקיות העבודה במצב auto

כאשר permissions.blockReadsOutsideWorkingDirectories כבויה, קריאות קבצים במצב auto רצות בלי בקשת אישור, כולל קריאה מחוץ לתיקיות העבודה, חוץ מקריאות מנתיבי רשת. בפעם הראשונה שקלוד משתמש בכלי Read, Grep או Glob על נתיב מחוץ להן, קלוד קוד שואל אם לאשר את הקריאה.

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

בכל תשובה קלוד ממשיך לעבוד:

• Yes, and keep allowing any reads outside the working directories: הקריאה רצה, קריאות מאוחרות מחוץ לתיקיות העבודה רצות כמו קודם, וקלוד קוד שומר את התשובה כדי שהבקשה לא תופיע שוב.
• No, and block reads outside the working directories from now on: הקריאה נדחית, וקלוד קוד קובע את permissions.blockReadsOutsideWorkingDirectories ל-true בהגדרות המשתמש. כלי הקבצים מסרבים לקריאות כאלה בכל סשן מאוחר יותר ובכל מצב הרשאה. כדי לאפשר לקלוד לקרוא נתיב כזה אחר כך, מוסיפים את התיקייה עם /add-dir או מסירים את ההגדרה.
• No, and ask again next time: הקריאה נדחית, והקריאה הבאה מחוץ לתיקיות העבודה מציגה בקשה שוב.
• Yes, but ask again next time: הקריאה רצה, דבר אינו נשמר, והקריאה הבאה מחוץ לתיקיות העבודה מציגה בקשה שוב.

פירוט מצבי ההרשאה וכללי הרשאה לכל כלי.