מדריך קלוד קוד בעברית

פרק 7

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

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

בתוכניות Pro, Max ו-Team, מצב הפתיחה המובנה הוא מצב auto. באפשרותך לשנות את מצב ההרשאה של סשן פעיל בכל עת.

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

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

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

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

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

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

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

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

מצבמה רץ בלי לשאולמתי להשתמש
defaultקריאות בלבדסקירת כל פעולה בעצמך, עבודה רגישה
acceptEditsקריאות, עריכות קבצים ופקודות מערכת קבצים נפוצות (mkdir, touch, mv, cp, rm, rmdir, sed) עבור נתיבים בספריית העבודה או ב-additionalDirectoriesפיתוח שוטף ובדיקת שינויים לאחר מעשה
planקריאות, ובנוסף פקודות מעטפת שהמסווג אישר כאשר מצב auto זמין. קלוד קורא קבצים ומריץ פקודות מעטפת לקריאה בלבד לחקר בסיס הקוד, ללא עריכת קבציםחקר בסיס קוד לפני ביצוע שינויים
autoהכל, עם בדיקות בטיחות ברקע שמוודאות שהפעולות תואמות לבקשה שלךמשימות ארוכות, הפחתת עייפות מבקשות אישור
dontAskקריאות קבצים בספריות העבודה ופעולות שאינן דורשות אישור רצות כרגיל, לצד כלים שאושרו מראש דרך /permissions או כללי permissions.allow. כל פעולה אחרת שדורשת אישור נדחית אוטומטית. AskUserQuestion, כלי MCP עם requiresUserInteraction, וכלי מחברים שהארגון קבע ל-ask נדחים גם אם אישרת אותםסביבות CI וסקריפטים נעולים
bypassPermissionsהכל, מדלג על בקשות אישור ובדיקות בטיחות (למעט פעולות שאף מצב אינו מאשר אוטומטית)מכולות ומכונות וירטואליות מבודדות בלבד

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

כדי למנוע שימוש במצבים אלה לחלוטין בארגון, ניתן לקבוע בקובץ הגדרות את permissions.disableBypassPermissionsMode או את permissions.disableAutoMode לערך "disable". הגדרות אלו יעילות במיוחד בהגדרות מנוהלות (managed settings), שם לא ניתן לדרוס אותן.


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

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

סוג כלידוגמהאישור במצב Manualהתנהגות "Yes, and don't ask again"
קריאה בלבד (Read-only)קריאת קבצים, Grepלא, בתוך ספריית העבודה ו-additionalDirectoriesלא רלוונטי
פקודות Bashהרצת מעטפתכן, חוץ מערכת פקודות קריאה מובניתקבוע לכל מאגר ולכל פקודה
שינוי קבציםEdit או Writeכןעד סוף הסשן בלבד
WebFetchשליפה מהרשתכן, חוץ מדומייני תיעוד שאושרו מראשקבוע לכל מאגר ולכל דומיין
WebSearchחיפוש ברשתכןקבוע לכל מאגר

כשבוחרים אישור קבוע לפקודת Bash או לדומיין של WebFetch, הכלל נשמר ככלל allow בקובץ .claude/settings.local.json בשורש מאגר ה-git, אחרי פתרון worktrees אל ה-checkout הראשי. הכלל חל על סשנים עתידיים בכל המאגר, כולל סשן מתת תיקייה או מ-worktree. לפני גרסה v2.1.211 הכלל נשמר בתיקיית ההפעלה. אישור שניתן אז ב-worktree או בתת תיקייה ממשיך לחול רק על סשנים שנפתחים משם.

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

כללי ה-allow בקובץ המקומי נכנסים לתוקף ללא שלב האמון במרחב העבודה (Workspace Trust) כל עוד הקובץ אינו במעקב git. אם הקובץ נמצא במעקב git, שלב האמון חל עליו בדיוק כמו על הקובץ המשותף.

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

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

לאחר מעבר ספריות באמצעות פקודת /cd, קלוד קוד קורא את שני קובצי הפרויקט מהספרייה החדשה לפי אותם כללים (דורש גרסה v2.1.246 ומעלה).

לפעמים מוצג רק אישור חד פעמי, בלי "don't ask again" ובלי אישור לשאר הסשן. האפשרויות האלה מופיעות רק כשהבקשה יכולה להראות במלואן מה הכלל יכסה. הן נעלמות בשלושה מקרים:

  1. הפקודה או העריכה גדולות מדי מכדי להציגן במלואן.
  2. התווית אינה יכולה להכיל את כל הפקודות או הנתיבים שהכלל יכסה.
  3. ספריית הפתיחה ארוכה מדי ולא קוצרה, למשל כשהיא מכילה תווים שאי אפשר להציג בבטחה או שאפילו תחילת הנתיב אינה נכנסת בתווית. אם הנתיב רק ארוך, קלוד קוד מקצר בתווית (~ ו-) ומשאיר את האפשרות. אותו כלל נשמר.

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

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

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

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

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

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

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


