הסביבה המבודדת בקלוד קוד: מה באמת נמצא בתוך הגבול

יש בלבול נפוץ סביב הסביבה המבודדת של קלוד קוד, והוא מתחיל בשם. “בידוד” נשמע כמו קופסה שקלוד יושב בתוכה — ובפועל זה לא מה שקורה. שם העמוד בתיעוד של Anthropic אומר את זה בלי להתחכם: הגדרת כלי ה-Bash המבודד. לא הגדרת קלוד המבודד.

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

מה בדיוק נמצא בתוך הגבול?

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

שלוש נקודות שכדאי לקרוא לאט:

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

שתי שכבות, ואפשר לכבות אחת מהן

הבידוד אינו מנגנון אחד אלא שניים, והם עצמאיים לגמרי:

בידוד קבצים קובע לאן פקודה יכולה לכתוב ומה היא יכולה לקרוא. כברירת מחדל הכתיבה מוגבלת לתיקיית העבודה ולתיקיית הזמניים של הסשן, והקריאה — וכאן ההפתעה — פתוחה כמעט לכל המחשב. התיעוד אומר זאת בלי לרכך: ברירת המחדל עדיין מתירה קריאה של קובצי סודות כמו ‎~/.aws/credentials‎ ושל התיקייה ‎~/.ssh‎.

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

מרחיבים כתיבה עם ‎allowWrite‎, וחוסמים קריאה עם ‎denyRead‎ — שאפשר לפתוח בחזרה נקודתית עם ‎allowRead‎. כשהכללים מתנגשים, המסלול הספציפי יותר מנצח:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

שימו לב שהנקודה בדוגמה הזאת מתייחסת לשורש הפרויקט רק כשהקובץ יושב בהגדרות הפרויקט. באותו קובץ תחת ‎~/.claude‎ היא הייתה נפתרת לתיקייה אחרת לגמרי, והפרויקט היה נשאר חסום.

אפשר גם לכבות את שכבת הקבצים ולהשאיר רק את הרשת, עם ‎filesystem.disabled‎ (דורש גרסה 2.1.216 ומעלה). זה הגיוני כשמה שמעניין אתכם הוא לאן הקוד מתחבר ולא מה הוא כותב — אבל התיעוד מצמיד לזה אזהרה שקשה להתעלם ממנה: פקודה עם כתיבה חופשית יכולה לכתוב לקובץ שירוץ בהרצה הבאה, ובכך להרחיב לעצמה את ההרשאות. השאירו את השכבה הזאת דלוקה אלא אם אתם סומכים על העומס שרץ שם.

איך מפעילים את זה?

מריצים ‎/sandbox‎, ונפתחת לוחית עם שלוש לשוניות: Mode לבחירת אופן האישור, Overrides לשאלה אם פקודה שנכשלה יכולה לרוץ מחוץ לבידוד, ו-Config להצגת ההגדרות כפי שנפתרו בפועל.

במק אין מה להתקין — הבידוד נשען על Seatbelt המובנה. בלינוקס וב-WSL2 צריך שתי חבילות:

sudo apt-get install bubblewrap socat

אם משהו חסר, תופיע לשונית Dependencies שמפרטת בדיוק מה. בדיקת התלויות רצה בעליית התוכנה, ולכן אחרי התקנה צריך להפעיל מחדש את קלוד קוד כדי ש-‎/sandbox‎ יזהה אותן. מסנן ה-seccomp האופציונלי, שמוסיף חסימה של שקעי יוניקס, מותקן בנפרד עם ‎npm install -g @anthropic-ai/sandbox-runtime‎.

בחירה בלוחית נשמרת ל-‎.claude/settings.local.json‎ ותקפה לפרויקט הנוכחי. כדי להפעיל בידוד בכל הפרויקטים, מגדירים ‎sandbox.enabled‎ בהגדרות המשתמש.

ופרט אחד ששווה יותר מכל השאר: כברירת מחדל, כשהבידוד אינו יכול לעלות, קלוד קוד מציג אזהרה וממשיך להריץ בלי בידוד. מי שרוצה שזה ייכשל במקום להתפשר מגדיר ‎sandbox.failIfUnavailable‎.

שני מצבים, ומה עדיין עוצר אתכם

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

וגם באישור אוטומטי, ארבעה דברים ממשיכים לעצור:

• כללי דחייה מפורשים מכובדים תמיד
• ‎rm‎ או ‎rmdir‎ על השורש, על תיקיית הבית או על נתיבי מערכת קריטיים חוזרים למסלול ההרשאות הרגיל
• כלל שאלה ממוקד תוכן, כמו ‎Bash(git push *)‎, מכריח שאלה גם על פקודה מבודדת
• במצב תכנון הכלל אינו מדולג: גם פקודות מבודדות, כולל קריאה בלבד, יבקשו אישור. לפני גרסה 2.1.212 זה התנהג אחרת

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

הנתיבים המוגנים: הסעיף שמפתיע את כולם

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

