📘 תיעוד 97

בחירת מצב הרשאות

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

מצב הרשאות קובע אילו פעולות קלוד יכול לבצע בהפעלה (session) מבלי לשאול אותך תחילה. במצב Manual, קלוד קוד (Claude Code) עוצר ושואל אותך לפני רוב הפעולות שעורכות קבצים, מריצות פקודות מעטפת (shell), או ניגשות לרשת. במצב auto, מודל שני, המסווג (classifier), בודק פעולות במקומך; הסעיף כיצד המסווג מעריך פעולות מפרט אילו פעולות הוא בודק ואילו מדלגות עליו.

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

מצבים זמינים

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

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

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

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

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

Claude Code אינו מאשר אוטומטית את הפעולות הבאות באף מצב, כולל bypassPermissions. כל נקודה ברשימה מקשרת לסעיף שמפרט מה קורה במקום זאת בכל מצב:

• כלים שתואמים לכלל ask מפורש.

• כלי קישור (connector tools) שהארגון שלך הגדיר ל-ask, בהפעלות שבהן הגדרה זו מגיעה אל Claude Code.

• כלים שדורשים אינטראקציית משתמש: הכלי המובנה AskUserQuestion וכלי MCP המסומנים כ-requiresUserInteraction.

• מחיקות rm ו-rmdir המכוונות אל נתיב קריטי, שאף כלל allow ואף הוק PreToolUse של "allow" אינם מאשרים.

• אמצעי ההגנה של הודעות בין הפעלות (cross-session messaging).

• קריאות מחוץ לתיקיות העבודה בזמן ש-permissions.blockReadsOutsideWorkingDirectories מופעל: פקודות Bash מוכרות לקריאת קבצים מבקשות אישור אפילו במצב auto ובמצב bypassPermissions, וכך גם כל ניסיון חוזר ללא ארגז חול (unsandboxed retry) שדורש אישור כדי לרוץ מחוץ לארגז החול. דורש את Claude Code בגרסה 2.1.257 ומעלה.

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

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

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

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

באיזה מצב הפעלה מתחילה

כאשר אתה מתחיל הפעלה חדשה במסוף (terminal), Claude Code לוקח את מצב ההרשאות מהראשון מאלה שחל:

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

שיחות שהתוסף ל-VS Code מתחיל פועלות לפי הרשימה של התוסף עצמו בסעיף החלפת מצבי הרשאות. לגבי מצב ההרשאות שבו Claude Code מתחיל הפעלה שחודשה, ראה מצב הרשאות בעת חידוש.

ברירת המחדל המובנית של auto דורשת את Claude Code בגרסה 2.1.228 ומעלה ב-macOS, Linux ו-WSL, ובגרסה 2.1.233 ומעלה ב-Windows מקורי. בגרסאות קודמות, ברירת המחדל המובנית היא Manual.

ברירת המחדל המובנית תלויה באופן שבו אתה מריץ את Claude Code, בתוכנית שלך, ובשאלה אם Claude Code הצליח להביא את דגלי התכונות (feature flags) שלו. השורה הראשונה שתואמת להפעלה שלך היא זו שחלה. הטבלה מכסה הפעלות שאתה מתחיל במסוף או דרך התוסף ל-VS Code; עבור אפליקציית ה-Desktop ו-claude.ai, ראה את הסעיפים של Desktop ושל אינטרנט ומובייל בסעיף החלפת מצבי הרשאות.

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

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

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

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

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

התחלה במצב הרשאות שונה

באפשרותך לקבוע את מצב ההרשאות ההתחלתי עבור הפעלה בודדת, או כברירת מחדל עבור כל הפעלה במחשב, בפרויקט או בארגון. כאשר יותר מקובץ הגדרות אחד מגדיר את permissions.defaultMode, סדר העדיפויות של ההגדרות קובע, כך שערך של פרויקט או ערך מנוהל גובר על ~/.claude/settings.json. כדי לשנות את מצב ההרשאות של הפעלה שכבר רצה, ראה החלפת מצבי הרשאות.

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

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

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

החלפת מצבי הרשאות

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

#CLI

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

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

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