#תצורות נפוצות

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

מה המטרהנקודת פתיחהרמת בידוד נדרשתהערות
סקירת כל פעולה בעצמךמצב Manual: claude --permission-mode defaultללאעבודה רגישה, קוד לא מוכר
פיתוח מקומי מהיר עם פחות שאלות, ללא מסווגמצב Manual בשילוב Bash sandbox במצב auto-allow: מפעילים claude --permission-mode default, מריצים /sandbox ובוחרים auto-allowה-Bash sandbox המובנה, ב-macOS, Linux ו-WSL2כללי deny עדיין חלים, וכללי ask שמציינים פקודה ספציפית כמו Bash(git push *) עדיין שואלים. להפעלת ה-sandbox מקובץ הגדרות, קבע את sandbox.enabled ל-true
חקר המאגר לפני ביצוע שינוייםclaude --permission-mode planללאקלוד קוד חוסם עריכות עד לאישור תוכנית
עבודה עצמאית במצב autoclaude --permission-mode auto, מצב הפתיחה המובנה בתוכניות Pro, Max ו-Teamללא, אך sandbox או מכולה מוסיפים הגנה לעומקדורש דגם נתמך, והארגון יכול לכבות את המצב
הרצה ב-CI עם רשימת היתרים מדויקתclaude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"ללא, מעבר למה ששרת ה-CI מספקסשנים בענן (Cloud sessions) מתעלמים מ-dontAsk מקובצי הגדרות
הרצה אוטונומית מלאה ללא השגחה בתוך מכולהclaude -p "<prompt>" --dangerously-skip-permissionsחובה: מכולה, מכונה וירטואלית או סביבת sandbox runtime. בלינוקס וב-macOS חובה להריץ כמשתמש שאינו rootסשנים בענן מתעלמים ממצב זה מקובצי הגדרות. בהרצת -p זו, הקריאות הבודדות שעדיין דורשות אישור יידחו במקום זאת

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


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

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

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

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

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

אופן הרצת קלוד קודמצב פתיחה מובנה
קובץ הגדרות כלשהו מגדיר את disableAutoMode ל-"disable"default
משיכת feature flags כבויהdefault
סשן ראשון לאחר התקנה או שדרוג לגרסה שכוללת ברירת מחדל זו, אלא אם לאחר התקנה נקייה הדגלים נמשכו בזמןdefault
הרצה עם claude -p או ב-Agent SDKdefault
סשן ב-Amazon Bedrock, Google Cloud Agent Platform, Microsoft Foundry, Claude Platform on AWS, או סשן מחובר ב-Claude apps gatewaydefault
תוכנית Pro, Max או Team, בטרמינל או דרך הרחבת VS Codeauto
תוכנית Enterprise או מפתח API מ-Claude Consoledefault

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

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

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

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

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

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

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

כדי להגדיר מצב פתיחה עבורבצע זאת
סשן יחיד שעומד להתחילהעבר את המצב בדגל, למשל claude --permission-mode default
כל סשן טרמינל במכונה זוהגדר permissions.defaultMode בקובץ ~/.claude/settings.json
כל סשן טרמינל בפרויקט מסויםהגדר permissions.defaultMode בקובץ .claude/settings.json של הפרויקט. סשנים בטרמינל מכבדים כל ערך חוץ מ-auto ו-bypassPermissions. סשנים בהרחבת VS Code אינם קוראים הגדרות פרויקט לקביעת מצב הפתיחה
כל סשן טרמינל בארגוןהגדר permissions.defaultMode בהגדרות מנוהלות (managed settings). סשנים בטרמינל ייפתחו במצב זה והמשתמשים יוכלו עדיין לעבור ל-auto. כדי לבטל את מצב auto כך שאיש לא יוכל לבחור בו, הגדר permissions.disableAutoMode ל-"disable" במקום זאת

דוגמה לקביעת מצב Manual (default) כברירת מחדל לכל סשן טרמינל במכונה שלך, בקובץ ~/.claude/settings.json:

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

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


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

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

#CLI

  • בזמן סשן: הקשה על Shift+Tab מעבירה בין המצבים. מ-auto, הלחיצה הראשונה עוברת ל-default, והמחזור ממשיך מ-default אל acceptEdits, משם אל plan, ובחזרה ל-default. מצבים אופציונליים משתלבים אחרי plan: מצב bypassPermissions מופיע ראשון ומצב auto מופיע אחרון. אם שניהם מופעלים, עוברים דרך bypassPermissions בדרך ל-auto. מצב dontAsk לעולם אינו מופיע במחזור. שורת המצב מציגה: ⏸ 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-dangerously-skip-permissions מוסיף את המצב למחזור בלי להפעיל אותו מיד.
  • מתוך בקשת אישור של פקודת Bash: במצבי Manual ו-acceptEdits, כאשר מצב auto זמין, קלוד קוד מוסיף לבקשת אישור של פקודת Bash את האפשרות Yes, and switch to auto mode (דורש גרסה v2.1.247 ומעלה). בחירה בה מאשרת את הפקודה ומעבירה את הסשן למצב auto. אפשרות זו אינה מופיעה בבקשות של כלי PowerShell, ואינה מופיעה בבקשות שנכפו על ידי כלל ask מפורש או על ידי hook.
  • בפתיחת סשן: מעבירים את המצב כדגל:
    claude --permission-mode plan
    אותו דגל עובד גם עם -p להרצות שאינן אינטראקטיביות.