הרשימה מכסה ארבע קבוצות:

• בתיקיית העבודה ומעליה: קובצי ההגדרות ב-‎.claude‎, התיקיות ‎.claude/skills‎, ‎.claude/agents‎, ‎.claude/commands‎ ו-‎.claude/hooks‎, הקובץ ‎.mcp.json‎, וגם מה שקלוד קוד מריץ מיוזמתו כמו ‎.claude/workflows‎ ו-‎.claude/scheduled_tasks.json‎
• בתיקיית העבודה בלבד: קובצי הפעלה של המעטפת כמו ‎.bashrc‎ ו-‎.zshrc‎, הקובץ ‎.gitconfig‎, התיקיות ‎.vscode‎ ו-‎.idea‎, וגם ‎hooks‎ ו-‎config‎ בתוך ‎.git‎
• קבצים שהיו הופכים את תיקיית העבודה למאגר git ערום: ‎HEAD‎, ‎objects‎ ו-‎refs‎ ברמה העליונה. בלינוקס וב-WSL2 הבידוד אפילו מוחק כאלה אם הם צצים בזמן שפקודה מבודדת רצה
• בתיקייה ‎~/.claude‎: רוב התוכן שלה, וגם ‎~/.claude.json‎ ומאגר ההזדהות ‎.credentials.json‎

ואי אפשר לפתוח אף אחד מהם נקודתית. כלל ‎allowWrite‎ שמכסה את הנתיב לא יעזור, וגם לא כלל היתר של ‎Edit‎. הדרך היחידה לבטל את ההגנה הזאת היא לכבות את שכבת הקבצים כולה. לראות את הרשימה כפי שנפתרה במחשב שלכם: ‎/sandbox‎, לשונית Config, תחת Denied within allowed.

פרט מעשי למי שעובדים ב-worktrees: הבידוד כן מתיר כתיבה לתיקיית ‎.git‎ המשותפת של המאגר הראשי, אחרת ‎git commit‎ לא היה יכול לעדכן רפרנסים — אבל ‎hooks‎ ו-‎config‎ בתוכה נשארים חסומים.

דלת החירום, ומתי לנעול אותה

חלק מהפקודות פשוט אינן עובדות מבודדות. ‎docker‎ אינו תואם, ‎watchman‎ תוקע את ‎jest‎, וכלים כתובי Go כמו ‎gh‎ ו-‎terraform‎ עלולים להיכשל באימות TLS תחת Seatbelt במק.

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

ומי שרוצה לסגור את הדלת לגמרי מכבה את ‎allowUnsandboxedCommands‎, ובלוחית זה נקרא Strict sandbox mode. אז הפרמטר מתעלמים ממנו לחלוטין, וכל פקודה חייבת לרוץ מבודדת או להיות רשומה במפורש ב-‎excludedCommands‎.

סודות: להסתיר, או להחליף?

ראינו שברירת המחדל מתירה קריאה של קובצי סודות. המענה יושב ב-‎sandbox.credentials‎ (מגרסה 2.1.187), ויש בו שתי גישות שונות מאוד באופיין.

‎deny‎ פשוט חוסם. קובץ הופך לבלתי קריא, ומשתנה סביבה נמחק לפני שהפקודה רצה. יעיל, אבל שובר כל כלי שבאמת צריך את הסוד — ‎gh‎ ו-‎npm‎ יפסיקו להזדהות.

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [{ "path": "~/.ssh", "mode": "deny" }],
      "envVars": [{ "name": "GITHUB_TOKEN", "mode": "deny" }]
    }
  }
}

‎mask‎ הולך רחוק יותר, וזה הרעיון היפה כאן. הפקודה בתוך הבידוד רואה ערך סנטינל — מחרוזת מזויפת — והפרוקסי מחליף אותו בערך האמיתי ביציאה, רק אל המארחים שרשמתם ב-‎injectHosts‎. הכלי ממשיך להזדהות, והסוד עצמו לעולם אינו יושב בזיכרון של התהליך או בלוגים שלו. התנאי: ‎network.tlsTerminate‎, כי בלי שהפרוקסי מסיים את ה-TLS בעצמו הוא אינו רואה את תוכן הבקשה. בלעדיו ההחלפה נכשלת בלי לחשוף כלום, וקלוד קוד מתריע על כך בעלייה.

שלושה סייגים ששווים יותר מהמנגנון עצמו:

• במק, מיסוך קובץ אינו מיסוך. בלינוקס וב-WSL2 הפקודה קוראת עותק סנטינל של הקובץ; במק היא פשוט אינה יכולה לקרוא אותו, בדיוק כמו ‎deny‎. מיסוך קובץ דורש גרסה 2.1.221 ומעלה
• מיסוך אינו מכובד מהגדרות המאגר. ‎mask‎, ‎tlsTerminate‎ ו-‎allowPlaintextInject‎ מתעלמים מ-‎.claude/settings.json‎ של פרויקט. הם מורשים רק מהגדרות המשתמש, מהגדרות מנוהלות ומדגל ‎—settings‎ — כי מיסוך מסמיך את הפרוקסי לשלוח את הסוד האמיתי החוצה, ולא סביר שקוד שמשכתם יחליט את זה בשבילכם
• אין רשימת סודות מובנית. מוגן רק מה שרשמתם. זו הנקודה שהכי קל לפספס