מצבים אופציונליים שהופעלו משתלבים לאחר plan, כאשר bypassPermissions ראשון ו-auto אחרון. אם הפעלת את שניהם, תעבור דרך bypassPermissions בדרך ל-auto.

מתוך בקשת אישור של Bash: במצבי ההרשאות Manual ו-acceptEdits, כאשר מצב auto זמין, Claude Code מוסיף את Yes, and switch to auto mode לבקשת האישור של פקודת Bash. בחר באפשרות זו כדי לאשר את הפקודה ולהעביר את ההפעלה למצב auto. בקשות אישור של כלי PowerShell אינן מציעות אפשרות זו. דורש את Claude Code בגרסה 2.1.247 ומעלה.

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

בעת ההפעלה: העבר את מצב ההרשאות כדגל:

claude --permission-mode plan

כברירת מחדל: הגדר את permissions.defaultMode בהיקף הרצוי לך, כמתואר בסעיף התחלה במצב הרשאות שונה.

אותו דגל --permission-mode עובד עם -p עבור הרצות לא אינטראקטיביות.

#VS Code

במהלך הפעלה: לחץ על מחוון המצב בתחתית תיבת ההנחיה (prompt box). הוא משתמש בתוויות אלה עבור המצבים בדף זה:

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

1. claudeCode.initialPermissionMode.
2. המצב האחרון שבחרת ממחוון המצב, אם הוא היה Manual, Edit automatically, או Auto. בחירה ב-Plan או ב-Bypass permissions חלה על אותה שיחה בלבד.
3. permissions.defaultMode מתוך הגדרות מנוהלות או מ-~/.claude/settings.json, בתוכניות Pro, Max ו-Team כאשר הבאת דגלי תכונות זמינה.
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 אינו זמין.

ראה את מדריך VS Code לפרטים ספציפיים לתוסף.

#JetBrains

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

#Desktop

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

• Auto: מופיע כאשר מצב auto זמין.
• Bypass permissions: דורש את מתג Allow bypass permissions mode בהגדרות Desktop בתוכניות Pro ו-Max; בתוכניות Team ו-Enterprise, מדיניות הארגון שולטת בכך במקום זאת.

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

לפרטים ספציפיים ל-Desktop, ראה בחירת מצב הרשאות במדריך Desktop.

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

מצב שאתה בוחר בבורר המצב נשמר לכל תיקייה וגובר על defaultMode עבור אותה תיקייה. Plan הוא החריג: בחירה בו חלה על ההפעלה הנוכחית בלבד.

לגבי המיקום של defaultMode בקובץ הגדרות, ראה את הדוגמה תחת התחלה במצב הרשאות שונה.

#אינטרנט ומובייל (Web and mobile)

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

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

עבור 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, או עטיפות תהליכים (process wrappers) כגון 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", עדיין מבקש אישור אפילו בנתיבים שבתוך ההיקף, מכיוון ש-Claude Code אינו יכול לאמת סטטית ארגומנט שהקריאות שלו עם וללא מירכאות שונות. העבר את התוכן דרך פרמטר עם שם כגון -Value כדי למנוע את בקשת האישור.

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

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

claude --permission-mode acceptEdits

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

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

כאשר מצב auto זמין וההגדרה useAutoModeDuringPlan מופעלת, כפי שהיא כברירת מחדל, המסווג בודק פקודות מעטפת במהלך התכנון במקום לשאול אותך. פקודות שאושרו רצות, ופקודות שנדחו נחסמות. אחרת, פקודות מחוץ לערכת הקריאה בלבד המובנית מבקשות אישור, כולל כאשר מצב אישור אוטומטי (auto-allow) של ארגז החול מופעל. בהפעלות מסוף אינטראקטיביות שבהן הרשאות עקיפה זמינות, לא המסווג ולא בקשת אישור חלים על פקודות תכנון; הסעיף דילוג על כל הבדיקות באמצעות מצב bypassPermissions מכסה את הדברים הבודדים שעדיין מבקשים שם אישור. בגרסאות 2.1.212 עד 2.1.217, הפעלות ללא הרשאות עקיפה ביקשו אישור עבור כל פקודה מחוץ לערכת הקריאה בלבד, בין אם מצב auto היה זמין ובין אם לאו.

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