#VS Code

  • בזמן סשן: לחיצה על מחוון המצב בתחתית תיבת הפרומפט. התוויות הן:
תווית בממשקמצב
Manualdefault
Edit automaticallyacceptEdits
Planplan
Autoauto
Bypass permissionsbypassPermissions
  • כברירת מחדל: כדי לקבע את מצב הפתיחה של שיחות חדשות, הגדר את claudeCode.initialPermissionMode בהגדרות המשתמש ב-VS Code לערכים: default, manual, acceptEdits, plan, או bypassPermissions. ההגדרה אינה מקבלת את הערך auto. כדי להתחיל במצב Auto, השאר את ההגדרה ריקה ובחר פעם אחת Auto ממחוון המצב. ההרחבה פותחת כל שיחה חדשה לפי הפריט הראשון שחל מבין הבאים:
    1. ההגדרה claudeCode.initialPermissionMode
    2. המצב האחרון שנבחר ממחוון המצב, אם היה Manual, Edit automatically או Auto. בחירה ב-Plan או ב-Bypass permissions חלה על אותה שיחה בלבד
    3. permissions.defaultMode מהגדרות מנוהלות או מ-~/.claude/settings.json, בתוכניות Pro, Max ו-Team כאשר משיכת feature flags זמינה
    4. ברירת המחדל המובנית עבור התוכנית, הספק והגדרות הארגון שלך

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

מצב Auto מופיע במחוון כאשר מצב auto זמין.

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

#JetBrains

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

#אפליקציית Desktop

  • בזמן סשן: בלשונית Code, משתמשים בבורר המצבים לצד כפתור השליחה. לא כל המצבים מופיעים בבורר:
    • Auto: מופיע כאשר מצב auto זמין.
    • Bypass permissions: דורש הפעלה של המתג Allow bypass permissions mode בהגדרות האפליקציה בתוכניות Pro ו-Max. בתוכניות Team ו-Enterprise, מדיניות הארגון קובעת זאת. לשונית Cowork אינה משתמשת במצבים אלה ויש לה מצבי הרשאה משלה.
  • כברירת מחדל: הגדרת defaultMode בהגדרות. האפליקציה קוראת את אותם קובצי הגדרות כמו ה-CLI ומחילה את המצב על סשנים מקומיים חדשים. מצב שנבחר בבורר המצבים נשמר לפי תיקייה וגובר על defaultMode באותה תיקייה, למעט Plan שתקף לסשן הנוכחי בלבד.

#Web ומובייל

משתמשים בתפריט הנפתח לצד תיבת הפרומפט ב-claude.ai/code או באפליקציית המובייל. בקשות אישור מופיעות ב-claude.ai לאישורך. המצבים הזמינים תלויים במקום שבו הסשן רץ:

  • סשנים בענן (Cloud sessions): מציגים Accept edits, Plan ו-Auto. המצב Accept edits מקביל למצב default, כיוון שסשנים בענן מאשרים עריכות קבצים מראש בכל מצב. סשנים בענן מכבדים defaultMode: "acceptEdits" מהגדרות. מצב Auto מופיע רק כאשר הארגון מתיר זאת והדגם תומך בכך. מצב Bypass permissions אינו זמין בענן.
  • סשני שליטה מרחוק (Remote Control) במכונה המקומית: מציגים Manual, Accept edits ו-Plan. לא ניתן לבחור Auto או Bypass permissions מהאפליקציה. התפריט מציג את המצב שבו הסשן המקומי נמצא ומתעדכן בזמן אמת (למעט Bypass permissions שאינו מדווח ל-claude.ai). סשנים שמנוהלים על ידי אפליקציית Desktop או הרחבת VS Code מדווחים על שינויי מצב ל-claude.ai בזמן אמת. סשני Remote Control דורשים שהמכונה המקומית תהיה מחוברת לחשבון claude.ai שלך (מפתחות API אינם נתמכים). ניתן לקבוע את מצב הפתיחה בעת הפעלת הסשן המקומי:
claude remote-control --permission-mode acceptEdits

#עריכות אוטומטיות של קבצים במצב acceptEdits