לערכים מובנים יש עידון: ‎extract‎ מקבל ביטוי רגולרי וממסך רק את מה שנתפס בקבוצה הראשונה, כך שקובץ תצורה נשאר קריא לכלי שמפרסר אותו, ו-‎decode: “jwt”‎ מחליף טוקן שלם בטוקן מזויף אך תקין מבנית, עם ‎maskClaims‎ למיסוך תביעות בודדות. שניהם דורשים גרסה 2.1.224 ומעלה.

מה הסביבה המבודדת אינה נותנת

זה הסעיף שהתיעוד של Anthropic פותח במשפט “מקטין סיכון, ואינו גבול בידוד מלא” — וכדאי לקחת אותו כפשוטו.

• הפרוקסי אינו פותח את התעבורה המוצפנת. הוא מחליט לפי שם המארח שהלקוח מבקש. משמעות הדבר, בלשון התיעוד עצמו, היא שקוד שרץ בתוך הבידוד יכול להשתמש בחזית דומיין (domain fronting) כדי להגיע למארחים שמחוץ לרשימה. אישור גורף ל-‎github.com‎ הוא נתיב הוצאת מידע אפשרי, לא רק נוחות
• ‎network.tlsTerminate‎ אינו פתרון לזה. הוא קיים כדי לאפשר מיסוך, והוא אינו מוסיף סינון תוכן. ארגון שצריך בדיקה אמיתית של התעבורה מצמיד פרוקסי משלו
• שקעי יוניקס הם דרך החוצה. ‎allowUnixSockets‎ יכול להעניק בטעות גישה לשירותי מערכת חזקים. הדוגמה שהתיעוד נותן חדה: היתר ל-‎/var/run/docker.sock‎ שווה בפועל לגישה למארח כולו
• הרשאות כתיבה רחבות מדי הן הסלמה. היתר כתיבה לתיקייה שיש בה קובצי הרצה ב-‎$PATH‎, או לקובצי ההפעלה של המעטפת, מוביל להרצת קוד בהקשר אחר לגמרי
• במק, ‎allowAppleEvents‎ מבטל את בידוד ההרצה. הוא פותר תקלות אימות בדפדפן, ובאותה נשימה מאפשר לפקודה מבודדת להפעיל אפליקציות אחרות לא מבודדות בלי שאלה
• בלינוקס, ‎enableWeakerNestedSandbox‎ מחליש משמעותית. הוא קיים כדי לעבוד בתוך קונטיינרים לא מורשים, ומקומו רק היכן שהקונטיינר החיצוני כבר מספק את הגבול

והנקודה שנוגעת לרוב הקוראים הישראלים: בווינדוס מקורי אין בידוד בכלל. לא חלקי, לא מוחלש — אין. WSL1 גם אינו נתמך, כי bubblewrap דורש יכולות ליבה שיש רק ב-WSL2. מי שמריצים קלוד קוד ישירות בווינדוס עובדים עם שכבת ההרשאות לבדה, וזו סיבה טובה להעביר את העבודה ל-WSL2. הדרך לשם: התקנת קלוד קוד בווינדוס.

מה כדאי להגדיר בארגון

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

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

ושלוש הערות שמונעות אכזבה. ראשית, למפתחות בוליאניים כמו ‎enabled‎ הערך המנוהל מנצח כל הגדרה מקומית, אבל מפתחות מסוג רשימה ממוזגים מכל המקורות — כלומר מפתח יכול להוסיף ערכים שמרחיבים את המדיניות. לנעילה אמיתית של קריאה ושל דומיינים יש ‎allowManagedReadPathsOnly‎ ו-‎allowManagedDomainsOnly‎.

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

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

שורה תחתונה

הסביבה המבודדת היא השכבה היחידה בקלוד קוד שאינה תלויה בשיקול דעת של מודל או בניתוח מחרוזת. היא לא שואלת מה הפקודה מתכוונת לעשות — היא קובעת למה היא תוכל לגעת. בגלל זה היא שווה את ההפעלה לכל מי שנותן לסוכן לרוץ ארוך בלי לשבת מולו.

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

שלושת הצעדים שכדאי לעשות היום, לפי הסדר: להריץ ‎/sandbox‎ ולבחור מצב; להוסיף את ‎~/.ssh‎ ואת קובצי ההזדהות של הענן תחת ‎sandbox.credentials‎, כי ברירת המחדל אינה עושה זאת בשבילכם; ולמי שעל ווינדוס — להעביר את קלוד קוד ל-WSL2, אחרת כל הפרק הזה תיאורטי.

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