claude --permission-mode plan

לחץ על Shift+Tab שוב כדי לצאת ממצב plan מבלי לאשר תוכנית.

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

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

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

אישור תוכנית יוצא ממצב plan ומעביר את ההפעלה למצב ההרשאות שכל אפשרות אישור מתארת, כך שקלוד מתחיל לערוך. כדי לתכנן שוב, חזור במחזור למצב plan באמצעות Shift+Tab, או הוסף קידומת /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) מובנית, לפני ש-Claude Code מוסר אותה, הן במצב auto והן במצב plan כאשר המסווג בודק פקודות; בדיקת השליחה דורשת את Claude Code בגרסה 2.1.222 ומעלה.

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

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

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

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

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

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

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

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

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

ב-Amazon Bedrock, ב-Agent Platform של Google Cloud, ב-Microsoft Foundry, ובהפעלות Claude apps gateway מחוברות, מצב auto מופיע במחזור Shift+Tab כברירת מחדל. הופעה במחזור אינה משנה את מצב ההרשאות שבו הפעלה מתחילה: בספקים אלה, הפעלות מסוף מתחילות ב-defaultMode שלך, שהוא Manual אלא אם תשנה אותו, ושיחות בתוסף ל-VS Code מתחילות ב-Manual אלא אם claudeCode.initialPermissionMode או מצב שבחרת בתוסף מגדירים כזה. רק Claude Sonnet 5, Opus 4.7 ומעלה, ומודלי Fable נתמכים בספקים אלה.

כדי להפוך את מצב auto למצב ההרשאות ההתחלתי המוגדר כברירת מחדל, הגדר את "permissions": {"defaultMode": "auto"} בהגדרות משתמש או בהגדרות מנוהלות. בהפעלות שהתוסף ל-VS Code מתחיל, בחר Auto ממחוון המצב במקום זאת. הסעיף החלפת מצבי הרשאות מכסה מה גובר על בחירה זו.

בדיקת ה-/doctor מציעה ברירת מחדל זו של הגדרות משתמש בספקים אלה באותו אופן שהיא עושה זאת ב-Anthropic API.

כדי למנוע ממפתחים להשתמש במצב auto, הגדר את disableAutoMode ל-"disable" בהגדרות מנוהלות. פעולה זו מסירה את auto ממחזור Shift+Tab, והפעלה שתופעל עם --permission-mode auto תתחיל ב-Manual במקום זאת. הפעלה שכבר רצה במצב auto עוזבת אותו כאשר ההגדרה מגיעה לאותה הפעלה ממקור שנפרס על ידי מנהל מערכת, ומציגה auto mode disabled by settings. לפני גרסה 2.1.251, הפעלה פעילה שמרה על מצב auto עד סיומה.

בגרסאות 2.1.158 עד 2.1.206, מצב auto היה כבוי בספקים אלה עד שהגדרת CLAUDE_CODE_ENABLE_AUTO_MODE=1, ו-Claude Code התעלם מ-defaultMode: "auto" בספקים אלה אלא אם המשתנה הוגדר גם כן. המשתנה עדיין מתקבל לצורכי תאימות ואין לו כל השפעה מגרסה 2.1.207 ואילך.

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

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

פנייה לשרת כברירת מחדל דורשת את Claude Code בגרסה 2.1.278 ומעלה.

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

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

חסום כברירת מחדל:

• הורדה והרצה של קוד, כגון curl | bash.
• שליחת נתונים רגישים לנקודות קצה חיצוניות.
• פריסות ייצור (production deploys) ומיגרציות.
• מחיקה המונית באחסון ענן.
• הענקת הרשאות IAM או הרשאות מאגר (repo).
• שינוי תשתית משותפת.
• השמדה בלתי הפיכה של קבצים שהיו קיימים לפני ההפעלה.
• דחיפה בכוח (force push).
• ביצוע commit או push של שינוי שישלח סודות או נתונים רגישים מחוץ למאגר כאשר הוא ירוץ, או ירחיב את מה שפריסה חושפת. הדבר מכסה תהליך עבודה ב-CI או תצורת פריסה שמעבירים סוד ליעד שאינו מקבל אותו כבר, סקריפט או שלב התקנה שקוראים מאגר סודות ושולחים את הנתונים החוצה, ושינוי תצורה שמרחיב את מה שפריסה מפרסמת, כגון הגדרת registry, ניראות (visibility), תוצר (artifact) או מפת מקור (sourcemap). הבדיקה חלה על כל ענף, חלה גם כאשר המאגר ציבורי, ומופעלת כאשר השינוי מבוצע ב-commit או ב-push, בין אם אותו commit או push מפעיל את הצינור (pipeline) ובין אם לאו; ביטול החסימה דורש לציין את השפעת ההרצה, ולא רק את ה-commit או ה-push. לפני גרסה 2.1.211, בדיקה זו הייתה מוגבלת לענף ברירת המחדל במקום זאת: push לשם נחסם כאשר נשא תוכן רגיש, שינויים שהוסתרו או תוארו באופן שגוי ביחס למה שביקשת, תוכן שהובא מחוץ למאגר, או עקיפה של בדיקה שביקשת.
• git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, או git stash clear, שהמסווג מניח שיבטלו שינויים שלא נשמרו ב-commit.
• git commit --amend כאשר ה-commit ב-HEAD לא נוצר בהפעלה זו.
• החל מגרסה 2.1.198, git commit --amend כאשר ה-commit ב-HEAD כבר נדחף (pushed). ניסוח מחדש של ההודעה בלבד אינו נחסם: --amend -m ללא שום דבר שנוסף מחדש ל-staging, על commit שקלוד יצר במהלך הפעלה זו.
• terraform destroy, pulumi destroy, cdk destroy, או terragrunt destroy, והחלת תוכנית שמשמידה משאבים.

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

• כתיבה למנהל סודות (secret manager), או שינוי רשומות DNS או תעודות TLS.
• מיזוג של pull request שאף אדם לא אישר, אישור של pull request של קלוד עצמו, או השבתת בדיקות CI.
• פרסום תגובה שהיא בעצמה פקודה לאוטומציה, כגון atlantis apply או /deploy או /merge של בוט.
• החלפה, הגדלה הדרגתית (ramping) או מחיקה של דגל תכונה בייצור (production feature flag).
• החלת שינויי תשתית על היקף IaC מוגן, או ניקוז והסרה (draining and removing) של צמתי אשכול (cluster nodes).
• כתיבות לאשכול מחשוב משותף שמגיעות מעבר למשאב שנקבת בשמו, כגון בורר תוויות (label selector) או --all שתופס עבודות של משתמשים אחרים.
• יצירת משאבי Kubernetes שרצים בכל צומת או מיירטים תעבורת אשכול, כגון DaemonSets ו-admission webhooks.
• מעטפות אינטראקטיביות או העברות פורטים (port-forwards) אל יעד מרוחק רגיש.
• פתיחת מנהרה (tunnel) או מעטפת הפוכה (reverse shell) שהופכות שירות מקומי לנגיש מהאינטרנט הציבורי.
• הדפסת פרטי אימות או טוקן פעיל לתוך התמליל (transcript) או לקובץ.
• גישה למיקום המופיע כמיקום נתונים רגישים ב-סביבה שלך, או העתקת נתונים מתוכו. החל מגרסה 2.1.198 הדבר חוסם גם שליחת נתונים מאחד כזה לקהל שהערך אינו כולל.
• ניתוב התקנת חבילה סביב מאגר החבילות הפנימי שלך אל מאגר ציבורי. החל מגרסה 2.1.198, הדבר חל גם כאשר אמרת לקלוד בשיחה שקיים מאגר פנימי או מראה (mirror), ולא רק כאשר הוא מופיע בסביבה שלך.
• הרצת פקודה עם דגל שמנטרל מנגנון הגנה, כמו --insecure.
• הפעלת לולאת סוכן אוטונומית שרצה ללא אישור אנושי או ללא ארגז חול, כגון לולאה שהופעלה עם --dangerously-skip-permissions או --no-sandbox. החל מגרסה 2.1.198 הדבר מכסה גם הרצת סוכן צד שלישי או מסגרת הערכה (eval harness) כאשר הבידוד ואישור פר-פעולה מושבתים, כגון מריץ שהופעל עם --yes-always.
• פעולות דפדפן של Claude in Chrome שעלולות לשלוח תוכן דף, קובצי cookie או פרטי אימות מחוץ למקור (off-origin).