מצב acceptEdits מאפשר לקלוד ליצור ולערוך קבצים בספריית העבודה שלך בלי לבקש אישור. שורת המצב מציגה ⏵⏵ accept edits on כאשר מצב זה פעיל.

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

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

השתמש ב-acceptEdits כאשר אתה מעדיף לסקור שינויים בעורך שלך או דרך git diff לאחר מעשה במקום לאשר כל עריכה בנפרד.

מעבר למצב זה מתבצע בלחיצה אחת על Shift+Tab ממצב Manual, או בהפעלה ישירה:

claude --permission-mode acceptEdits

#ניתוח ומחקר לפני עריכה במצב plan

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

כאשר מצב auto זמין וההגדרה useAutoModeDuringPlan מופעלת (מופעלת כברירת מחדל), המסווג בודק פקודות מעטפת בזמן תכנון במקום לשאול אותך. פקודות שאושרו רצות, ופקודות שנדחו נחסמות. אחרת, פקודות שאינן שייכות לערכת הקריאה המובנית דורשות אישור, כולל כאשר מופעל מצב auto-allow של ה-sandbox. בסשני טרמינל אינטראקטיביים שבהם הרשאות bypass זמינות, לא מופעל מסווג ולא מוצגת בקשת אישור לפקודות תכנון. מגרסה v2.1.212 עד v2.1.217, סשנים ללא הרשאות bypass הציגו בקשת אישור לכל פקודה מחוץ לערכת הקריאה, ללא קשר לזמינות מצב auto.

נכנסים למצב plan בהקשת Shift+Tab או בהוספת הקידומת /plan לפרומפט בודד. ניתן גם לפתוח סשן במצב זה מה-CLI:

claude --permission-mode plan

הקשה נוספת על Shift+Tab יוצאת ממצב plan בלי לאשר תוכנית.

#בדיקה ואישור של תוכנית

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

  • Yes, and use auto mode: אישור התוכנית ותחילת עבודה במצב auto. כאשר מצב 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, או מקדימים /plan לפרומפט הבא.

הקשה על Ctrl+G פותחת את התוכנית המוצעת בעורך הטקסט המוגדר כברירת מחדל במערכת, ומאפשרת לערוך אותה ישירות לפני שקלוד ממשיך. כאשר ההגדרה showClearContextOnPlanAccept מופעלת, התפריט כולל אפשרות ראשונה שמאשרת את התוכנית ומנקה את הקשר התכנון (planning context).

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

#הגדרת מצב plan כברירת מחדל

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


#ביטול בקשות אישור שגרתיות במצב auto

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

בתוכניות Pro, Max ו-Team, מצב auto הוא מצב הפתיחה המובנה.

המסווג בודק גם כל הודעה שקלוד שולח לסוכן אחר באמצעות SendMessage, בין אם מדובר בטקסט רגיל ובין אם בהודעה מובנית של צוות סוכנים (agent team), לפני שקלוד קוד מוסר אותה. בדיקה זו מתבצעת הן במצב auto והן במצב plan כאשר המסווג בודק פקודות (דורש גרסה v2.1.222 ומעלה).

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

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

[!WARNING] מצב auto מפחית בקשות אישור אך אינו מבטיח בטיחות מוחלטת. השתמש בו למשימות שבהן אתה סומך על הכיוון הכללי, ולא כתחליף לבדיקה ידנית בפעולות רגישות.

מצב auto זמין רק כאשר החשבון שלך עומד בכל הדרישות הבאות:

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

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

הודעה נפרדת המציינת שם דגם ואומרת שמצב auto אינו יכול לקבוע את בטיחות הפעולה ("cannot determine the safety"), מעידה על כשל בבקשת המסווג. כשל זה הוא לרוב זמני, אך ב-Amazon Bedrock הוא עלול לחזור עד שלחשבונך תהיה הרשאה להפעיל את הדגם המצוין.

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

#מצב auto ב-Bedrock, ב-Agent Platform או ב-Foundry

בספקים אלה, מצב auto מופיע במחזור Shift+Tab כברירת מחדל. הופעתו במחזור אינה משנה את מצב הפתיחה של סשן חדש: סשנים בטרמינל נפתחים ב-defaultMode שלך (Manual אלא אם שינית זאת), ושיחות בהרחבת VS Code נפתחות ב-Manual אלא אם הוגדר מצב אחר בהרחבה. רק Claude Sonnet 5, Opus 4.7 ומעלה ודגמי Fable נתמכים בספקים אלה.

כדי להפוך את מצב auto למצב הפתיחה כברירת מחדל בספקים אלה, הגדר "permissions": {"defaultMode": "auto"} בהגדרות משתמש או בהגדרות מנוהלות.

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

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

