📘 תיעוד 42

מצב ארגז חול

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

מצב ארגז חול כבוי כברירת מחדל.

#התחלה מהירה

# Run with workspace sandbox (read everywhere, write to CWD + temp dirs + ~/.grok/)
grok --sandbox workspace

# Read-only mode (read everywhere, write only to ~/.grok/ + temp dirs)
grok --sandbox read-only

# Most restrictive profile (read CWD + system paths + ~/.grok, write CWD + ~/.grok/sessions + temp dirs, no child network)
grok --sandbox strict

#פרופילים מובנים

¹ חסימת רשת של תהליכי בן נאכפת בלינוקס בלבד (דרך seccomp). ב-macOS זו פעולה ריקה (no-op): הפרופילים האלה לא מגבילים שם את הרשת של תהליכי בן.

² רק כשמנוע הדמון מריץ את הסשן. הוא מחזיק את השקעים, הלוג ומאגר הסשנים של הדמונים תחת strict. לפרופיל מותאם יש ~/.grok/daemon/run/<name> משלו.

כדי לחסום קבצים מסוימים (למשל .env או נתיבי אישורים) מעל פרופיל, הגדירו פרופיל מותאם עם רשימת deny. זה נאכף בליבה (קריאה + כתיבה/שינוי שם) ותומך בתבניות glob כמו **/*.pem.

#פרטי פרופיל

workspace: הפרופיל המומלץ לפיתוח יומיומי. הסוכן יכול לקרוא כל קובץ במערכת (כדי להבין תלויות, ספריות מערכת וכן הלאה) אבל יכול לכתוב רק לספריית העבודה הנוכחית, ל-~/.grok/ ולתיקיות זמניות (/tmp, /var/tmp, ובנוסף תיקיות הזמניות של macOS). גישה לרשת מותרת לכלים כמו web_search ושרתי MCP.

devbox: פרופיל מובנה שמור למכונות וירטואליות לפיתוח חד פעמי. הסוכן יכול לקרוא בכל מקום ולכתוב לכל תיקייה ברמה העליונה חוץ מ-/data וממערכות הקבצים הווירטואליות (/proc, /sys, /dev), כולל תיקיית הבית. גישה לרשת מותרת. --sandbox devbox מריץ את הפרופיל המובנה, שמצל על כל [profiles.devbox] שאתם מגדירים ב-sandbox.toml.

read-only: לשימוש כשרוצים שהסוכן ינתח קוד בלי לשנות את קבצי הפרויקט. הסוכן יכול לקרוא הכל אבל יכול לכתוב רק ל-~/.grok/ (נדרש לשמירת סשן) ולתיקיות זמניות. גישת רשת של תהליכי בן חסומה בלינוקס (פעולה ריקה ב-macOS).

strict: הפרופיל המגביל ביותר, לסקירת קוד לא מהימן. הסוכן יכול לקרוא את ספריית העבודה הנוכחית, נתיבי מערכת חיוניים ואת ~/.grok. הכתיבה מוגבלת ל-CWD, ל-~/.grok/sessions ולתיקיות זמניות: לא לכל עץ ~/.grok. כשמנוע הדמון מריץ את הסשן, הוא יכול גם לכתוב ל-~/.grok/daemon/run/strict (השקעים, הלוג ומאגר הסשנים של הדמונים תחת strict). גישת רשת של תהליכי בן חסומה בלינוקס (פעולה ריקה ב-macOS).

#Worktrees

worktree של git צריך גישת כתיבה ל-~/.grok ולתיקייה שבה Grok התחיל, וגישת קריאה לתצורת ה-git שלכם. workspace, devbox (אלא אם ~/.grok נמצא בתוך /data או מקשר לתוכו) ופרופילים מותאמים שמרחיבים את workspace מאפשרים את זה. תחת strict, read-only ופרופילים מותאמים שמרחיבים אותם, worktrees לא זמינים:

• grok -w, אינטראקטיבי או עם -p, יוצא עם שגיאה שמציינת את הפרופיל לפני שהסשן מתחיל. grok worktree create מסרב באותו אופן.
• grok -w -r <id> ו-grok -w -c יוצאים באותו אופן. כשהפרופיל השמור של הסשן שוחזר, השגיאה אומרת לחדש בלי -w, כי סשן שחודש שומר את הפרופיל שנשמר איתו.
• /fork ו-/new לא מציעים worktree. כש-fork_worktree_mode או new_session_worktree_mode מוגדרים ל-"always", הם נפתחים בתיקייה הנוכחית ואומרים זאת בסשן.
• בקשה ל-worktree מסרבת עם אותה שגיאה ולא משאירה דבר מאחור: /fork --worktree, Ctrl+W או שורת New worktree במסך הבית, New Session in Worktree בלוח הפקודות, Ctrl+W בבורר הסשנים, ומתג ה-worktree בלוח הבקרה. בורר המיקום בלוח הבקרה מסתיר את מתג ה-worktree שלו.
• סוכן משנה או שלב workflow שמבקש בידוד worktree רץ במקום זאת בתיקיית הסשן.

מחוץ למאגר git שגיאת "not a git repository" מגיעה קודם. הסירוב עוקב אחרי הפרופיל, גם בפלטפורמה שלא יכולה לאכוף אותו. כדי להשתמש ב-worktrees, עברו לפרופיל שיכול ליצור אותם במקום שבו הנוכחי מוגדר: --sandbox, GROK_SANDBOX, [sandbox] profile, או דרישה מנוהלת.

#עדכונים

תחת כל פרופיל חוץ מ-off, Grok אף פעם לא מתחיל עדכון בעצמו. הוא עדיין בודק אם יש גרסה חדשה יותר ומספר לכם עליה. רק grok update, שאתם מקלידים, מתקין עדכון.

• מסך הפתיחה אומר "Run grok update to get the latest version." ולא מציע Ctrl+U. מצב מינימלי מדפיס את אותה הודעה בסשן.
• תהליכי leader כמו grok agent leader מדלגים על העדכון השעתי שלהם. leader עדיין מופעל מחדש אל build שתהליך אחר התקין, כמו אחד מ-grok update.
• Grok עדיין עשוי לכוון מחדש את ~/.grok/bin/agent או להעתיק build שהוחלף. שניהם משתמשים ב-build שכבר מותקן.
• grok agent ו-grok agent stdio מדפיסים הודעה ל-stderr בהפעלה, למשל:

A new version of Grok Build is available: <current> -> <latest> [<channel>]
Run `grok update` to get the latest version.

grok update עצמו מתחיל בלי פרופיל ש-GROK_SANDBOX, --sandbox או התצורה מגדירים, אלא אם משהו כבר כולא את התהליך. כשהפרופיל כן חל, strict ופרופילים מותאמים שמבוססים עליו לא יכולים לכתוב את ה-build החדש תחת ~/.grok, והעדכון נכשל.

#הגנה ישירה על כתיבה גלובלית

תחת workspace, read-only ו-strict (ופרופילים מותאמים שמרחיבים את הבסיסים האלה), הליבה אוסרת כתיבה לנתיבי הדיסק הישירים שבבעלות Grok, המשמשים כמקורות hooks גלובליים למשתמש, וגם לקובצי התצורה וקבצי האמון שלהם (הם נשארים קריאים כשההרשאה ניתנה). strict המובנה יכול לקרוא את ~/.grok (הם נשארים קריאים). הכתיבה היא ל-CWD + ~/.grok/sessions + תיקיות זמניות, ובנוסף ~/.grok/daemon/run/strict כשמנוע הדמון מריץ את הסשן, לא לכל העץ. איסור הכתיבה עדיין חל במקום שהפרופיל מעניק בו כתיבה:

• ~/.grok/hooks/ (תיקיית hooks)
• ~/.grok/hooks-paths (קובץ רישום. הוא לא נטען כ-JSON של hook: רק היעדים המוחלטים שלו)
• יעדים מוחלטים שרשומים ב-hooks-paths (שורות יחסיות מתעלמות. יעדים חסרים מסרבים להתחלת ארגז החול)
• ~/.grok/config.toml, ~/.grok/trusted_folders.toml, ~/.grok/managed_config.toml, ~/.grok/requirements.toml, ~/.grok/sandbox.toml (הגדרות, אמון בתיקיות, מדיניות מנוהלת, דרישות ופרופילי ארגז חול)
• ~/.grok/bundled/ ו-~/.grok/bundles/ (מטמוני חבילות מובנים. כל מה שמונח שם נטען כ-skill, סוכן או workflow מובנה)

מכיוון שהקבצים האלה הם לקריאה בלבד תחת הפרופילים האלה, שינוי שהיה נשמר אליהם חל על הסשן הנוכחי בלבד. אישור בקשת אמון בתיקייה, החלפת המודל עם /model, ושינוי מצב ההרשאות (/auto או Shift+Tab) נכנסים לתוקף לסשן אבל לא נשמרים. כדי לשמור אמון בתיקייה, הריצו grok --trust בתיקייה לפני התחלת ארגז החול. כדי לשנות את מודל ברירת המחדל או את מצב ההרשאות, ערכו את ~/.grok/config.toml ישירות.

grok update מחליף את ההתקנה של Grok ושומר את ערוץ העדכון ב-~/.grok/config.toml. הוא מתחיל בלי הפרופילים האלה כשהם מגיעים מ-GROK_SANDBOX, --sandbox או מהתצורה. הוא מחיל את הפרופיל כשדרישה מגדירה אותו. הוא גם מחיל את הפרופיל כשמשהו כבר כולא את התהליך, כמו פקודה שהסוכן מריץ או קונטיינר שהופעל עם no-new-privileges. תחת הפרופיל הוא לא יכול לשמור את הערוץ. בקונטיינר כזה, grok --sandbox off update עובד אלא אם דרישה מגדירה את הפרופיל.

גם מטמוני החבילות הם לקריאה בלבד, ולכן Grok לא יכול להוריד או לעדכן skills מובנים בזמן שאחד מהפרופילים האלה פעיל. הוא ממשיך להשתמש בעותק שכבר מותקן. בית Grok שרץ תמיד רק תחת הפרופילים האלה אין בו skills מובנים שהורדו. הפעילו את Grok פעם אחת עם --sandbox off כדי להתקין או לעדכן אותם. בהפעלה ראשונה תחת הפרופילים האלה, Grok יוצר תיקיות bundled/ ו-bundles/ ריקות כשהן חסרות. bundled/ או bundles/ שהוא קישור סימבולי נדחה בתחילת ארגז החול (מונע שינוי יעד).

בהפעלה ראשונה תחת הפרופילים האלה, Grok יוצר תיקיית hooks/ אמיתית וריקה וקובץ hooks-paths ריק כשהם חסרים (אף פעם לא קישורים סימבוליים או סוגים שגויים). הגדרות גלובליות של Claude/Cursor לא מכוסות על ידי איסור הכתיבה הזה אלא אם תצורת hook של פרויקט מקשרת אליהן (ראו בהמשך). גילוי של הספקים האלה נשאר מוגבל בנפרד על ידי הגדרות תאימות.

$GROK_HOME שהוא קישור סימבולי, או רשומת hooks-paths עם רכיב של קישור סימבולי, נדחים בתחילת ארגז החול (מונע שינוי יעד). תיקיות האב הקיימות של נתיבים מוגנים נעוצות כדי שלא יהיה אפשר לשנות להן שם מתחת לאיסור (אחים נשארים ניתנים לכתיבה). בלינוקס, מרחבי שמות משתמש מקוננים מושבתים בתוך bubblewrap כדי שלא יהיה אפשר לסדר מחדש קישורי mount. hooks של פרויקט נשארים מותנים באמון בתיקייה. ארגז החול לפי פקודה של דמון סביבת העבודה, שפועל כברירת מחדל ב-Grok Desktop, מונע מפקודה לכתוב לתיקיות .claude, .grok או .cursor שמהן נטענים hooks של פרויקט. זה מכסה את אלה של סביבת העבודה עצמה ואת אלה של כל תיקייה מעליה עד שורש המאגר ש-git מוצא. מחוץ למאגר מוגנות רק אלה של סביבת העבודה עצמה. תיקיות חבילה מתחת לסביבת העבודה עדיין לא מוגנות, כולל עותקים שלהן אצל סוכן משנה של worktree. הפרופילים האלה אוסרים כתיבה רק על קובצי התצורה בתיקיות האלה (ראו בהמשך), כך שפקודה שהם שמים בארגז חול עדיין יכולה להוסיף, להזיז ולשנות קבצים אחרים שם. פרופיל devbox לא מחיל את ההגנה הזאת (מכונות וירטואליות חד פעמיות). פרופילים שדורשים אותה מסרבים להתחיל אם לא ניתן להחיל את מדיניות הליבה (כולל לינוקס בלי עיגוני קריאה בלבד מאומתים).

תחת הפרופילים האלה, כל תצורת hook של פרויקט שקיימת בתחילת ארגז החול גם אסורה לכתיבה בקובץ שאליו היא מפוענחת, כשעוקבים אחרי קישורים. התצורות האלה הן .claude/settings.json, .claude/settings.local.json, .cursor/hooks.json וקבצי ה-hooks ב-.grok/hooks/, בתיקיות שמהן נטענים hooks של פרויקט. לדוגמה, .claude/settings.json שמקושר אל ~/dotfiles/claude.json הופך את ~/dotfiles/claude.json לקריאה בלבד לסשן. בתוך $GROK_HOME יעד נשאר מוחזק רק במקום שבו איסור הכתיבה הגלובלי למעלה מחזיק אותו, או בתיקייה מתחתיו שממנה נטענים hooks של פרויקט. כך סשן באחד מ-worktrees של Grok שומר את התצורות שלו לקריאה בלבד. התחלת ארגז החול נדחית לכל יעד אחר שם, כמו $GROK_HOME/auth.json, כי החזקה שלו הייתה מונעת מ-Grok לשמור את המצב שלו. היא נדחית גם כשל יעד יש קישורים קשיחים אחרים, או כשקובץ תצורה מפוענח לכל דבר שאינו קובץ רגיל (כולל /dev/null). השגיאה מציינת את התצורה. הקישור עצמו נשאר ניתן להחלפה: תצורה שכוונה מחדש במהלך הסשן נטענת בגילוי הבא, כמו תצורה שנוצרה במהלך הסשן. בלינוקס רק תיקיות מחוץ לסביבת העבודה ולתיקיות האב שלה נעוצות עבור הקבצים האלה (~/dotfiles בדוגמה). קבצים עדיין זזים ומקושרים בקישור קשיח בין תיקיות סביבת העבודה לשאר תיקיית הבית שלכם. שינוי שם או קישור קשיח לתוך תיקייה נעוצה או החוצה ממנה נכשלים (mv נופל חזרה להעתקה). בלינוקס תיקיית סביבת עבודה שמחזיקה תצורה או את היעד שלה עדיין יכולה לקבל שינוי שם ולהיות מוחלפת, אלא אם ארגז החול לפי פקודה של הדמון מגן עליה. זה אותו פער כמו תצורה שנוצרה במהלך הסשן. בלינוקס grok שהופעל על ידי פקודה בארגז החול bubblewrap של ה-CLI לא יכול להוסיף עיגונים משלו. הוא מתחיל במקום שבו ארגז החול הזה כבר שומר על תצורות ה-hooks של הפרויקט מפני כתיבה. אחרת הוא מסרב עם שגיאה שמציינת את התצורה ואומרת להפעיל את grok מחוץ לארגז החול. הפעלות מחדש של Grok עצמו בתוך ארגז החול הזה בודקות באותו אופן, כמו מעבר מצב מסך (GROK_SCREEN_MODE_SWITCH=exec) או grok update ברקע. כל אחת מסרבת לתצורה שנוספה או קושרה מחדש במהלך הסשן כשארגז החול משאיר אותה ניתנת לכתיבה, כי פקודה הייתה יכולה לכתוב אותה. עדכון ברקע יוצא אז בלי הודעה.

#פרופילים מותאמים אישית

צור פרופילי ארגז חול מותאמים אישית ב-~/.grok/sandbox.toml (גלובלי) או ב-.grok/sandbox.toml (לכל פרויקט):

[profiles.project]
# Start from a built-in profile, then add overrides
extends = "workspace"
restrict_network = true

# Paths the agent can read but NOT write/delete
read_only = ["/data"]

# Additional writable paths
read_write = ["/tmp/scratch"]

# Paths or globs to kernel-deny (read + write/rename, enforced; see notes below)
# `~/…` is your home; other relative entries are anchored at the workspace
deny = ["/data/shared-secrets", "~/.ssh", "**/.env", "**/*.pem"]

השתמש בפרופיל המותאם אישית:

grok --sandbox project

פרופיל מותאם אישית לא יכול להשתמש בשם של פרופיל מובנה. --sandbox devbox תמיד מריץ את פרופיל devbox המובנה, ומסתיר כל [profiles.devbox] שאתה מגדיר.

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

#שדות פרופיל מותאם אישית

הערה על read_only / read_write: אלה הענקת ספריות מילוליות, לא גלובים. /** נגרר (או /*) מטופל כספריית האב, כך ש-…/cache/** מעניק את …/cache (ו-/** לבדו מעניק את /). כל רשומה שעדיין מכילה *, ? או [ אחרי זה (לדוגמה /home/**/cache, או ספרייה ששמה המילולי dir[1]) מדולגת עם אזהרה: פרט את הספריות הקונקרטיות שאתה צריך, או שים גלובים תחת deny. רשומות עם רווח לבן בהתחלה או בסוף גם מדולגות עם אזהרה: רווח לבן משמעותי בנתיבים מילוליים, לכן תקן את הרשומה במקום להסתמך על קיצוץ.