גרסה 2.1.198 ומעלה חוסמות כברירת מחדל גם את אלה:

• מחיקת קבצים ב-/tmp, ב-$TMPDIR, או בתיקיית עבודה או מטמון משותפת אחרת באמצעות תווים חופשיים (wildcard), גלוב (glob) או מסנן גיל ולא לפי נתיב ספציפי בעל שם.
• הכללת פרטים רגישים בתוכן שנשלח, הועלה, פורסם או נכתב לאנשים אחרים או למערכות משותפות, כאשר הודעתך שלך לא אישרה פרטים אלה עבור אותו נמען. גופי PR ו-issue, הודעות commit ותגובות נחשבים לתוכן יוצא מסוג זה כאשר המאגר נמצא מחוץ לגבול האמון או שהוא ציבורי, כולל מאגרים ציבוריים של הארגון שלך עצמו; נתיבי קבצים פנימיים, שמות קוד, נתוני תגובת API פעילים כגון הודעות דוא"ל או מזהי חשבונות, ומזהי תשתית נחשבים לפרטים רגישים. תיחום ההיקף של PR, issue והודעות commit דורש את Claude Code בגרסה 2.1.200 ומעלה. נתונים אישיים פעילים מתגובת API בגוף PR או issue, כגון כתובת דוא"ל, מזהה חשבון או ארגון, או מדד שימוש, מחייבים אותך לציין פרטים אלה ואת הנמען ללא קשר לניראות המאגר או לגבול האמון. בדיקה זו דורשת את Claude Code בגרסה 2.1.203 ומעלה.
• שליחת הקשות מקלדת לחלונית ה-tmux של Claude Code עצמו כדי להפעיל את הממשק שלו, דבר שהמסווג מתייחס אליו כקלוד המשנה את ההרשאות או הפיקוח של עצמו.

גרסה 2.1.200 ומעלה חוסמות כברירת מחדל גם את אלה:

• הפיכת בדיקה או טענה (assertion) המגנה על התנהגות אבטחה להערה (commenting out), מחיקתה או העברתה בכוח (force-passing), כגון אימות (auth), בקרת גישה, אימות קלט או ארגז חול.
• מחיקה או פירוק של משאב בעל מצב (stateful resource) שקלוד לא יצר בהפעלה, כאשר לא חל כלל מחיקה ספציפי יותר ולא נקבת בשם אותו משאב.
• הפניה מחדש של כתובת בסיס של API, נקודת קצה של פרוקסי, מקבל webhook או מראת מאגר אל מארח צד שלישי שאינו מתאים למשימה, כולל בקובצי דוגמה כמו .env.example.
• שינוי היעד של דחיפות (pushes) באמצעות git remote set-url או git remote add, אלא אם ציינת את שם המאגר המרוחק החדש.
• דחיפת סודות או נתונים אישיים או נתונים שנמסרו בנאמנות אל מאגר הידוע כציבורי, או דחיפת חומר סודי לשם שאינו חלק מהעבודה של אותו מאגר עצמו. נושא העבודה של מאגר dotfiles הוא החריג היחיד עבור נתונים אישיים או נתונים שנמסרו בנאמנות, ותוכן ממאגר פרטי שמגיע למשטח ציבורי כלשהו נחסם באותו אופן; שני הדיוקים הללו דורשים את Claude Code בגרסה 2.1.203 ומעלה. לפני גרסה 2.1.203, נתונים אישיים קובצו יחד עם חומר סודי ונחסמו רק כאשר לא היו חלק מהעבודה של אותו מאגר עצמו. כאשר הניראות של מאגר אינה ידועה, המסווג אינו חוסם על סמך עובדה זו בלבד; הוא שופט את התוכן מול שאר הכללים במקום זאת.
• פתיחת pull request כנגד מאגר או ארגון אחר, יצירת fork באמצעות gh repo fork, או דחיפה למאגר של צד שלישי, אלא אם ציינת יעד חיצוני זה.