בתוכניות Enterprise ובחשבונות המשתמשים ב-Claude API, ב-Claude Platform on AWS, Amazon Bedrock, Google Cloud Agent Platform ו-Microsoft Foundry, ובכל פעם שמשתנה הסביבה ANTHROPIC_BASE_URL מצביע אל שער (gateway) או פרוקסי של LLM, קלוד קוד במצב auto מבקש מהשרת לבדוק את פעולות המסווג כחלק מבקשות המודל של הסשן (דורש גרסה v2.1.278 ומעלה).

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

#מה המסווג חוסם כברירת מחדל

המסווג נותן אמון בספריית העבודה שלך ובמאגרים המרוחקים (remotes) שהוגדרו עבורה בעת פתיחת הסשן. מאגר מרוחק שנוסף או עודכן בזמן הסשן באמצעות git remote add או git remote set-url אינו נחשב מהימן, וכל גורם אחר נחשב חיצוני עד להגדרת תשתית מהימנה.

פעולות שנחסמות כברירת מחדל:

  • הורדה והרצה של קוד, כגון curl | bash.
  • שליחת מידע רגיש לנקודות קצה חיצוניות.
  • פריסות ייצור (production deploys) ומיגרציות של מסדי נתונים.
  • מחיקה המונית באחסון ענן.
  • הענקת הרשאות IAM או הרשאות מאגר.
  • שינוי תשתיות משותפות.
  • השמדה בלתי הפיכה של קבצים שהיו קיימים לפני תחילת הסשן.
  • דחיפה בכוח (git push --force).
  • ביצוע commit או push של שינוי שיגרום לשליחת סודות או נתונים רגישים מחוץ למאגר בזמן ריצה, או שירחיב את המידע שפריסה חושפת. זה כולל הגדרות CI או פריסה שמעבירות סוד ליעד שאינו מקבל אותו כיום, סקריפט שקורא ממאגר סודות ושולח החוצה, או שינוי הגדרות שמרחיב חשיפה ב-registry, visibility, artifacts או sourcemap. הבדיקה חלה על כל ענף וגם במאגר ציבורי.
  • פקודות ביטול שינויים: git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, או git stash clear, שהמסווג מניח שימחקו עבודה שטרם נשמרה.
  • ביצוע git commit --amend כאשר ה-commit בראש (HEAD) נוצר לפני הסשן הנוכחי, או (מגרסה v2.1.198) כאשר הוא כבר נדחף למאגר המרוחק. שינוי מלל בלבד (--amend -m) ללא קבצים חדשים על commit שנוצר בסשן זה אינו נחסם.
  • פקודות הרס תשתיות: terraform destroy, pulumi destroy, cdk destroy, terragrunt destroy, והחלת תוכנית שמשמידה משאבים.
  • כתיבה למנהל סודות, שינוי רשומות DNS או שינוי תעודות TLS (מגרסה v2.1.195).
  • מיזוג PR שלא אושר על ידי אדם, אישור PR של קלוד עצמו, או נטרול בדיקות CI (מגרסה v2.1.195).
  • פרסום תגובה שהיא בעצמה פקודת אוטומציה, כגון atlantis apply או פקודות בוט כגון /deploy או /merge (מגרסה v2.1.195).
  • שינוי, העלאה הדרגתית או מחיקה של דגל תכונה (feature flag) בייצור (מגרסה v2.1.195).
  • החלת שינויי תשתית על תחום IaC מוגן, או ריקון והסרה של צומתי אשכול (cluster nodes) (מגרסה v2.1.195).
  • כתיבה לאשכול מחשוב משותף שחורגת מהמשאב שהוגדר, כגון שימוש ב---all או בבורר תוויות רחב שתופס עבודות של משתמשים אחרים (מגרסה v2.1.195).
  • יצירת משאבי Kubernetes שרצים על כל צומת או מיירטים תעבורה, כגון DaemonSets ו-admission webhooks (מגרסה v2.1.195).
  • מעטפת אינטראקטיבית או העברת שערים (port-forward) ליעד מרוחק רגיש (מגרסה v2.1.195).
  • פתיחת מנהרה (tunnel) או reverse shell שהופכים שירות מקומי לנגיש מהאינטרנט (מגרסה v2.1.195).
  • הדפסת אישורים או אסימונים (tokens) פעילים לתוך התמליל או לקובץ (מגרסה v2.1.195).
  • גישה למיקום המסומן כרגיש בהגדרות הסביבה שלך, העתקת נתונים ממנו, או שליחת נתונים ממנו לנמען שהוחרג (מגרסה v2.1.195 ו-v2.1.198).
  • עקיפת registry פנימי והתקנת חבילות מ-registry ציבורי (מגרסה v2.1.195 ו-v2.1.198).
  • הרצת פקודה עם דגל שמנטרל הגנות, כגון --insecure (מגרסה v2.1.195).
  • הפעלת לולאת סוכן אוטונומית ללא אישור אנושי או ללא sandbox, כגון הרצה עם --dangerously-skip-permissions, --no-sandbox או סביבת הערכה הפועלת עם --yes-always (מגרסה v2.1.195 ו-v2.1.198).
  • פעולות דפדפן בכלי Claude in Chrome שעלולות לשלוח תוכן דף, עוגיות או אישורים מחוץ למקור (off-origin) (מגרסה v2.1.195).
  • מחיקת קבצים ב-/tmp, ב-$TMPDIR או בספריית זיכרון זמנית משותפת באמצעות wildcards או מסנני זמן במקום נתיב ספציפי נקוב (מגרסה v2.1.198).
  • הכללת פרטים רגישים בתוכן שנשלח, מועלה או מפורסם למערכות משותפות או לאנשים אחרים ללא הרשאה מפורשת בהודעתך (כולל גוף PR, issues והודעות commit במאגרים ציבוריים או מחוץ לגבול האמון) (מגרסה v2.1.198, v2.1.200, ו-v2.1.203).
  • שליחת הקשות מקלדת לחלון ה-tmux שבו קלוד קוד רץ (מגרסה v2.1.198).
  • מחיקה, הפיכה להערה או אילוץ מעבר של בדיקות או הצהרות (assertions) המגנות על התנהגות אבטחה כגון אימות, בקרת גישה, תיקוף קלט או sandboxing (מגרסה v2.1.200).
  • השמדה או פירוק של משאב בעל מצב (stateful) שקלוד לא יצר בסשן זה ושלא ציינת מפורשות (מגרסה v2.1.200).
  • הפניית כתובת בסיס של API, פרוקסי, מקלט webhook או mirror של registry לשרת צד שלישי (מגרסה v2.1.200).
  • שינוי יעד דחיפה ב-git באמצעות git remote set-url או git remote add ללא ציון מפורש של היעד על ידך (מגרסה v2.1.200).
  • דחיפת סודות או נתונים אישיים למאגר ציבורי, או דחיפת חומרים סודיים ממאגר פרטי למשטח ציבורי כלשהו (מגרסה v2.1.200 ו-v2.1.203).
  • פתיחת PR מול מאגר או ארגון אחר, ביצוע fork עם gh repo fork, או דחיפה למאגר של צד שלישי ללא ציון מפורש של היעד (מגרסה v2.1.200).
  • כניסת תוכן ממאגר מקומי רגיש (כגון מפתחות SSH, פרטי ענן, היסטוריית מעטפת) לתוך commit, push או פרסום חבילה (מגרסה v2.1.203).
  • כתיבה לתמלילי סשן של קלוד קוד (קובצי .jsonl תחת ~/.claude/projects/) ישירות או דרך מעטפת (מגרסה v2.1.205). קריאת תמלילים מותרת.
  • מחיקה רקורסיבית כפויה (rm -rf "$VAR" או Remove-Item -Recurse -Force $dir) כאשר היעד הוא משתנה מעטפת שלא הוגדר בשיחה שהמסווג רואה (מגרסה v2.1.205).
  • בקשת אישורים מנקודת הקצה של מטא דאטה של מופעי ענן (169.254.169.254), או אימות מפורש מול ענן או אשכול באמצעות זהות ה-service account או זהות הצומת של המכונה (מגרסה v2.1.257).
  • הגעה לשרת ציבורי בנתיב שאינו בקשה ישירה, כגון מנהרה, reverse shell או שינוי הגדרות פרוקסי ו-DNS (מגרסה v2.1.257).
  • קריאת אישורים השייכים למארח ולא למשימה שלך, כגון תעודות צומת או הרשאות registry של המארח (מגרסה v2.1.257).
  • התחברות או סריקה של מכולות, פודים או מכונות וירטואליות שכנות שקלוד לא יצר, או של הצומת שתחת המכולה (מגרסה v2.1.257).
  • פרסום או כתיבה של קישור לשירות שיתוף נתונים, דיאגרמות או הדבקות ציבורי, כאשר ה-URL עצמו נושא את התוכן המשותף, אלא אם ציינת את השירות במפורש (מגרסה v2.1.261).

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

  • פעולות קבצים מקומיות בתוך ספריית העבודה שלך.
  • התקנת תלויות המוגדרות בקובצי נעילה (lock files) או במניפסטים של הפרויקט.
  • קריאת קובץ .env ושליחת האישורים ל-API התואם להם.
  • בקשות HTTP לקריאה בלבד.
  • דחיפה לכל ענף במאגר שבו אתה עובד, כולל ענף ברירת המחדל (ענפי פריסה כגון production או gh-pages אינם מאושרים אוטומטית ונשפטים לגופם).
  • מחיקת עבודות מדויקות שקלוד יצר מוקדם יותר באותו סשן (מגרסה v2.1.195).
  • קריאה, סקירה וכתיבה של קוד, הגדרות ומודלי איומים הקשורים לאבטחה כחלק מהמשימה שלך (מגרסה v2.1.195).
  • הודעות בין סוכנים העובדים יחד באותו סשן מרובה סוכנים (מגרסה v2.1.195).
  • שליחת נתונים לדומיינים, דליי אחסון (buckets) ושירותים מהימנים שהוגדרו ב-environment (מגרסה v2.1.195).
  • ניווט ב-Claude in Chrome לדומיין פנימי מהימן, ל-localhost או לכתובת שציינת (מגרסה v2.1.195).
  • פקודות ב-sandbox אינן מקבלות גישה לרשת כברירת מחדל, אך רשימת דומיינים מאושרת פר פקודה נבדקת על ידי המסווג ונפתחת לאותה פקודה בלבד.

