לדלג לתוכן

2.3 הרשאות ומצבי עבודה הרצאה

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

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

למה בכלל הרשאות - why permissions

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

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

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

בקשת ההרשאה - the permission prompt

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

  Bash  rm build/cache.tmp

  Do you want to run this command?
  > 1. Yes
    2. Yes, and don't ask again for rm commands in this project
    3. No, tell Claude what to do differently (Esc)

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

  • Yes - מאשר את הפעולה הבודדת הזאת. בפעם הבאה יישאל שוב.
  • Yes, and don't ask again - מאשר, ומוסיף את סוג הפעולה הזה לרשימת ההיתר של הפרויקט, כך שלא יישאל שוב עליה.
  • No - דוחה, ומאפשר להסביר ל-Claude מה לעשות במקום.

ההבדל בין אפשרות 1 לאפשרות 2 הוא ההבדל בין אישור נקודתי לבין קביעת מדיניות. באפשרות 2 אתם אומרים "אני סומך על הפעולה הזאת מספיק כדי לא להישאל עליה שוב". זה מוביל אותנו לרשימת ההיתר.

רשימת ההיתר - the allowlist

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

הרשימה נשמרת בקובץ הגדרות. עבור פרויקט, המיקום הוא .claude/settings.json. הנה דוגמה:

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(git status)",
      "Read"
    ]
  }
}

התחביר Bash(npm test) אומר "הרשה את הפקודה npm test בלי לשאול". אפשר גם כללים רחבים יותר, אבל ככל שהכלל רחב יותר כך הוא מסוכן יותר - כלל כמו הרשאה גורפת לכל פקודת מעטפת מוותר למעשה על כל מנגנון הבטיחות. לצד allow יש גם deny (חסימה מוחלטת) ו-ask (תמיד שאל). כללי deny ו-ask חלים בכל המצבים, גם באלה הרפויים ביותר, ולכן הם הדרך החזקה להגן על דברים רגישים.

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

מצבי הרשאה - permission modes

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

מצב מה רץ בלי לשאול מתאים ל
default (מסומן Manual) קריאות בלבד התחלה, עבודה רגישה
acceptEdits קריאות, עריכות קבצים, ופקודות מערכת קבצים נפוצות עבודה על קוד שאתם סוקרים
plan קריאות בלבד, בלי עריכות חקירת קוד לפני שינוי
auto הכל, עם בדיקות בטיחות ברקע משימות ארוכות, פחות הפרעות
bypassPermissions הכל, בלי בדיקות סביבות מבודדות בלבד (קונטיינר, VM)

המצב שסוקר כל פעולה נקרא Manual בinterface, וערך ההגדרה שלו הוא default. חשוב להבין: בכל המצבים חוץ מ-bypassPermissions, כתיבה לנתיבים מוגנים (כמו .git או קבצי ההגדרה של Claude עצמו) לעולם לא מאושרת אוטומטית - זו רשת ביטחון נגד השחתה בשוגג.

מעבר בין מצבים - switching modes

הדרך המהירה להחליף מצב תוך כדי סשן היא ללחוץ Shift+Tab. זה מחזור בין המצבים: default (Manual) לוחצים פעם אחת ל-acceptEdits, ושוב ל-plan, ושוב חוזר להתחלה. המצב הנוכחי מופיע בשורת המצב בתחתית המסך. למשל, כשמצב acceptEdits פעיל, מופיע הסימון ⏵⏵ accept edits on.

אפשר גם לקבוע מצב בהפעלה, דרך דגל שורת פקודה:

claude --permission-mode plan
claude --permission-mode acceptEdits

ואפשר לקבוע מצב ברירת מחדל קבוע דרך defaultMode בקובץ ההגדרות:

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

חשוב לדעת: המצב נקבע דרך הפקדים האלה (Shift+Tab, דגל, הגדרה), לא על ידי בקשה מ-Claude בצ'אט. אם תבקשו מהagent "עבור למצב אחר", זה לא הדרך - משתמשים בפקדים.

נתיבים מוגנים - protected paths

יש קבוצה קטנה של נתיבים שכתיבה אליהם לעולם לא מאושרת אוטומטית, בכל המצבים חוץ מ-bypassPermissions. המטרה: למנוע השחתה בשוגג של מצב הrepo ושל ההגדרות של Claude עצמו. בין הנתיבים המוגנים: תיקיית .git, קבצי ההגדרה של git, קבצי המעטפת שלכם (כמו .bashrc ו-.zshrc), ותיקיית .claude. גם אם תוסיפו כלל היתר גורף, כתיבה לנתיבים האלה תמשיך להישאל (או תיחסם, תלוי במצב).

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