גרסה 2.1.203 ומעלה חוסמות כברירת מחדל גם את אלה:

• תוכן מאחסון מקומי רגיש, או מקובץ ששמו, נתיבו או סוגו מסמנים אותו כרגיש, הנכנס ל-commit, ל-push, לטקסט של PR או issue, ל-gist או paste, או לפרסום חבילה, אלא אם ציינת הן את המקור והן את היעד. תמלילי הפעלה ויומני שיחה, תיקיות נקודה של פרטי אימות ותצורה כגון מפתחות SSH, פרטי אימות ענן, פרופילי דפדפן והיסטוריית מעטפת, וייצוא נתוני משתמש נחשבים כולם, והעובדה שהמאגר פרטי אינה מבטלת את החסימה.

גרסה 2.1.205 ומעלה חוסמות כברירת מחדל גם את אלה:

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

גרסה 2.1.257 ומעלה חוסמות כברירת מחדל גם את אלה:

• בקשת פרטי אימות מנקודת הקצה של מטא-נתוני מופע ענן (instance-metadata endpoint), כגון 169.254.169.254, או אימות מפורש של קריאת ענן, אשכול או מאגר באמצעות זהות חשבון השירות או הצומת של המכונה עצמה.
• הגעה למארח ציבורי בנתיב שאינו בקשה ישירה, כגון מנהרה, מעטפת הפוכה, או תצורת מפענח (resolver) או פרוקסי שנכתבה מחדש כדי להצביע החוצה.
• קריאת פרטי אימות השייכים למארח ולא למשימה שלך, כגון תעודות צומת או אימות מאגר המכולות של הצומת.
• התחברות או סריקה של מכולות, פודים (pods) או מכונות וירטואליות אחים שקלוד לא הפעיל, או הצומת שמתחת למכולה.
• אם Claude Code רץ במקום שנועד לאפשר אחד מאלה, תאר הגדרה זו ברשומת הכלת מארח (Host containment) ב-autoMode.environment.

גרסה 2.1.261 ומעלה חוסמות כברירת מחדל גם את אלה:

• פרסום או כתיבה של קישור לשירות הדבקה (paste), תרשימים או שיתוף נתונים ציבורי בהודעה, בטקסט של PR או issue, במסמך, או בכל מקום אחר שבו הקישור ייפתח או יובא, כאשר כתובת ה-URL עצמה נושאת את התוכן המשותף, אלא אם ציינת שירות זה בשמו.

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

• פעולות קבצים מקומיות בתיקיית העבודה שלך.
• התקנת תלויות המוצהרות בקובצי הנעילה (lock files) או המנשרים (manifests) שלך.
• קריאת .env ושליחת פרטי אימות ל-API התואם שלהם.
• בקשות HTTP לקריאה בלבד.
• דחיפה (push) לכל ענף במאגר שבו אתה עובד, כולל ענף ברירת המחדל. ענף שאינו ענף ברירת המחדל ששמו מסמן אותו כיעד פריסה או פרסום, כגון production או gh-pages, אינו מכוסה: המסווג שופט דחיפה לשם בפני עצמה. תוכן הדחיפה עדיין נבדק מול שאר הכללים, כללי permissions.deny עדיין יכולים לחסום פקודות push כפי שנכתבו בכל מצב, והגנת הענף של המאגר המרוחק עצמו עדיין חלה. לפני גרסה 2.1.211, רק דחיפות לענף שבו התחלת, לענפים שקלוד יצר, ודחיפות שגרתיות לענף ברירת המחדל הותרו כברירת מחדל, ולפני גרסה 2.1.203 כל דחיפה ישירה לענף ברירת המחדל נחסמה.

גרסה 2.1.195 ומעלה מתירות כברירת מחדל גם את אלה:

• מחיקת העבודות המדויקות שקלוד יצר קודם לכן באותה הפעלה.
• קריאה, בדיקה או כתיבה של קוד, תצורות ומודלי איומים הקשורים לאבטחה כחלק מהמשימה שלך.
• הודעות בין סוכנים שעובדים יחד באותה הפעלת ריבוי סוכנים.
• שליחת נתונים לדומיינים, דליים (buckets) ושירותים מהימנים שאתה מציין ב-environment. הדבר מכסה זרימת נתונים בלבד, ולא פעולות הרסניות או פעולות הקשורות לפרטי אימות באותה תשתית.
• ניווט של Claude in Chrome לדומיין פנימי מהימן, ל-localhost, או לכתובת URL שציינת בשמה.

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

הרץ claude auto-mode defaults כדי להדפיס את רשימות הכללים המלאות כ-JSON. אם פעולות שגרתיות נחסמות, מנהל מערכת יכול להוסיף מאגרים, דליים ושירותים מהימנים דרך ההגדרה autoMode.environment: ראה הגדרת מצב auto.

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

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

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

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

לא משנה מה תענה, קלוד ממשיך לעבוד:

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

גבולות שאתה מציין בשיחה

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

גבולות אינם נשמרים ככללים. המסווג קורא אותם מחדש מהתמליל בכל בדיקה, כך שגבול עלול ללכת לאיבוד אם דחיסת הקשר (context compaction) מסירה את ההודעה שציינה אותו. לקבלת ערובה קשיחה, הוסף כלל חסימה (deny rule) במקום זאת.

כאשר מצב auto נסוג לאחור

כאשר מצב auto אינו יכול לאשר את פעולות ההפעלה שלך, מה שקורה תלוי במקרה:

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

חסימות חוזרות מעידות בדרך כלל על כך שלמסווג חסר הקשר לגבי התשתית שלך. השתמש ב-/feedback כדי לדווח על זיהויים שגויים (false positives), או בקש ממנהל מערכת להגדיר תשתית מהימנה.

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

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

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

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

• Bash(*) או PowerShell(*) גורף.
• מפרשים בעלי תווים חופשיים כמו Bash(python*).
• פקודות הרצה של מנהל חבילות (package-manager run commands).
• כללי allow עבור Agent.
• כללי allow עבור Monitor, מכיוון ש-Claude Code מריץ פקודות Monitor דרך המעטפת.

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

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

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

באפשרותך להוסיף הערה לתוצאת קריאה באמצעות שדה classifierContext של הוק PostToolUse, שאותו המסווג קורא כהקשר שסופק על ידי האפליקציה. השדה דורש את Claude Code בגרסה 2.1.236 ומעלה.

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

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

המסווג בודק את עבודת תת-הסוכן (subagent) בשלוש נקודות:

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

שלב 1 דורש את Claude Code בגרסה 2.1.178 ומעלה. גרסאות קודמות החילו את המסווג בשלבים 2 ו-3, אך לא העריכו את תיאור המשימה לפני שתת-הסוכן התחיל.

עלות והשהיה

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

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

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

גישה מבוד דת לרשת (Sandboxed network access) אינה מוסיפה בקשות מסווג לכל חיבור. המסווג שופט את המארחים שפקודה מציינת יחד עם הפקודה בבדיקה אחת, ו-Claude Code בודק כל חיבור מול הרשימה המאושרת מבלי לקרוא למסווג שוב.

התרת כלים שאושרו מראש בלבד באמצעות מצב dontAsk

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

Claude Code דוחה קריאות התואמות לכללי ה-ask המפורשים שלך במקום לבקש אישור. הוא דוחה גם את הכלי המובנה AskUserQuestion אפילו אם כללי ה-allow שלך תואמים לו, ועושה את אותו הדבר לכלי קישור שהארגון שלך הגדיר ל-ask בהפעלות שבהן הגדרה זו מגיעה אל Claude Code. הוא דוחה כלי MCP המסומנים כ-_meta["anthropic/requiresUserInteraction"] באותו אופן, מכיוון שכרטיס האישור שלהם זקוק לתשובה שמצב זה לעולם אינו אוסף; הדבר דורש את Claude Code בגרסה 2.1.199 ומעלה.

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