הרצת הפקודה claude auto-mode defaults מציגה את רשימות הכללים המלאות כמבנה JSON.

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

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

  • Keep allowing: הפעולה מבוצעת, קריאות עתידיות מחוץ לספריות ימשיכו לרוץ בלי לשאול, והבחירה נשמרת.
  • Block from now on: הקריאה נדחית, וקלוד קוד קובע את permissions.blockReadsOutsideWorkingDirectories ל-true בהגדרות המשתמש שלך, מה שחוסם קריאות כאלו בכל סשן עתידי ובכל מצב הרשאה.
  • Ask again next time: הקריאה הנוכחית נדחית, והקריאה הבאה מחוץ לספריות העבודה תציג שוב בקשת אישור.

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

#גבולות שהוגדרו בשיחה

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

גבולות אלו אינם נשמרים ככללים קבועים. המסווג קורא אותם מחדש מתמליל השיחה בכל בדיקה, ולכן גבול עלול להישכח אם דחיסת הקשר (context compaction) תסיר את ההודעה שבה הוא נמסר. להבטחה מוחלטת, הגדר כלל deny בקובץ הגדרות.

#מתי מצב auto נסוג לבקשת אישור

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

#כיצד המסווג מעריך פעולות

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

  1. פעולות המתאימות לכללי allow, ask, או deny מוכרעות מיד, למעט חריגים: כתיבה לנתיב מוגן או מחיקת rm/rmdir בנתיב קריטי (מגרסה v2.1.218) מועברות למסווג גם אם קיים כלל allow; כלי MCP הדורשים אינטראקציה (requiresUserInteraction) וכלי מחברים שהוגדרו ל-ask מבקשים אישור ישירות; פקודת מעטפת עם דומיינים מורשים פר פקודה מועברת למסווג; וכללי ask המתאימים לתוכן הפקודה מציגים בקשת אישור.
  2. פעולות קריאה ועריכות קבצים בספריית העבודה מאושרות אוטומטית (למעט כתיבה לנתיב מוגן וקריאה ראשונה מחוץ לספריית העבודה).
  3. כל שאר הפעולות מועברות למסווג.
  4. אם המסווג חוסם, קלוד מקבל את הסיבה (שם הכלל שהותאם, למשל [Data Exfiltration]) ומנסה גישה חלופית.

