📘 תיעוד 132

הגדרת הרשאות

שליטה במה ש-Claude Code יכול לגשת אליו ולעשות, באמצעות כללי הרשאה מפורטים, מצבים ומדיניות מנוהלת.

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

#מערכת ההרשאות

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

בקשת הרשאה מציגה מה Claude עומד לעשות, ואחרי זה את האפשרויות שלך. הדוגמה הזו היא הבקשה לפקודת Bash, מסשן במצב Manual:

האפשרות השלישית, כן, ועבור למצב auto, לא מופיעה בכל בקשה.

כשבוחרים "כן, ואל תשאל שוב" והאישור נשמר לצמיתות, למשל עבור פקודת Bash או דומיין של WebFetch, Claude Code שומר את הכלל בקובץ .claude/settings.local.json בשורש מאגר ה-git, אחרי פתרון דרך worktrees אל ה-checkout הראשי. הכלל חל על סשנים עתידיים בכל מקום באותו מאגר, כולל סשנים שהתחילו בתת-ספריות וב-worktrees. אישור לשינוי קובץ לא נשמר בקובץ: כפי שהטבלה מראה, הוא נמשך עד סוף הסשן. במקרים מסוימים, למשל מחוץ למאגר git או ב-Windows, Claude Code לא משתמש בשורש המאגר. איפה Claude Code מחפש כל קובץ מפרט את המקרים האלה ואיפה הכלל נשמר במקומם.

לפעמים בקשת הרשאה מציעה רק אישור חד-פעמי, בלי אפשרות "אל תשאל שוב" ובלי אפשרות לאפשר את הפעולה לשאר הסשן. Claude Code מציע את האפשרויות האלה רק כשהבקשה יכולה להראות לך את כל מה שהן יאפשרו, ולכן כלל שנשמר מבקשה מכסה רק את מה שהאפשרות שלו נקבה בשמו. כשבקשה מציעה רק את האישור החד-פעמי, אשר את הפעולה פעם אחת, או הוסף את הכלל בעצמך ב-/permissions. כדי להפסיק את הבקשות לפקודה שמתחילה ב-exec wrapper כמו watch, או לפקודת find עם פעולה כמו -delete, ראה Exec wrappers ופעולות find.

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

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

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

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

Claude Code מעביר את ההערה בצורה שונה לפי אופן התשובה:

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

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

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

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

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

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

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

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

[!NOTE]

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

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

#מצבי הרשאה

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

[!WARNING]

במצב bypassPermissions, Claude Code מדלג על בקשות הרשאה, כולל לכתיבה אל נתיבים מוגנים כמו .git ו-.claude. אמצעי ההגנה על הודעות בין סשנים עדיין חלים. השתמש במצב הזה רק בסביבות מבודדות כמו קונטיינרים או מכונות וירטואליות, שבהן Claude Code לא יכול לגרום נזק.

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

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

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

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

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

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

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

#שימוש במציינים לשליטה מדויקת

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

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

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

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

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

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

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

אי אפשר להתאים כך לשדה התוכן העיקרי של כלי: 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 מתאים לכל טקסט, כולל רווחים, ולכן כלל אחד מכסה משפחה של פקודות. כלל בלי * מתאים לפקודה מדויקת אחת.

[!WARNING]

שימו את * אחרי תת-הפקודה. ב-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 בלי לשאול, ומסרב לפקודות שמתחילות ב-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.

#כללי הרשאה ייעודיים לכלי

#Bash

כללי Bash מתאימים לטקסט הפקודה כולו, כאשר * עומד במקום כל טקסט. תבניות תו כללי מראה אילו פקודות כל צורת כלל מתאימה והיכן לשים את *. שאר הסעיף מכסה איך Claude Code מתאים פקודות מורכבות ועטיפות, אילו עטיפות ופעולות find כלל קידומת לא יכול לאשר, מה כלל לא מתאים, פקודות לקריאה בלבד, והפניות.

#פקודות מורכבות

[!TIP]

Claude Code מזהה אופרטורים של shell, ולכן כלל כמו Bash(safe-cmd *) לא נותן לו הרשאה להריץ את הפקודה safe-cmd && other-cmd. מפרידי הפקודות המוכרים הם &&, ||, ;, |, |&, &, ושורות חדשות. כל תת פקודה חייבת להיות מותרת כדי שפקודה מורכבת תרוץ בלי בקשת אישור, למשל מפני שהתת פקודה מתאימה לכלל allow או שהיא פקודה לקריאה בלבד.

כללי deny ו ask חלים כאשר תת פקודה כלשהי מתאימה להם, כולל פקודה מקוננת בתוך תת shell, החלפת פקודה, או גוף של בקרת זרימה כמו לולאת for. כלל ask כמו Bash(git clean *) עדיין מבקש ממך אישור עבור cd /tmp && git clean -f או echo "$(git clean -f)", גם במצב auto.

כאשר אין כלום אחרי && או ||, כמו ב npm test &&, Claude Code מתייחס לפקודה כבלתי ניתנת לניתוח ולא מפצל אותה לתת פקודות לצורך התאמה לכללי allow, ולכן כלל כמו Bash(npm *) לא מאשר אותה.