הפעלות ענן מתעלמות מ-defaultMode: "dontAsk"; ראה bypassPermissions לפרטים.

הגדר אותו בעת ההפעלה באמצעות הדגל:

claude --permission-mode dontAsk

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

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

הפעולות שאף מצב אינו מאשר אוטומטית עדיין מבקשות אישור במצב זה.

שני אמצעי הגנה של הודעות בין הפעלות (cross-session messaging) עדיין חלים במצב זה, ובהפעלות מסוף אינטראקטיביות במצב plan שבהן הרשאות עקיפה זמינות:

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

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

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

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

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

claude --permission-mode bypassPermissions

הדגל --dangerously-skip-permissions שווה ערך.

Claude Code מסרב ל-bypassPermissions בהפעלה שאתה מתחיל עם --restricted. הדגל --restricted דורש את Claude Code בגרסה 2.1.248 ומעלה.

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

ב-Linux וב-macOS, Claude Code מסרב להתחיל במצב זה כאשר הוא רץ כ-root או תחת sudo:

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

הבדיקה מדולגת אוטומטית בתוך ארגז חול מוכר. כדי לרוץ באופן אוטונומי בתוך מכולה, השתמש בתצורת dev container, המריצה את Claude Code כמשתמש שאינו root.

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

אזהרה: bypassPermissions אינו מציע שום הגנה מפני הזרקת הנחיות (prompt injection) או פעולות לא מכוונות. לבדיקות בטיחות ברקע עם הרבה פחות בקשות אישור, השתמש במצב auto במקום זאת. מנהלי מערכת יכולים לחסום מצב זה על ידי הגדרת permissions.disableBypassPermissionsMode ל-"disable" בהגדרות מנוהלות.

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

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

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

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

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

• .git
• .config/git
• .vscode
• .idea
• .husky
• .cargo
• .devcontainer
• .yarn
• .mvn
• .claude, למעט .claude/worktrees שבו קלוד מאחסן את עצי העבודה (git 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

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

Claude Code לעולם אינו מאפשר לכלל permissions.allow או להוק PreToolUse שמחזיר "allow" לאשר פקודת rm או rmdir המכוונת אל נתיב קריטי, אפילו במצבים שמדלגים על בקשות אישור אחרות. מפסק ביטחון זה מגן מפני שגיאת מודל. כלל חסימה (deny rule) תואם עדיין חוסם את הפקודה לחלוטין.

מה שקורה במקום זאת תלוי במצב ההרשאות שלך:

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

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

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

Claude Code מתייחס גם לגלוב או ללוכסן סוגר ישירות תחת משתנה מעטפת, כגון rm -rf "$DIR"/*, כמחיקת נתיב קריטי, מכיוון שהפקודה הופכת למחיקה משורש מערכת הקבצים כאשר המשתנה ריק.

הסתרת המחיקה בתוך תת-מעטפת עם (...), קבוצת סוגריים מסולסלים עם { ...; }, החלפת פקודה עם $(...) או backticks, או החלפת תהליך עם <(...), אינה מדלגת על הבדיקה. Claude Code מאתר מחיקת נתיב קריטי בין אם היא נמצאת בתוך המבנה המקונן, כמו ב-(rm -rf ~) או ב-echo "$(rm -rf ~)", ובין אם במקום אחר באותה פקודה.

Remove-Item ב-PowerShell

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

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

ראה גם

• הרשאות: כללי allow, ask ו-deny; מדיניות מנוהלת.
• הגדרת מצב auto: הדרכת המסווג באיזו תשתית הארגון שלך נותן אמון.
• הוקים (Hooks): לוגיקת הרשאות מותאמת אישית דרך הוקים של PreToolUse ו-PermissionRequest.
• אבטחה: אמצעי הגנה ושיטות עבודה מומלצות.
• ארגז חול (Sandboxing): בידוד מערכת קבצים ורשת עבור פקודות Bash.
• מצב לא אינטראקטיבי: הרצת Claude Code עם הדגל -p.