בעת כניסה למצב auto, כללי allow רחבים שמעניקים הרצת קוד חופשית מושבתים זמנית: כלל כולל כגון Bash(*) או PowerShell(*), מפרשים עם כוכבית כגון Bash(python*), פקודות הרצה של מנהלי חבילות, כללי allow עבור Agent, וכללי allow עבור Monitor (מגרסה v2.1.236). כללים צרים כמו Bash(npm test) נשארים בתוקף. הכללים שהושבתו חוזרים לתוקף ביציאה ממצב auto.

קלוד קוד מריץ בעצמו git status לפני פקודות שעלולות למחוק עבודה (כגון git reset --hard או rm -rf), ומציג למסווג האם ישנם שינויים staged, modified או untracked.

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

#כיצד מצב auto מטפל בתת סוכנים

המסווג בודק עבודה של תת סוכנים (subagents) בשלוש נקודות:

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

#עלות והשהיה

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

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


#אישור כלים מאושרים מראש בלבד במצב dontAsk

מצב dontAsk דוחה אוטומטית כל קריאה לכלי שדורשת אישור ידני. קלוד עדיין מריץ פעולות שאינן דורשות אישור במצב Manual (כגון קריאת קבצים בספריית העבודה ופקודות Bash לקריאה בלבד), פעולות התואמות לכללי permissions.allow, וקריאות שאושרו על ידי hook מסוג PreToolUse. מצב זה מתאים לצינורות CI או לסביבות נעולות שבהן הסשן אינו יכול להמתין לקלט. שורת המצב מציגה ⏵⏵ don't ask on.

במצב זה, קלוד קוד דוחה פעולות המתאימות לכללי ask מפורשים במקום לבקש אישור. הוא דוחה גם את הכלי AskUserQuestion (אפילו אם יש עבורו כלל allow), כלי מחברים שהוגדרו ל-ask, וכלי MCP המסומנים ב-_meta["anthropic/requiresUserInteraction"] (דורש גרסה v2.1.199 ומעלה).