כאשר מאשרים פקודה מורכבת עם "Yes, and don't ask again", Claude Code שומר כלל נפרד לכל תת פקודה שדורשת אישור, במקום כלל יחיד למחרוזת המורכבת המלאה. לדוגמה, אישור git status && npm test שומר כלל עבור npm test, כך שהרצות עתידיות של npm test מזוהות בלי קשר למה שקודם ל &&. תת פקודות כמו cd לתיקייה מחוץ לתיקיות העבודה שלך יוצרות כלל Read משלהן עבור הנתיב הזה. ייתכן שיישמרו עד 5 כללים עבור פקודה מורכבת אחת.

#עטיפות

לפני התאמת כללי Bash, Claude Code מסיר קבוצה קבועה של עטיפות, כך שכלל כמו Bash(npm test *) מתאים גם ל timeout 30 npm test. העטיפות שמוסרות הן timeout, time, nice, nohup, ו stdbuf, ובנוסף הפקודות המובנות של shell‏ command ו builtin, ו noglob של zsh. כל אחת מריצה את הארגומנט שלה כפקודה בפועל. שתי צורות קרובות לא מוסרות: צורת השאילתה command -v, שמאתרת פקודה במקום להריץ אחת, ו nocorrect של zsh.

Claude Code גם מסיר השמה מובילה של משתני סביבה מסוימים שידועים כבטוחים, כך ש Bash(npm test *) מתאים ל NODE_ENV=test npm test. כלל allow לא יתאים מעבר להשמה של כל משתנה אחר. כלל deny או ask מתאים מעבר לכל השמה מובילה, כך ש Bash(rm *) ב deny עדיין מתאים ל FOO=bar rm -rf tmp/.

גם xargs לבדו מוסר, כך ש Bash(grep *) מתאים ל xargs grep pattern. ההסרה חלה רק כאשר ל xargs אין דגלים: הרצה כמו 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). הוסף כלל אחד לכל פקודה פנימית שברצונך לאפשר.

#עטיפות exec ופעולות find

כלל קידומת כמו Bash(watch *) או Bash(find *) לא יכול לאשר אוטומטית את הפקודות הבאות, ולכן במצב Manual הן מבקשות אישור:

• עטיפות exec: כמו watch, setsid, ionice, ו flock
• find: עם פעולה שמריצה פקודות, מוחקת קבצים, או כותבת קבצים, כמו -exec, -delete, -rm, או -fprint, או עם -files0-from, שלוקח את הנתיבים לחיפוש מקובץ

כדי לאשר הפעלה ספציפית שאין בה *, כתוב כלל התאמה מדויקת למחרוזת הפקודה המלאה, כמו Bash(find build -type f -delete).

כאשר יש בפקודה *, כמו ב find . -name '*.tmp' -delete, Claude Code קורא את הכלל כתבנית תו כללי, לא כהתאמה מדויקת, ולכן הפקודה עדיין מבקשת אישור. אשר אותה בכל פעם שהיא מבקשת אישור, או השתמש בהוק PreToolUse שמחזיר "allow" עבורה.

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

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

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

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

#פקודות לקריאה בלבד

Claude Code מזהה קבוצה מובנית של פקודות Bash כקריאה בלבד ומריץ אותן בלי בקשת הרשאה בכל מצב, פרט לשינוי ש permissions.blockReadsOutsideWorkingDirectories עושה עבור נתיבים מחוץ לתיקיות העבודה שלך. הקבוצה כוללת את ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd, וצורות לקריאה בלבד של git. הקבוצה אינה ניתנת להגדרה. כדי לדרוש בקשת אישור עבור אחת מהפקודות האלה, הוסף עבורה כלל ask או deny. במצב auto, הפקודות האלה יכולות גם להמתין לסקירת המסווג. ראה איך המסווג מעריך פעולות.

הפניה כמו ls > out.txt מוסיפה בדיקה על היעד. ראה הפניות.