הערה על deny: רשימת deny לא ריקה נאכפת בקרנל. נתיבים חסומים הם חסומים לקריאה וחסומים לכתיבה/שינוי שם דרך Seatbelt ב-macOS ודרך bind-over של bwrap בלינוקס, כך שנתיב חסום לא ניתן לקריאה (דרך bash, grep או סוכני משנה) ולא ניתן להעברה אל מחוץ לקבוצת ה-deny ולקריאה במקום אחר (מעקף mv secret x && cat x סגור). בלינוקס, חסימת קריאה דורשת bubblewrap: אם הוא חסר (או אם נתיב deny יחיד כלשהו לא ניתן לקישור), גרוק מסרב להתחיל במקום לרוץ כשהנתיבים החסומים חשופים (devbox, שחוסם כתיבה בלבד ל-/data, עדיין נופל חזרה ל-Landlock). כתיבות לנתיבים שאינם ב-deny נשלטות לפי מה שאתה מעניק ב-read_write.

לאן רשומת deny מצביעה: רשומה מוחלטת נלקחת כפי שהיא. רשומה שמתחילה ב-~/, וגם ~ לבדו, מעוגנת בתיקיית הבית שלך, כך ש-deny = ["~/.ssh"] מגן על ~/.ssh האמיתי. כל רשומה יחסית אחרת מעוגנת בסביבת העבודה. ~user אינו מורחב: זו רשומה יחסית רגילה ששמה ספריית ~user בסביבת העבודה, לכן כתוב את הנתיב במלואו עבור הבית של משתמש אחר. במארח שאין לו תיקיית בית, או שנתיב הבית שלו מכיל *, ? או [ או שאינו UTF-8 תקין, רשומת ~ גורמת לגרוק לסרב להתחיל במקום להגן בשקט על הנתיב הלא נכון. חסום ספריית אב בלי התווים האלה. מדיניות לפי פקודה גם מעגנת ~/… בתיקיית הבית שלך. read_only ו-read_write אינם מרחיבים ~. ציין את הספריות האלה במלואן. חסום את הספריות שאליהן התכוונת במקום את הבית עצמו: ~ לבדו מכסה גם את ~/.grok, שהוא התצורה ומצב הסשן של גרוק עצמו.

גלובים ב-deny: רשומה היא גלוב אם היא מכילה *, ? או [. התווים האלה תמיד פירושם גלוב: כדי לחסום קובץ מילולי ששמו מכיל אותם, ציין ספריית אב. תת הקבוצה הנתמכת, בסגנון gitignore, היא:

• *: כל רצף תווים בתוך מקטע נתיב אחד (נעצר ב-/)
• ?: בדיוק תו אחד בתוך מקטע
• **: חוצה ספריות (כמקטע נתיב שלם, לדוגמה **/, a/**). **/ מתאים גם לאפס ספריות, כך ש-**/.env מתאים ל-.env ול-sub/.env
• [abc] / [a-z]: מחלקות תווים. ! מוביל או ^ שוללים ([!a] ו-[^a] שניהם אומרים "לא a")

חילופי סוגריים מסולסלים ({a,b}), בריחות בלוכסן הפוך, מקטעי נתיב ריקים (// כפול או / נגרר), מקטעי . או .., וצורות המחלקה החריגות []…] (] מילולי בהתחלה) ו-POSIX [[:…:]] אינם נתמכים, כך ששתי הפלטפורמות לעולם לא יכולות לפרש גלוב בצורה שונה. גלוב שמשתמש במטא תו לא נתמך, או גלוב פגום, גורם לגרוק לסרב להתחיל (כישלון סגור) בשתי הפלטפורמות: כתוב *.pem ו-*.key כרשומות נפרדות במקום *.{pem,key}.

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

• macOS אטום: כל גלוב הופך לביטוי רגולרי של Seatbelt שמוחל בזמן ריצה, כך שקבצים תואמים נחסמים גם אם נוצרו אחרי שגרוק התחיל.
• לינוקס היא מאמץ מיטבי: מרחב שמות mount לא יכול לבצע גלוב בזמן ריצה, לכן כל גלוב מורחב לקבצים שקיימים בהפעלה ואלה נקשרים מעליהם. קבצים שנוצרים מאוחר יותר ומתאימים לגלוב אינם מכוסים: ציין נתיבים מדויקים לכל דבר שחייב להיות אטום בלינוקס. קישור סמלי תואם ממוסך יחד עם היעד שלו אחרי פענוח. גלוב שמתאים ליותר מדי קבצים, או שהעץ שלו עמוק מדי או רחב מדי לסריקה, גורם לגרוק לסרב להתחיל במקום לאכוף באופן חלקי. השגיאה מציינת את הגלובים ואת הספרייה שבה הסריקה נעצרה. סריקת ההפעלה מתחילה בקידומת המילולית של כל גלוב וכוללת קבצים שמופיעים ב-gitignore וקבצים מוסתרים, לכן בסביבות עבודה גדולות מאוד העדף גלובים מעוגנים (certs/**/*.pem סורק רק את certs/) על פני תבניות ** חשופות.

#איך זה עובד

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

• read_file, search_replace, list_dir: מוגבלים על ידי Landlock/Seatbelt בתוך התהליך
• פקודות bash, grep (rg): תהליכי בן יורשים הגבלות מערכת קבצים אוטומטית
• רשת: בלינוקס, תהליכי בן יכולים להיחסם דרך seccomp. ב-macOS זה no-op

כשפרופיל ארגז חול שאינו off מבוקש (CLI, GROK_SANDBOX, תצורה, או דרישה מנוהלת):

• הסוכן רץ בתוך התהליך, לא דרך ה-leader המשותף, כך שקריאות כלים נשארות בתהליך הזה כשהפרופיל נאכף. אם מצב leader היה מופעל אחרת, הערה של שורה אחת בהפעלה מציינת זאת
• אם פרופיל מובנה נכשל בהחלה, גרוק מזהיר וממשיך בלי אכיפה (ראה תמיכת פלטפורמות), אבל עדיין מסרב ל-leader כדי שהכלים לא יועברו למקום אחר
• grok workspace start, restart ו-resume אינם זמינים. pause, stop ו-status עדיין עובדים

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

ארגז החול בלתי הפיך מרגע שהוחל. הסוכן לא יכול לרכך את ההגבלות בזמן ריצה.

#חידוש סשנים

הפרופיל שבו סשן התחיל נשמר עם הסשן והוא קבוע לכל חיי הסשן. כשאתה מחדש אותו (grok --resume <id>, grok --continue, או grok -r), גרוק משחזר את אותו פרופיל אוטומטית, כך שסשן שהתחיל עם --sandbox workspace לא יחזור בשקט תחת ברירת מחדל מחמירה יותר וישבור פקודות שעבדו קודם.

חידוש לא ישנה את ארגז החול של סשן:

• השמטת --sandbox בחידוש משתמשת בפרופיל השמור של הסשן.
• העברת --sandbox <profile> שתואם לפרופיל השמור מותרת.
• העברת --sandbox <profile> ששונה מהפרופיל השמור נדחית עם שגיאה: שינוי ארגז החול של סשן שמחודשים הוא מלכודת בטיחות (הוא עלול להרחיב גישה שהסשן נועד להיות מוגבל אליה, או לשבור סשן שהסתמך על גישה רחבה יותר). התחל סשן חדש כדי להשתמש בפרופיל אחר.
• אם גרוק לא יכול לשחזר את הפרופיל השמור בעצמו, החידוש נדחה והשגיאה מציינת את פרופיל --sandbox שיש להעביר.
• פרופיל שמוצמד ב-requirements.toml גובר על הפרופיל השמור, לכן תחת הצמדה כל סשן מתחדש עם הפרופיל המוצמד.

סדר פתרון הפרופיל לסשן חדש:

1. דגל מפורש --sandbox <profile> או משתנה הסביבה GROK_SANDBOX
2. [sandbox] profile בתצורה שלך
3. off (בלי ארגז חול)

#תמיכת פלטפורמות

אם לא ניתן להחיל את ארגז החול (לדוגמה, ליבה לא נתמכת, entitlements חסרים), גרוק רושם אזהרה וממשיך בלי אכיפה. היוצא מן הכלל הוא פרופיל מותאם אישית שמבוקש במפורש: בmacOS ובלינוקס, אם לא ניתן להחיל אותו (פרופיל לא מוכר, sandbox.toml פגום, או, בלינוקס, bubblewrap לא זמין עבור deny לא ריק), גרוק מסרב להתחיל במקום לרוץ כשהנתיבים החסומים שלו חשופים.

#מטא נתונים של קבצים בלינוקס

Landlock שולט בתוכן קובץ, ביצירה, במחיקה ובשינויי שם, אבל לא במטא נתונים של קובץ. תחת כל פרופיל, פקודה עדיין יכולה לשנות את סיביות המצב (chmod), חותמות זמן (touch) ותכונות מורחבות (setfattr) של קובץ מחוץ לנתיבי הכתיבה, אם היא הבעלים שלו או אם היא יכולה לכתוב אליו תחת הרשאות Unix רגילות, אף שכתיבה לתוכן הקובץ נדחית. שינוי הבעלים של קובץ פועל לפי כללי Unix הרגילים. תיקיות שגרוק מעגן לקריאה בלבד, כגון תיקיות ההוקים שלמעלה, ונתיבי deny של פרופיל מותאם אישית, שגרוק מכסה בעגינה לקריאה בלבד, אינן מושפעות. ב-macOS, Seatbelt דוחה את השינויים האלה מחוץ לנתיבי הכתיבה.

Landlock מגביל קיטום רק החל מליבה 6.2 (Landlock ABI v3). בליבות 5.13 עד 6.1, כגון Ubuntu 22.04 ו-Debian 12, פקודה יכולה גם לרוקן או לקצר קובץ מחוץ לנתיבי הכתיבה באמצעות truncate אם היא יכולה לכתוב את הקובץ תחת הרשאות Unix רגילות.

"enforced": true ב-sandbox-events.jsonl אומר שכללי הקרנל של הפרופיל הוחלו. בלינוקס זה לא אומר שמטא נתונים של קבצים מחוץ לנתיבי הכתיבה מוגן, ובליבות לפני 6.2 זה לא אומר שהקבצים האלה מוגנים מפני קיטום.

#הגבלות רשת

בלינוקס, פרופילים עם restrict_network חוסמים גישת רשת בתהליכי בן (פקודות bash, סקריפטים) דרך seccomp. ב-macOS, חסימת רשת היא no-op. כלים מובנים שמבצעים בקשות HTTP בתוך התהליך (חיפוש באינטרנט, קריאות API של LLM) אף פעם לא מושפעים, כי הסוכן צריך גישת רשת כדי לתפקד.

בפועל, בלינוקס המשמעות היא:

• web_search, web_fetch ו-API של ה-LLM תמיד יש להם גישת רשת
• פקודות bash כמו curl, wget ו-npm install נחסמות כש-restrict_network מופעל
• הוק HTTP עדיין שולח דרך https://
• גרוק מסרב לכתובת http:// הפשוטה של הוק מחוץ למדיניות מנוהלת

#מדיניות סביבת מעטפת

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

[shell_environment_policy]
inherit = "core"                 # all (default) | core | none
ignore_default_excludes = false  # also drop *KEY* / *SECRET* / *TOKEN*
exclude = ["ACME_*", "CI_*"]     # drop these names
include_only = ["PATH", "HOME"]  # if set, keep only these names
set = { MY_FLAG = "1" }          # force these values

גרוק בונה את סביבת תהליך הבן לפי הסדר: הוא מתחיל מ-inherit (all שומר הכל, core שומר קבוצה קטנה של הפלטפורמה כגון PATH ו-HOME, none מתחיל ריק), משמיט את תבניות הסוד המובנות *KEY*, *SECRET* ו-*TOKEN* אלא אם ignore_default_excludes = true, משמיט כל התאמה של exclude, מחיל את set, וכאשר include_only אינו ריק, שומר רק את השמות התואמים. התבניות הן גלובים שאינם תלויי רישיות (*, ?).

ברירת המחדל (inherit = "all", ignore_default_excludes = true) משאירה את הסביבה ללא שינוי, כך ששום דבר לא משתנה עד שאתה מגדיר מדיניות. טבלה עם ערך שלא מתפרס, כגון inherit = "most", עוצרת את גרוק בהפעלה עם שגיאת הפענוח. בבקאנד הלא מתמיד המדיניות גם מסננת משתנים שנלכדו ממעטפת ההתחברות שלך, כך שייצוא מקובץ .rc לא יכול להעביר סוד מעבר ל-exclude או ל-include_only. המעטפת המתמידה היא חריג אחד: היא מחילה את המדיניות על סביבת הבסיס שלה, אבל משתנים שקובץ .rc מייצא במהלך ההתחברות משוחזרים מצילום מצב ואינם מסוננים שוב, לכן השאר סודות מחוץ לקבצי הפעלת המעטפת שם. האכיפה מכסה את כלי bash ואת הטרמינלים ב-macOS, בלינוקס ו-Windows.

#רישום אירועים

אירועי ארגז חול נרשמים ב-~/.grok/sessions לצורך ניפוי שגיאות. האירועים כוללים:

• פרופיל שהוחל (איזה פרופיל, חותמת זמן)
• הפרות (ניסיון גישה לנתיבים חסומים)

#מתי להשתמש במצב ארגז חול

השתמש ב-workspace כאשר:

• עובדים על הפרויקטים שלך ורוצים הגנת כתיבה בסיסית
• רצים בסביבות משותפות שבהן רוצים להגביל את היקף השינויים

הגדר פרופיל מותאם אישית עם רשימת deny כאשר:

• צריך לחסום קבצים מסוימים (לדוגמה .env או נתיבי אישורים) מעל פרופיל בסיס
• צריך אכיפת קרנל שמכסה bash, grep וסוכני משנה, לא רק את כלי read_file

השתמש ב-read-only כאשר:

• סוקרים קוד שאינך סומך עליו
• חוקרים בסיס קוד בלי סיכון לשינוי מקרי
• מריצים ניתוח קוד או ביקורות

השתמש ב-strict כאשר:

• מנתחים קוד לא מהימן או של צד שלישי
• רצים בסביבות רגישות לאבטחה
• רוצים בידוד מרבי

דלג על ארגז חול כאשר:

• הסוכן צריך להתקין תלויות (npm install, pip install)
• הסוכן צריך לשנות קבצים מחוץ לתיקיית העבודה
• אתה עובד בסביבה מהימנה ורוצה גמישות מרבית

#פשרות

ארגז החול אוכף גבולות ברמת מערכת ההפעלה, דרך Landlock או מרחב שמות mount בלינוקס, ודרך Seatbelt ב-macOS, ולא דרך VM נפרד.