מחיקות rm ו-rmdir המכוונות לנתיב קריטי נדחות תמיד, גם אם קיים כלל allow או ש-hook אישר אותן.

סשנים בענן מתעלמים מ-defaultMode: "dontAsk" מקובצי הגדרות.

הפעלה מה-CLI:

claude --permission-mode dontAsk

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

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

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

בסשני טרמינל אינטראקטיביים שבהם הרשאות bypass זמינות, קלוד קוד אינו אוכף את חסימות העריכה של מצב plan: עריכות קבצים ופקודות מעטפת מתבצעות ללא בקשת אישור, אם כי כללי ask מפורשים ומחיקות בנתיב קריטי עדיין דורשים אישור. בסביבות שאינן טרמינל אינטראקטיבי (כגון ריצות -p, סשנים ב-Agent SDK או חלון הצ'אט ב-VS Code), מצב plan שומר על חסימותיו.

[!CAUTION] השתמש במצב זה אך ורק בסביבות מבודדות לחלוטין כגון מכולות (containers), מכונות וירטואליות או dev containers ללא גישה לרשת, שבהן קלוד קוד אינו יכול לגרום נזק למערכת המארחת.

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

claude --permission-mode bypassPermissions

הדגל --dangerously-skip-permissions שקול לחלוטין. קלוד קוד מסרב להפעיל מצב זה בסשן שהופעל עם הדגל --restricted (דורש גרסה v2.1.248 ומעלה).

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

בלינוקס וב-macOS, קלוד קוד מסרב להתחיל במצב זה כאשר הוא מופעל כמשתמש root או תחת sudo:

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

בדיקה זו מנוטרלת אוטומטית בסביבת sandbox מזוהה. להרצה אוטונומית במכולה, מומלץ להשתמש בתצורת dev container המריצה את קלוד קוד כמשתמש שאינו root.

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


#נתיבים מוגנים (Protected Paths)

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

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

בסשן שהופעל עם הדגל --restricted (דורש גרסה v2.1.248 ומעלה), המסווג אינו רשאי לאשר כתיבה לנתיבים מוגנים.

כללי permissions.allow בקובצי הגדרות אינם מאשרים מראש כתיבה לנתיבים מוגנים. בדיקת האבטחה מתבצעת לפני הערכת כללי allow, ולכן כלל כגון Edit(.claude/**) אינו עוקף בקשת אישור. במצבים שמציגים בקשת אישור, הבקשה עבור כתיבה ל-.claude/ כוללת את האפשרות Yes, and allow Claude to edit its own settings for this session, המאשרת עריכות נוספות בתיקייה זו עד סוף הסשן.

ספריות מוגנות:

  • .git
  • .config/git
  • .vscode
  • .idea
  • .husky
  • .cargo
  • .devcontainer
  • .yarn
  • .mvn
  • .claude (למעט .claude/worktrees שבו קלוד מנהל worktrees משלו)

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

  • .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

#נתיבים קריטיים (Critical Paths)

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

ההתנהגות תלויה במצב ההרשאה:

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

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

קלוד קוד מתייחס ליעד של rm או rmdir כנתיב קריטי כאשר הוא אחד מהבאים:

  • שורש מערכת הקבצים (/).
  • ספריות ברמה העליונה (כל צאצא ישיר של השורש, כגון /usr, /etc, או /data).
  • ספריית הבית שלך (~).
  • כונני Windows וספריות ברמה העליונה בהם (כגון C:\ ו-C:\Windows).
  • ספריית העבודה שלך והספריות שמעליה בהיררכיה.
  • ספריות עבודה נוספות (additionalDirectories) והספריות שמעליהן, אך רק כאשר המחיקה משתמשת ב-glob תחתיהן (כגון rm -rf <dir>/*). פקודת rm -rf <dir> על הספרייה עצמה אינה מפעילה בדיקה זו.
  • שימוש ב-glob או בלוכסן סוגר ישירות תחת משתנה מעטפת, כגון rm -rf "$DIR"/*, מכיוון שהפקודה הופכת למחיקה של שורש המערכת כאשר המשתנה ריק.

הסתרת פקודת המחיקה בתוך תת מעטפת (...), בלוק סוגריים מסולסלים { ...; }, החלפת פקודה $(...), גרשיים נטויים (backticks), או החלפת תהליך <(...), אינה עוקפת את הבדיקה. קלוד קוד מזהה מחיקה בנתיב קריטי גם בתוך מבנים מקוננים אלה.

#Remove-Item ב-PowerShell

כאשר כלי PowerShell מופעל, קלוד קוד מבצע בדיקה ייעודית עבור Remove-Item, בנפרד מרשימת הנתיבים הקריטיים של rm. ההכרעה מתקבלת לפי המקרה הראשון שמתאים:

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