תבניות glob לא מצוטטות מותרות לפקודות שכל דגל בהן הוא לקריאה בלבד, כך ש ls *.ts ו wc -l src/*.py רצות בלי בקשת אישור.

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

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

גם cd לנתיב בתוך תיקיית העבודה שלך או תיקייה נוספת הוא לקריאה בלבד, ופקודה מורכבת כמו cd packages/api && ls רצה בלי בקשת אישור כאשר כל חלק עומד בתנאי בפני עצמו. השילובים האלה מבקשים אישור גם כאשר כל חלק הוא לקריאה בלבד:

• cd עם git: מבקש אישור כאשר cd עובר לתיקייה אחרת, מפני שהרצת git בתיקייה חדשה יכולה להפעיל את ה hooks של אותה תיקייה. cd שהיעד שלו מתפרש לתיקיית העבודה הנוכחית הוא no-op ולא מפעיל את בקשת האישור.
• cd עם הפניה: מבקש אישור כאשר Claude Code לא יכול לקבוע ביחס לאיזו תיקייה יעד ההפניה מחושב אחרי ש cd רץ. פקודה שהיעד היחיד של ההפניה שלה הוא /dev/null, כמו cd app; grep -r pattern . 2>/dev/null, לא מבקשת אישור, מפני ש /dev/null לא תלוי בתיקיית העבודה.

[!WARNING]

תבניות הרשאת Bash שמנסות להגביל ארגומנטים של פקודה שבירות. לדוגמה, Bash(curl http://github.com/ *) מיועד להגביל את curl לכתובות של GitHub, אבל לא יתאים לווריאציות כמו:

• אפשרויות לפני ה URL: curl -X GET http://github.com/...
• פרוטוקול אחר: curl https://github.com/...
• הפניות: curl -L http://short.example.com/xyz, שמפנה ל GitHub
• משתנים: URL=http://github.com && curl $URL

לסינון URL אמין יותר, שקול:

• הגבלת כלי רשת של Bash: השתמש בכללי deny כדי לעצור את curl, wget, ופקודות דומות, ואז השתמש בכלי WebFetch עם הרשאת WebFetch(domain:github.com) לדומיינים מותרים. כלל deny לא מתאים לאותה תוכנית לפי נתיב או בתוך sh -c, ולכן שלב אותו עם רשימת ההיתר של רשת ארגז החול כאשר ההגבלה חייבת להחזיק. ראה מה כלל Bash לא מתאים
• שימוש בהוקי PreToolUse: ממש הוק שמאמת כתובות URL בפקודות Bash וחוסם דומיינים לא מותרים
• הוספת הנחיה ב CLAUDE.md: תאר את תבניות curl המותרות שלך ב CLAUDE.md. זה מעצב את מה ש Claude מנסה אבל לא אוכף גבול, ולכן שלב את זה עם אחת מהאפשרויות למעלה

שים לב ששימוש ב WebFetch לבדו לא מונע גישה לרשת. אם Bash מותר, Claude עדיין יכול להשתמש ב curl, wget, או כלים אחרים כדי להגיע לכל URL.

#הפניות

כאשר פקודה מפנה פלט או קלט, Claude Code בודק את יעד ההפניה מול כללי הקבצים שלך כאילו Claude כתב או קרא את הקובץ ישירות:

• הפניות פלט: עבור > file, >> file, או 2> file, הבדיקה מכסה את כללי ה allow וה deny של Edit, נתיבים מוגנים, ואת תיקיות העבודה. כלל כמו Bash(git commit *) מתיר את הפקודה, לא את היעד. יעד שמתחיל ב ~ או שמכיל תו glob דורש את האישור שלך.
• הפניות קלט: עבור < file, הבדיקה מכסה את כללי ה allow וה deny של Read ואת תיקיות העבודה. יעד מחוץ לתיקיות העבודה דורש את האישור שלך אלא אם כלל allow מכסה אותו. יעד שמכיל תבנית glob, או נתיב יחסי שאחרי cd באותה פקודה, דורש את האישור שלך גם כאשר כלל allow מכסה אותו. Claude Code בודק יעדי קלט ב v2.1.257 ואילך.

יעדים שאין מאחוריהם קובץ לא נבדקים: /dev/null, צורות של מתאר קובץ כמו 2>&1 ו <&3, ו here-docs ו here-strings.

Claude Code גם בודק את הקבצים שפקודת tee כותבת, כולל בצינור כמו make | tee build.log. הבדיקה מכסה את כללי ה allow וה deny של Edit, נתיבים מוגנים, ואת תיקיות העבודה. כלל allow כמו Bash(tee *) לא מכסה יעד מחוץ לתיקיות העבודה. Claude Code בודק יעדי tee ב v2.1.269 ואילך.

#PowerShell

כללי הרשאה של PowerShell משתמשים באותה צורה כמו כללי Bash, ו PowerShell לבדו או PowerShell(*) מתאים לכל פקודה. התצורה הזו מתירה פקודות Get-ChildItem ו git commit וחוסמת את Remove-Item:

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

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

Claude Code מפרק את ה AST של PowerShell ובודק כל פקודה בפקודה מורכבת בנפרד. אופרטורי צינור |, מפרידי משפטים ;, וב PowerShell 7+ אופרטורי השרשור && ו || מפצלים פקודה מורכבת לתת פקודות. כל תת פקודה חייבת להיות מותרת כדי שהפקודה המורכבת תרוץ בלי בקשת אישור, למשל על ידי התאמה לכלל allow.

#Read ו-Edit

כדי לחסום את כלי הקבצים של Claude מקריאת קובץ או תיקייה, הוסיפו כלל deny של Read לנתיב שלו, כמו Read(./.env) או Read(./secrets/**). בהחרגת קבצים רגישים יש דוגמה מוכנה להדבקה. אם בפרויקט שלכם יש קובץ .claudeignore, אין לו השפעה, לכן העבירו את הרשומות שלו לכללי deny של Read.

#על מה כללי Read ו-Edit מכסים

כללי Edit חלים על כל הכלים המובנים שעורכים קבצים. Claude מנסה כמיטב יכולתו להחיל כללי Read על כל הכלים המובנים שקוראים קבצים, כמו Grep ו-Glob, על אזכורי @file בהנחיות שלכם, ועל הקשר הבחירה והקובץ הפתוח שIDE מחובר משתף עם Claude.

כלל deny של Read(path) חל גם על נתיבי תמונה שאתם מדביקים בהנחיה ועל תיקיות שאתם מזכירים עם @:

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

Claude Code בודק נתיבי תמונה שהודבקו ורשימות תיקיות ב-v2.1.290 ואילך.

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

[!WARNING]

כללי deny של Read ו-Edit חלים על כלי הקבצים המובנים של Claude, על פקודות קבצים ש-Claude Code מזהה ב-Bash, כמו cat, head, tail, sed ו-tee, ועל היעדים של הפניות ב-Bash כמו > file ו-< file. הם לא חלים על פקודה שקוראת קבצים בלי לנקוב בשמם, כמו grep -r pattern . שרצה מהתיקייה שמחזיקה את הקובץ, או על תהליכי משנה שרירותיים שקוראים או כותבים קבצים בעקיפין, כמו סקריפט Python או Node שפותח קבצים בעצמו. לאכיפה ברמת מערכת ההפעלה שחוסמת את כל התהליכים מגישה לנתיב, הפעילו את ה-sandbox.

#כללי Write(path), NotebookEdit(path) ו-Glob(path) אף פעם לא מתאימים

Claude Code בודק הרשאות קבצים רק מול כללי Edit(path) ו-Read(path). אם כותבים כלל נתיב עבור Write, NotebookEdit, Glob או MultiEdit הישן, Claude Code מקבל את הכלל אבל אף פעם לא מתאים קריאה או עריכה מולו.

השתמשו ב-Edit(docs/**) במקום Write(docs/**), NotebookEdit(docs/**) או MultiEdit(docs/**), וב-Read(docs/**) במקום Glob(docs/**). כדי להתאים לכל שימוש בכלי Write, NotebookEdit או Glob בלי קשר לנתיב, כתבו רק את שם הכלי.

#איך תבניות נתיב מתאימות

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

[!WARNING]

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

#איפה תבנית מעוגנת

תבנית /path מעוגנת בתיקייה שמשויכת למקור ההגדרות שמגדיר אותה, ולכן אותו כלל מתאים למיקומים שונים לפי המקום שבו שמתם אותו:

כלל שאתם מוסיפים דרך /permissions עוקב אחרי השורה של קובץ ההגדרות שאליו אתם שומרים אותו.

כללי הגדרות מקומיות מעוגנים בתיקיית העבודה הראשית של הסשן, לא בשורש המאגר שבו Claude Code שומר את הקובץ. בסשן שהתחיל בשורש המאגר, שתי התיקיות זהות. בסשן worktree, כלל משותף כמו Edit(/src/**) מתאים לתיקיית src/ של אותו worktree.

כלל deny כמו Read(/secrets/**) בהגדרות משתמש חוסם את ~/.claude/secrets/**, לא תיקיית secrets בפרויקט שלכם. כדי לכתוב כלל בהגדרות משתמש שחל בתוך כל פרויקט, השתמשו בנתיב מוחלט // או בנתיב יחסי לבית ~/ במקום.

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

דוגמאות:

• Edit(/docs/**): עריכות ב-<primary working directory>/docs/, לא ב-/docs/ ולא ב-<primary working directory>/.claude/docs/
• Read(~/.zshrc): קורא את .zshrc בתיקיית הבית שלכם
• Edit(//tmp/scratch.txt): עורך את הנתיב המוחלט /tmp/scratch.txt
• Read(src/**): ככלל allow, קורא רק מ-<current-directory>/src/. ככלל deny או ask, מתאים לתיקיית src בכל עומק מתחת לתיקייה הנוכחית

#עד איזה עומק תבנית מתאימה

כלל מתאים רק לקבצים מתחת לעוגן שלו. בתוך הגבול הזה, עומק ההתאמה תלוי בצורת התבנית, ולתבניות תיקייה עם מקטע יחיד גם בסוג הכלל, כמתואר בהמשך. שמות קבצים חשופים עוקבים אחרי סמנטיקת gitignore ומתאימים בכל עומק, כך ש-Read(.env) ו-Read(**/.env) שקולים:

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

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