בניית רשימת היתר תוך כדי עבודה - building the allowlist

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

> run the tests
  Bash  npm test
  Do you want to run this command?
  > 2. Yes, and don't ask again for npm test in this project

[from now on, npm test won't be asked about again in this project]

> check the status of git
  Bash  git status
  > 2. Yes, and don't ask again for git status in this project

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

הערה חשובה על פקודות קריאה: פקודות מעטפת שהן קריאה בלבד (כמו ls, cat, git log) נחשבות בטוחות ולרוב מאושרות בלי טרחה מיותרת. ההקפדה של המנגנון מתמקדת בפקודות שמשנות משהו או בעלות השלכות חיצוניות.

מצב acceptEdits - הפשרה הנפוצה

המצב acceptEdits הוא כנראה זה שתשתמשו בו הכי הרבה בעבודה שוטפת. הוא נותן ל-Claude ליצור ולערוך קבצים בתיקיית העבודה בלי לשאול על כל עריכה. בנוסף לעריכות, הוא מאשר אוטומטית פקודות מערכת קבצים נפוצות כמו mkdir, touch, mv, cp. פקודות אחרות ופעולות מחוץ לתיקיית העבודה - עדיין נשאלות.

מתי להשתמש בו? כשאתם סומכים על הכיוון וסוקרים את השינויים בדיעבד, למשל דרך git diff, במקום לאשר כל עריכה תוך כדי. זה מאיץ מאוד עבודה איטרטיבית: הagent משנה כמה קבצים ברצף, ואתם סוקרים את הכל בסוף.

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

מצב auto וההשלכות של אישור אוטומטי - auto mode

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

בקצה הקיצוני ביותר יש את bypassPermissions, שמכבה את כל הבדיקות. הדגל המקביל הוא --dangerously-skip-permissions. השם לא מקרי: זה מצב שמוותר על כל ההגנות, כולל הגנה מפני הזרקת prompts. יש להשתמש בו רק בסביבות מבודדות לחלוטין - קונטיינר או מכונה וירטואלית בלי גישה לאינטרנט - שבהן הagent לא יכול לפגוע במערכת שלכם. במחשב העבודה הרגיל שלכם, אל תשתמשו בו.

היכן לשמור כל כלל - settings scopes

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

קובץ היקף מתי להשתמש
~/.claude/settings.json כל הפרויקטים שלכם פקודות שאתם סומכים עליהן בכל מקום, כמו git status
.claude/settings.json הפרויקט, משותף בצוות כללים שנכונים לכל מי שעובד על הפרויקט
.claude/settings.local.json הפרויקט, רק אתם היתרים אישיים שלא רוצים לשתף (הוסיפו ל-gitignore)

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

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

הפשרה המרכזית - the tradeoff

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

More oversight                                     More convenience
   default  ->  acceptEdits  ->  auto  ->  bypassPermissions
(asks about everything)                         (never asks, dangerous)

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

סיכום

  • הרשאות קיימות כי הagent מריץ פקודות אמיתיות: יש פעולות בלתי הפיכות, הבנה עלולה להיות שגויה, וקלט עלול להיות מורעל.
  • בקשת ההרשאה מציעה שלוש אפשרויות: Yes (פעם אחת), Yes and don't ask again (הוספה לרשימת היתר), ו-No (דחייה עם הסבר).
  • רשימת ההיתר נשמרת ב-.claude/settings.json תחת permissions.allow, ומאפשרת לאשר מראש פקודות מהימנות. כללי deny ו-ask חלים בכל מצב.
  • מצבי הרשאה קובעים מה רץ בלי לשאול: default (Manual, קריאות בלבד), acceptEdits (עריכות בלי לשאול), plan (חקירה בלבד), auto (הכל עם בדיקות רקע), ו-bypassPermissions (הכל, לסביבות מבודדות בלבד).
  • מחליפים מצב עם Shift+Tab (מחזור default -> acceptEdits -> plan), עם הדגל --permission-mode, או עם defaultMode בהגדרות. לא דרך בקשה מ-Claude.
  • acceptEdits הוא הפשרה הנפוצה: מהיר לעבודה איטרטיבית, מוותר על סקירה בזמן אמת.
  • auto מפחית בקשות עם מסווג בטיחות ברקע אך אינו מבטיח בטיחות; bypassPermissions מסוכן ומיועד לסביבות מבודדות בלבד.
  • הפשרה המרכזית: נוחות מול פיקוח. מתחילים בפיקוח מלא, מרפים ככל שהאמון גובר.