כל צורת תבנית אחרת מתאימה באותו עומק בכל סוג כלל: Edit(/src/**) ו-Edit(src/components/**) מתאימים רק במיקום המעוגן שלהם, ואילו Edit(**/src/**) מתאים בכל עומק.

הדוגמה הבאה מציגה כל צורת תבנית מול פרויקט עם תיקיית src/ ברמה העליונה ועותק מקונן מתחת ל-vendor/:

<current-directory>/
├── src/
│   └── app.ts
└── vendor/
    └── pkg/
        └── src/
            └── lib.js

[!NOTE]

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

#תווים מיוחדים ושלילה ב-!

כשאתם מאשרים נתיב קובץ עם "Yes, and don't ask again", Claude Code מבצע escape לתווי תבנית gitignore בנתיב הזה, כמו [, ] ו-*, כדי שהכלל שנוצר יתאים רק לנתיב המילולי שאישרתם. כללים שאתם כותבים בעצמכם אינם עוברים escape.

אין צורך לבצע escape לסוגריים בנתיב, ולכן Edit(./Finance (2024)/**) מתאים לתיקייה Finance (2024) כפי שהיא כתובה.

כלל deny או ask שהנתיב שלו אינו שמיש כתבנית gitignore עדיין מגן על הנתיב המדויק הזה. כלל allow עם תבנית שאינה שמישה לא מאשר דבר.

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

ההחרגה מגיעה רק לכללים מאותו מקור. Read(!.env) בהגדרות פרויקט או ב---disallowedTools לא מבטל deny של Read(./.env) מהגדרות מנוהלות או מכל קובץ הגדרות אחר.

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

• Claude Code קורא תבנית ! ביחס לתיקייה הנוכחית גם כש-/, ~/ או // באים אחרי ה-!, ולכן התבנית לא יכולה להגיע לכלל שמעוגן עם אחד מהקידומות האלה. Read(!~/notes/public/**) לא מחריג דבר מ-Read(~/notes/**).
• החרגה לא יכולה לפתוח מחדש קובץ בתוך תיקייה שכלל חוסם כמכלול. עם Read(secrets/**) ו-Read(!secrets/public/**), Claude Code עדיין חוסם את secrets/public יחד עם שאר secrets.

#קישורים סימבוליים

כשנתיב קובץ ש-Claude מבקש עובר דרך קישור סימבולי, בדיקת ההרשאה מכסה שני נתיבים: זה ש-Claude ביקש והקובץ שאליו הוא מתפענח. זה חל על קישורים סימבוליים ב-macOS, ב-Linux וב-Windows, ועל צמתי תיקיות ב-Windows.

#איך כללים מתאימים לנתיב מקושר סימבולית

כללי allow ו-deny מתייחסים אחרת לנתיב המבוקש ולקובץ שאליו הוא מתפענח:

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

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

Grep ו-Glob מחפשים בתיקייה שאליה מתפענח ארגומנט path. Claude Code מחיל כללי deny של Read על התיקייה הזו.

#קבצים מצורפים דרך קישור סימבולי

כלל deny של Read מכסה גם את הקבצים המצורפים האלה, ומתאים כל אחד מהם לפי הנתיב הנקוב או לפי הקובץ שאליו הוא מתפענח. Claude Code משמיט קובץ מצורף מהשיחה כשכלל מתאים לו:

• אזכורי @: קובץ או תיקייה שאתם מזכירים בהנחיה. קובץ שנדחה לא משאיר דבר בשיחה, ורשימת התיקייה משמיטה את השמות שכלל מכסה.
• תמונות שהודבקו: תמונה שהנתיב שלה הודבק או נגרר להנחיה בטרמינל
• קבצים שהשתנו: קובץ ש-Claude Code קורא מחדש אחרי שהוא משתנה בדיסק
• הקשר IDE: הקשר הבחירה והקובץ הפתוח ש-IDE מחובר משתף

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

השורה הזו במקום קובץ שציינתם ב-@ אומרת ש-Claude Code לא הצליח לברר לאן הנתיב מוביל, למשל כי הקישורים הסימבוליים שלו יוצרים לולאה:

Referenced <path> (not read: could not be examined)

ל-Claude נאמר לקרוא את הנתיב עם כלי הקבצים שלו במקום, וזה יכול להצליח כש-Claude Code רק נגמר לו הזמן לבדוק את הנתיב.

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

#כתיבה דרך קישור סימבולי

אם הנתיב ש-Claude מבקש לערוך או לכתוב הוא בעצמו קישור סימבולי, כלי Edit ו-Write מסרבים לכתיבה ומפנים את Claude ליעד הקישור.

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

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

#נתיבים שאי אפשר לפענח או שמשתנים

כש-Claude Code לא יכול לקבוע לאן נתיב מוביל בדיסק, למשל כי קישורים סימבוליים עליו יוצרים לולאה, כלי Read, Edit ו-Write מסרבים לפעולה.

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

#נתיבי רשת

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

ב-Claude Code מגרסה v2.1.292 ואילך, כל אחד מאלה משאיר את בקשת האישור במקומה:

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

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

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

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

#WebFetch

כללי WebFetch משתמשים בקידומת domain: ומתאימים לשם המארח של כתובת ה-URL המבוקשת. ההתאמה אינה תלויה באותיות גדולות או קטנות, תומכת בתווי הכללה *, ומסירה . בסוף גם מהכלל וגם משם המארח, כך ש-example.com. ו-example.com נחשבים אותו דבר.

• WebFetch(domain:example.com) מתאים לבקשות אל example.com בלבד. כדי לכסות גם תת-דומיינים כמו api.example.com, הוסיפו כלל WebFetch(domain:*.example.com)
• WebFetch(domain:*.example.com) מתאים לכל תת-דומיין בכל עומק, כמו api.example.com או a.b.example.com, אבל לא ל-example.com עצמו
• WebFetch(domain:*) מתאים לכל דומיין. הוא אינו זהה לכלל WebFetch חשוף. ראו לאפשר או לחסום כל fetch

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

תווי הכללה בכללי WebFetch דורשים את Claude Code בגרסה v2.1.172 או מאוחרת יותר כדי להתאים ל-fetch.

#לאפשר או לחסום כל fetch

כלל WebFetch חשוף הוא שם הכלי בלי חלק domain:, כמו "deny": ["WebFetch"]. גם הוא וגם WebFetch(domain:*) מכסים כל כתובת URL, אבל Claude Code מחיל אותם בצורה שונה, ורק הצורה עם domain: מוסיפה גם את הדומיין שלה ל-רשימת הדומיינים המותרים או החסומים של ארגז החול. הסעיף הזה מפרט את צורות תו ההכללה שארגז החול מכבד ואת הגרסה שהוסיפה * חשוף.

כל שורה מראה מה הכלל עושה ברשימת allow וברשימת deny:

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

כשכלל חוסם קריאה, הסירוב מציין את שם הכלל. לפני v2.1.268, כלל deny של WebFetch חשוף חסם כל קריאת artifact, וכלל ask חשוף ביקש אישור לפני כל אחת.

כדי לאפשר ל-Claude לבצע fetch בחופשיות ולהשאיר את רשימת ההיתר של ארגז החול כפי שהיא, השתמשו בצורה החשופה. ה-settings.json הזה עושה זאת:

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

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

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

#MCP

כדי להתאים לכל כלי משרת MCP, כתבו mcp__<server>__*. כדי להתאים לכלי אחד, כתבו את שמו המלא, mcp__<server>__<tool>.

• mcp__puppeteer מתאים לכל כלי שהשרת puppeteer מספק
• mcp__puppeteer__* משתמש בתחביר תו הכללה וגם מתאים לכל הכלים משרת puppeteer
• mcp__puppeteer__puppeteer_navigate מתאים לכלי puppeteer_navigate שהשרת puppeteer מספק

עבור <server>, כתבו את שם השרת כפי שהוא מופיע בשמות הכלים של השרת הזה. הדוגמאות האלה מראות איזה כלל לכתוב עבור שם עם תווים מיוחדים, שרת מתוסף, ושם שמכיל __ או מסתיים ב-_:

• שמות עם תווים כמו . או רווחים: התווים האלה הופכים ל-_, כך שעבור שרת שהגדרתם כ-my.server, כתבו mcp__my_server__*

• שרתים שתוסף מספק: <server> מקבל את הצורה בטווח התוסף, כך שעבור שרת database-tools בתוסף בשם my-plugin, כתבו mcp__plugin_my-plugin_database-tools__*

• <server> שמכיל __ או מסתיים ב-_: כתבו את צורת תו ההכללה, mcp__<server>__*, עם השם כולו. עבור שרת בשם reports__v2, כתבו mcp__reports__v2__*. הצורה החשופה mcp__reports__v2 והקצרה יותר mcp__reports אינן מתאימות לכלים שלו ככללי allow, כי Claude Code קורא את שתיהן ככללים עבור שרת בשם reports.

  ככלל deny או ask, לעומת זאת, כל אחד משני השמות האלה מכסה גם כל כלי של שרת reports__v2. כדי לכסות שרת בשם reports בלבד, כתבו כלל אחד לכל כלי בצורה mcp__reports__<tool>, או שנו את השם של אחד השרתים.

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

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

#Agent (subagents)

השתמשו בכללים Agent(AgentName) כדי לשלוט באילו תת-סוכנים Claude יכול להשתמש:

• Agent(Explore) מתאים לתת-הסוכן Explore
• Agent(Plan) מתאים לתת-הסוכן Plan
• Agent(my-custom-agent) מתאים לתת-סוכן מותאם אישית בשם my-custom-agent

הוסיפו את הכללים האלה למערך deny בהגדרות שלכם או השתמשו בדגל ה-CLI --disallowedTools כדי להשבית סוכנים מסוימים. כדי להשבית את סוכן Explore:

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

#Cd

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

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

הוספת כלל allow כלשהו של Cd מעבירה את /cd למצב רשימת היתר: תיקיית היעד שנפתרה חייבת להתאים לאחד מכללי ה-allow שלכם, אחרת /cd מסרב. בלי כללי Cd מוגדרים, /cd שומר על התנהגות ברירת המחדל שלו ומבקש מכם לאשר תיקייה לא מוכרת.

תבניות נתיב חולקות את העוגנים //, ~/ ו-/ מכללי Read ו-Edit, אבל ההתאמה מעוגנת לנתיב התיקייה כולו ולא בסגנון gitignore. * מתאים בדיוק למקטע נתיב אחד ו-** מתאים על פני מקטעים. /** בסוף מתאים גם לשורש ששמו מצוין.

#הרחבת הרשאות עם hooks

hooks של Claude Code מאפשרים לרשום פקודות מעטפת מותאמות אישית שמעריכות הרשאות בזמן ריצה. כש-Claude Code מבצע קריאת כלי, hooks מסוג PreToolUse רצים לפני בקשת ההרשאה, עבור כל כלי מלבד EndConversation. פלט ה-hook יכול לסרב לקריאת הכלי, לכפות בקשת אישור, או לדלג על בקשת האישור כדי לאפשר לקריאה להמשיך.

#קדימות בין כללים, hooks ו-mods

החלטות של hook מסוג PreToolUse אינן עוקפות כללי הרשאה. Claude Code מעריך כללי deny ו-ask בלי קשר למה ש-hook מסוג PreToolUse מחזיר: כלל deny תואם חוסם את הקריאה, וכלל ask תואם עדיין מבקש אישור גם כשה-hook החזיר "allow" או "ask". זה שומר על קדימות deny-first שמתוארת ב-ניהול הרשאות, כולל כללי deny שהוגדרו בהגדרות מנוהלות.

הקדימות הזו מכסה hooks בקובצי הגדרות וב-hooks/hooks.json של תוסף. mod שאתם מתקינים ומטפל באירוע tool.check נותן את התשובה שלו אחרי ש-hooks מסוג PreToolUse רצו. עם הגדרות מנוהלות על המחשב, או /login של Team או Enterprise כאישור של הסשן, התוצאות האלה נשארות במקום כברירת מחדל כשה-mod מאשר קריאה:

• קריאה שכלל deny מסרב לה נשארת מסורבת, והארגון שלכם יכול לשנות זאת.
• קריאה שכלל ask היה מבקש עליה אישור עדיין מבקשת מכם אישור.
• קריאה ש-hook מסוג PreToolUse או permissions.blockReadsOutsideWorkingDirectories היה מבקש עליה אישור עדיין מבקשת מכם אישור.
• קריאה ש-hook מסוג PreToolUse חסם נשארת חסומה, מכל קובץ הגדרות שה-hook מגיע.
• קריאה ש---permission-prompt-tool שלכם או callback של canUseTool ב-Agent SDK היה נשאל עליה עדיין מועברת לכלי או ל-callback הזה.

בלי הגדרות מנוהלות ובלי /login של Team או Enterprise כאישור של הסשן, ה-mod יכול לאשר קריאה שכלל deny מסרב לה או ש-hook מסוג PreToolUse חסם. סשן שרץ על מפתח API או על CLAUDE_CODE_OAUTH_TOKEN ארוך טווח במקום זאת אינו משתמש ב-login הזה, גם כשה-login הזה שמור.

בהגדרה הזו אינכם מקבלים בקשת אישור כשה-mod מאשר קריאה שכלל ask, hook מסוג PreToolUse, או permissions.blockReadsOutsideWorkingDirectories היה מבקש עליה אישור. גם --permission-prompt-tool או callback של canUseTool שלכם אינם נשאלים על קריאה שה-mod מאשר. מצב auto, מצב plan ומצב dontAsk כל אחד מוסיף תוצאה משלו בכל הגדרה:

• מצב auto: קריאה שה-mod מאשר רצה בלי בדיקת מסווג, חוץ ממקום שבו ה-mod אינו יכול לעקוף את כלי בקשת ההרשאה שלכם או את callback ההרשאה של Agent SDK. שם המסווג בודק את הקריאה קודם.
• מצב plan: ה-mod אינו יכול לאשר קריאה שאינה לקריאה בלבד, כמו עריכת קובץ או פקודת מעטפת שכותבת.
• מצב dontAsk: ה-mod יכול לאשר קריאה שרק המצב היה מסרב לה.

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

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

hook חוסם גם מקבל קדימות על כללי allow. hook שיוצא עם קוד 2 עוצר את קריאת הכלי לפני שכללי ההרשאה מוערכים, כך שהחסימה חלה גם כשכלל allow היה מאפשר לקריאה להמשיך אחרת. כדי להריץ את כל פקודות Bash בלי בקשות אישור חוץ מכמה שאתם רוצים לחסום, הוסיפו "Bash" לרשימת ה-allow שלכם ורשמו hook מסוג PreToolUse שדוחה את הפקודות הספציפיות האלה. ראו חסימת עריכות לקבצים מוגנים עבור סקריפט hook שאפשר להתאים.

#אישורי hook במצב plan

במצב plan, מלבד ExitPlanMode, ל-"allow" של ה-hook מסוג PreToolUse שלכם אין השפעה על עריכת קובץ או על קריאה אחרת שאינה לקריאה בלבד. אתם מקבלים אותה בקשת אישור, חסימה או אישור שהקריאה הייתה מקבלת בלי hook, ו-Claude Code עדיין מחיל כל updatedInput שה-hook מחזיר. אם ה-hook עונה ל-ExitPlanMode עם "allow" ו-updatedInput, הכלי הזה עדיין רץ בלי בקשת אישור.

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

#ספריות עבודה

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

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

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

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

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

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

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

• permissions.blockReadsOutsideWorkingDirectories: כלי הקבצים מסרבים לקריאות שם, מלבד קבצים שקלוד קוד עצמו צריך. במצב אוטומטי, קלוד קוד מציע להפעיל את זה בפעם הראשונה שקלוד קורא מחוץ לספריות העבודה.
• permissions.blockWritesOutsideWorkingDirectories: הכלים Write, Edit ו-NotebookEdit מסרבים לכתיבה שם, מלבד חלק מהקבצים של קלוד קוד עצמו, כמו קבצי plan. המפתח לא מגביל פקודות מעטפת, כלי MCP או התוכניות שה-hooks מריצים, לכן השתמשו בארגז חול כדי להגביל לאן פקודות מעטפת כותבות. נדרש Claude Code מגרסה v2.1.314 ואילך.

כדי שספרייה חיצונית אחת תישאר נגישה כשאחד מהמפתחות הוא true, הוסיפו אותה כספריית עבודה.

#העברת הסשן לתיקייה אחרת

כדי להעביר את הסשן לספריית עבודה ראשית אחרת, במקום להוסיף ספרייה לצד הנוכחית, הריצו /cd <path>. קלוד קוד שומר את השיחה, טוען את CLAUDE.md של התיקייה החדשה, ומבקש מכם לתת אמון בסביבת העבודה אם לא עבדתם בה קודם. אחר כך, קלוד קוד מוצא את הסשן שהועבר כשמריצים --resume מהתיקייה החדשה.

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

• הגדרות הפרויקט שלו, כולל כללי ההרשאות ו-hooks
• שרתי .mcp.json שלו, בכפוף לאותו אישור שרת כמו בהפעלה, ושרתי MCP בהיקף מקומי שרשמתם בו
• התוספים שההגדרות שלו מפעילות, המיומנויות שלו, והסוכני המשנה שלו
• ערכי env שלו, שמוחלים מעל משתני הסביבה מההגדרות של התיקייה הקודמת, שנשארים בתוקף

קלוד קוד גם מנתק את שרתי ה-MCP של הפרויקט ושל ההיקף המקומי של התיקייה הקודמת, ואת השרתים של תוספים שכבר לא מופעלים אחרי ההעברה. הוא לוקח ספריות נוספות מההגדרות של התיקייה החדשה במקום מאלה של הקודמת, ושומר את הספריות שהוספתם עם --add-dir או /add-dir. Hooks שההעברה מפעילה עדיין מקבלים את ${CLAUDE_PROJECT_DIR} כשהוא מוגדר לשורש הפרויקט שבו הסשן התחיל.

כשהתיקייה החדשה עדיין לא מהימנה, קלוד קוד מציג בבקשת האמון את כללי ה-allow, הספריות הנוספות, ה-hooks ופקודות העזר שההגדרות של התיקייה היו מפעילות, כדי שאפשר יהיה לעיין בהן לפני האישור. אם דוחים, הסשן נשאר במקומו. לפני v2.1.246, /cd לא החיל את ההגדרות, ה-hooks, שרתי ה-MCP או המיומנויות של התיקייה החדשה עד שחידשתם את הסשן, ובקשת האמון שלו לא פירטה מה ההגדרות של התיקייה היו מפעילות.

הגבילו או השביתו יעדי /cd עם כללי הרשאה Cd.

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

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

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

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

סוגי ההגדרות הבאים נטענים מספריות --add-dir:

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

#מאיפה נטענים סגנונות פלט, hooks והגדרות מקומיות

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

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

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

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

#איך הרשאות פועלות יחד עם ארגז חול

הרשאות וארגז חול הן שכבות אבטחה משלימות:

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

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

כשמפעילים ארגז חול ומשאירים את autoAllowBashIfSandboxed בברירת המחדל true, פקודות Bash בתוך ארגז החול רצות בלי בקשה גם אם ההרשאות כוללות כלל ask של Bash בלבד, או הצורה המקבילה Bash(*): גבול ארגז החול מחליף את הבקשה לכל הכלי.

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

הבדיקות האלה עדיין חלות:

• כללי ask מוגבלי תוכן כמו Bash(git push *) עדיין כופים בקשה
• גם פקודות אחרות בתוך ארגז חול יכולות לעבור בזרימת ההרשאות הרגילה, כפי שמצב Auto-allow מתאר

פקודות שלא ירוצו בתוך ארגז חול, כמו פקודות שהוחרגו, מכבדות את כלל ה-ask של Bash בלבד כרגיל. ראו מצבי ארגז חול כדי לשנות את ההתנהגות הזו.

#הגדרות מנוהלות

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

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

disableBypassPermissionsMode בדרך כלל ממוקם בהגדרות מנוהלות כדי לאכוף מדיניות ארגונית, אבל הוא פועל מכל היקף. משתמש יכול להגדיר אותו בהגדרות שלו כדי לנעול את עצמו מחוץ למצב bypass.

#סדר עדיפויות של הגדרות

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

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

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

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

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

#כללי allow של הפרויקט ואמון בסביבת העבודה

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

Claude Code משייך ושומר את האמון שקיבלתם לפי המקום שממנו מפעילים אותו:

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

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

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

#מתי קובץ ההגדרות המקומי דורש אמון

.claude/settings.local.json הוא בדרך כלל קובץ שלכם, ולכן Claude Code מחיל את כללי ה-allow ואת התיקיות הנוספות שלו בלי שלב האמון. כשהקובץ נמצא במעקב של git, או ש-.claude הוא symlink, Claude Code מתייחס אליו כאל קובץ שסופק על ידי המאגר ומחזיק את הכללים שלו עד שמאמינים לתיקייה.

Claude Code מריץ git כדי להבחין בין השניים, והוא מריץ git רק אחרי שכבר נתתם אמון לתיקייה: קיבלתם את תיבת הדו-שיח של האמון עבורה או עבור תיקיית הורה שהאמון שלה חל עליה, או שאתם בסשן -p או SDK, וזה נחשב כקבלה. עד אז, המקום שממנו הפעלתם את Claude Code קובע מה קורה לכללים של הקובץ:

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

[!NOTE]

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

#מה רץ לפני שמאמינים לתיקייה

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

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

לפני שמריצים claude -p במאגר שלא כתבתם, החליטו מה מותר לו להריץ על המכונה שלכם:

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

#תצורות לדוגמה

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

#ראו גם

• כל ההגדרות: כל מפתח הגדרות, כולל מפתחות ההרשאות
• הגדרת מצב אוטומטי: אמרו למסווג של המצב האוטומטי באיזו תשתית הארגון שלכם נותן אמון
• Sandboxing: בידוד של מערכת קבצים ורשת ברמת מערכת ההפעלה לפקודות Bash
• אימות: הגדרת גישת משתמש ל-Claude Code
• אבטחה: אמצעי הגנה של אבטחה ושיטות עבודה מומלצות
• Hooks: אוטומציה של תהליכי עבודה והרחבת הערכת הרשאות