📘 תיעוד 46

הרשאות ובטיחות

שליטה במה שגרוק יכול לגשת אליו ולעשות: מצבי הרשאה, כללי allow/ask/deny, hooks, וארגז החול האופציונלי ברמת מערכת ההפעלה.

• מצבים קובעים באיזו תדירות גרוק מבקש אישור (always-approve, auto, ask, ומצבים קשורים).
• כללים קובעים אילו כלים מותרים, נשאלים, או חסומים בתוך קו הבסיס הזה.

#מצבי הרשאה

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

מצבים קובעים קו בסיס. כללי allow, ask ו-deny בכללים עדיין חלים מעל כל מצב. עבור הסוכן הראשי, מצב plan הוא החריג לעריכות. הרצה headless של --permission-mode plan מחזיקה את plan ומסרבת לכל עריכה חוץ מקובץ התוכנית, במסלול ה-native ובמסלול ה-daemon, גם כשכלל allow מכסה את הכתיבה. מצב plan אינטראקטיבי (בלי hold) מתיר רק את קובץ התוכנית בערכת הכלים grok, וכל קובץ markdown בערכת הכלים של התאימות (כלי ה-write ו-string-replace שלה) ובמסלול ה-daemon. מעטפת וכלים אחרים עדיין רצים אחרי אישור. תת-סוכן שהופעל עם Task עוקב אחרי כללי ה-allow. במסלול ה-native הכלי workflow אינו מגודר במצב plan. מסלול ה-daemon מסרב ל-workflow ב-Plan.

#נקודות התחלה

grok -p "Run the tests" --always-approve
grok agent --always-approve stdio
grok agent --always-approve serve --bind 127.0.0.1:2419 --secret <token>

לקוחות ACP יכולים להגדיר "_meta": { "yoloMode": true } ב-session/new. ראו מצב סוכן.

#מצבים זמינים

--permission-mode plan מתחיל סשן במצב plan. הסעיף הזה מפרט אילו הפעלות נכנסות למצב plan ואילו נשארות בחוץ. הגדרת defaultMode של plan מתקבלת. היא לא נכנסת למצב plan.

Always-approve הוא שם המוצר; תצורה והגדרות תואמות Claude עשויות להשתמש ב-bypassPermissions לאותו מצב. Always-approve ו-auto סותרים זה את זה (always-approve גובר כששניהם מתבקשים).

#איך מגדירים את המצב

TUI אינטראקטיבי: Shift+Tab / Ctrl+O, /always-approve או /auto, או /settings (קיצורי דרך, פקודות).

CLI:

grok --always-approve -p "Run the test suite"
grok --permission-mode auto
grok agent --always-approve serve --bind 127.0.0.1:2419 --secret <token>

תצורה:

[ui]
permission_mode = "always-approve"   # or "auto", "ask", …

גם defaultMode תואם Claude ב-.claude/settings.json נתמך (ראו הגדרות תואמות Claude). ה-CLI דורס את התצורה עבור התהליך הזה.

#Always-approve

מדלג על בקשות הרשאה רגילות כך שכלים רצים בלי להמתין ללחיצה. כללי deny, hooks, וחלק מכללי ask של המעטפת עדיין חלים. מנהלים יכולים לנעול את המצב ככבוי (להלן).

#Always-approve עם מגבלות קשיחות

השאירו always-approve לאוטומציה, והוסיפו כללי deny לנתיבים או לפקודות שלעולם לא תרצו שירוצו:

# project .grok/config.toml
[ui]
permission_mode = "always-approve"

[permission]
deny = [
  "Bash(rm -rf *)",
  "MCPTool(sales__delete_*)",
]

grok -p "Deploy the service" --always-approve --deny 'Bash(rm -rf *)'

Deny תמיד גובר על allow ועל המעבר הרגיל של always-approve. ראו הגדרת הרשאות.

#מצב סקירה אוטומטית

permission_mode = "auto", /auto, או Shift+Tab. מצמצם בקשות אינטראקטיביות על ידי בדיקת קריאות כלים רבות לפני שהן רצות. עבודה מקומית שגרתית לרוב ממשיכה. טיוטת משוב שהסוכן שומר עם send_feedback נשמרת בלי בקשה, כי היא נשארת במחשב שלכם עד שתשלחו אותה מ-/feedback; כלל deny או ask עבור send_feedback עדיין חל. קריאה שהמסווג לא יאשר אוטומטית מציגה בקשת הרשאה כדי שתוכלו לאשר או לדחות אותה; עבור פקודת מעטפת, הבקשה אומרת שסקירה אוטומטית חסמה אותה או לא יכלה לסקור אותה, ו-Ctrl+F מציג את הסבר הסוקר. בסשנים לא אינטראקטיביים (grok -p, stdio לא מזוהה), אותה קריאה נכשלת ומדווחת למודל (לדוגמה Auto mode blocked this action …).

לאוטומציה שחייבת להריץ כלים בלי אישור אינטראקטיבי, השתמשו ב-always-approve (ובכללי deny אם צריך חסימות קשיחות) ולא בסקירה אוטומטית לבדה. כשמוגדרים כללי Bash מסוג deny או ask, או כללי Read או Edit מסוג deny, סשן לא אינטראקטיבי מסרב לפקודת מעטפת שגרוק לא יכול לבדוק מולם במקום להמתין לאישור, גם תחת always-approve. תחת סקירה אוטומטית המסווג עדיין מחליט קודם, ורק פקודה שהוא היה שולח לאישור נדחית (ראו כללי Bash).

#השבתת always-approve (מנהלים)

ארגונים יכולים למנוע הפעלה של always-approve דרך CLI, TUI, או /always-approve. הגדירו זאת ב-requirements.toml (ברמת המשתמש תחת ~/.grok/, או בכל המערכת תחת /etc/grok/ לאכיפה שמשתמשים לא יכולים להסיר):

[ui]
disable_bypass_permissions_mode = true

אל תשתמשו ב-permission_mode למנעול הזה; המפתח הזה הוא ברירת מחדל שניתן להחליף. המפתח הישן [ui] yolo = false ב-requirements.toml גם משבית את always-approve לצורך תאימות.

גרוק עדיין יכול לטעון כללי הרשאה בסגנון Claude מהגדרות מנוהלות; always-approve נעול עם requirements.toml כפי שמוצג למעלה.

#איך מאושרת קריאת כלי

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

1. hooks של PreToolUse. hook יכול לסרב לקריאת כלי לפני כל בדיקה אחרת. hook שמתיר קריאה לא מדלג על הבדיקות שלמטה; הוא רק נמנע מלסרב. ראו 10-hooks.md.

2. כללי הרשאה (מקבצי תצורה או מדגלי --allow/--deny)

   • כלל deny תואם דוחה את הקריאה. deny גובר על כל כלל אחר.
   • כלל ask תואם מבקש מכם אישור, כולל לקריאות קבצים, חיפושים, ופקודות מעטפת שאחרת היו מאושרות אוטומטית. במסלול ה-native, חיפוש בתיקייה עם grep של ערכת הכלים grok משמיט את הקבצים שתבנית הנתיב של כלל ask של Read או Grep מכסה, במקום לבקש אישור (ראו כללי Read, Edit ו-Grep).
   • כלל allow תואם מאשר את הקריאה. עבור הסוכן הראשי, hold של plan ב-headless לא מאשר עריכה שאינה קובץ התוכנית. מצב plan אינטראקטיבי לא מאשר עריכה שאינה markdown, ובערכת הכלים grok הוא גם מסרב ל-markdown שאינו קובץ התוכנית.

3. היתרים שנשמרו. אישורים לפי פקודה ששמרתם מבקשות קודמות חלים כאן, בתחום הפרויקט הנוכחי. היתר קיים יכול לספק כלל ask במקום לבקש שוב. פקודות ברשימה המסוכנת מבקשות שוב במקום להשתמש בקידומת שנשמרה. ראו אישורים אינטראקטיביים.

4. אישורים אוטומטיים מובנים. כלים לקריאה בלבד וקבוצה קבועה של פקודות מעטפת לקריאה בלבד, ועוד mkdir ו-touch חשופים, רצים בלי בקשה (ראו פקודות מעטפת לקריאה בלבד).

5. מדיניות בקשות (נקבעת על ידי מצב ההרשאה): לבקש מכם, לאשר אוטומטית, או לסרב אוטומטית לקריאה.

Always-approve מקצר את הצינור הזה אחרי שלב 2: כללי deny, hooks, וכללי ask שתואמים למקטעים של פקודת מעטפת עדיין חלים, אבל היתרים שנשמרו (כולל רשומות "never allow" שנשמרו) לא נבדקים, וכללי ask על כלים שאינם מעטפת לא מבקשים אישור.

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

הפעולות למטה נחשבות לקריאה בלבד ורצות בלי בקשה, בכל מצב כולל dontAsk, אלא אם כלל deny תואם או hook חוסם אותן. כלל ask כופה בקשה לקריאות קבצים, חיפושים, ופקודות מעטפת (ראו איך מאושרת קריאת כלי), חוץ מזה שבמסלול ה-native חיפוש בתיקייה עם grep של ערכת הכלים grok משמיט את הקבצים שתבנית הנתיב של כלל ask של Read או Grep מכסה במקום זאת (ראו כללי Read, Edit ו-Grep).

#כלים לקריאה בלבד

• read_file
• list_dir
• grep (חיפוש תוכן)
• web_search
• todo_write
• get_command_or_subagent_output / kill_command_or_subagent (שליטה בתת-סוכן)
• הפעלת skills

#פקודות מעטפת לקריאה בלבד

אחרי פיצול פקודות משורשרות (על &&, ||, ;, וצינורות), הפקודות הבאות מזוהות כקריאה בלבד כשהן מופיעות כפקודה הראשית. הרשימה הזו מותאמת לפי גבול מילה, כך ש-ls לא תואם ל-lsof או ל-less. (כללי Bash(...) שלכם מותאמים אחרת; ראו מדריך התאמת כללים.)

מערכת קבצים (צפייה לקריאה בלבד):

• ls, cat, pwd, date, whoami, hostname, uptime, ps
• head, tail, wc, sort, uniq, tr, cut

יצירת קובץ ריק ותיקייה:

• mkdir, touch, עם כל דגל (הם לא כותבים תוכן קובץ, ולכן מטופלים כמו הפקודות לקריאה בלבד, אף שדגלים עדיין יכולים לקבוע סיביות הרשאה וחותמות זמן; יעד מוגן כמו ~/.ssh או .git/hooks לא מאושר אוטומטית: הוא מבקש אישור במצב default ונדחה תחת dontAsk). גרוק לא עוקב אחרי שינויי תיקייה, אז אחרי cd, pushd, או popd גם יעד יחסי לא מאושר אוטומטית; cd פשוט לתיקיית העבודה של הסשן, כתוב כנתיב המלא שלו ורץ כצעד הראשון של הפקודה, לא נספר (חוץ מ-Windows).

Git (קריאה בלבד):

• git status, git branch, git log, git diff, git ls-files, git show, git rev-parse
• git blame, git describe, git merge-base, git shortlog
• git check-ignore, git check-attr, git cat-file, git ls-tree, git show-ref, git for-each-ref, git rev-list, git name-rev, git count-objects

חיפוש ובדיקה:

• grep, rg (לא rg --pre / rg --pre=…, שמפעילים מעבד מקדים לכל קובץ)

Kubernetes (קריאה בלבד):

• kubectl get, kubectl logs, kubectl describe

הערה: tee לא ברשימה הזו כי הוא יכול לכתוב את הקלט שלו לקבצים שרירותיים. cargo check לא ברשימה הזו כי הוא מהדר ומריץ build.rs, proc-macros, וכל build.rustc-wrapper מהמאגר (במצב Ask הוא לכן מבקש אישור; מצב Auto עדיין עשוי לאשר היוריסטית את cargo כמריץ קוד של הפרויקט). sort --compress-program=… (כולל קיצורים ייחודיים של אפשרות ארוכה), דריסות git -c / --config-env, ופקודת git שהתצורה המקומית או של worktree שלה מתקינה hook בר הרצה (core.fsmonitor, מנהל התקן diff.*.command/textconv/external, או alias.<safe-subcommand> = !… של מעטפת) מעלים רצפה ברמת הבקשה ומבקשים אישור במקום לאשר אוטומטית, אלא אם המשתמש העניק את הסקריפט המלא המדויק הזה או ש-always-approve מופעל.

הבדיקות האלה חלות לכל מקטע. בפקודה כמו ls && rm -rf /, מקטע ה-ls מזוהה כקריאה בלבד, אבל מקטע ה-rm לא ברשימה. במצב default מקטע ה-rm מבקש אישור; תחת dontAsk הוא נדחה.

#הגדרת הרשאות

Grok קורא כללי הרשאה משלושה מקורות תואמים. כללים מכל המקורות ממוזגים לקבוצה אחת. ההשפעה של כלל תלויה בפעולה שלו (deny > ask > allow), לא בקובץ שממנו הוא הגיע.

#היכן כללי ההרשאה נמצאים (היקפים)

כללי הרשאה יכולים להיות גלובליים (כל הפרויקטים), בהיקף פרויקט (מאגר אחד), או אישיים עבורך בתוך פרויקט:

הערות על היקף:

• Grok מגלה .grok/config.toml בכל רמת תיקייה משורש המאגר ועד תיקיית העבודה, כך שתת-תיקייה יכולה להוסיף כללים מעל הכללים של שורש המאגר.
• כללים מכל ההיקפים ממוזגים לקבוצת כללים אחת. deny > ask > allow חל על פני ההיקפים, ולכן deny גלובלי אינו ניתן לעקיפה על ידי allow של פרויקט.
• ל-Grok אין config.local.toml מקורי. לכללים אישיים שלא נשמרו ב-commit בפרויקט, השתמשו ב-.claude/settings.local.json. Grok קורא אותו ישירות (ראו תאימות ל-Claude Code).
• ל-worktree ייתכן שאין עותק של הקובץ המתעלם הזה, ולכן worktree מחיל גם את כללי ה-deny וה-ask של הקובץ ב-checkout הראשי בכל רמת תיקייה מתיקיית העבודה ועד שורש ה-worktree, תחת אותו שער אמון תיקייה כמו כללי הפרויקט שלו. כללי ה-allow ו-defaultMode בקובץ של ה-checkout הראשי אינם חלים ב-worktrees שלו, אם כי תשובות "always allow" השמורות של ה-checkout הראשי כן חלות (ראו ההתמדה היא לפי פרויקט).
• תיקייה שנוספה עם --add-dir מחילה גם את כללי ה-deny וה-ask שהיא פותרת בעצמה, כולל קובצי הפרויקט שלה, על הנתיבים שתחתיה. הכללים שלה לפקודות, לכלי MCP ולכתובות URL חלים על כל הסשן. כללי ה-allow ו-defaultMode שלה אינם חלים, ולכן תיקייה שנוספה יכולה רק להפוך את הסשן למחמיר יותר.
• החלטות אינטראקטיביות של "Always allow" נשמרות מחוץ למאגר, בהיקף של הפרויקט (ראו אישורים אינטראקטיביים).

כדי להפסיק בקשות אישור לפקודה מסוימת בפרויקט אחד, הוסיפו כלל allow מצומצם לקובץ .grok/config.toml של אותו פרויקט (או ל-.claude/settings.json):

[permission]
allow = ["Bash(cargo test *)", "Bash(npm run build)"]

זה מאשר רק את הפקודות שברשימה. מצב always-approve מאשר את כל קריאות הכלים.

#1. דגלי CLI

grok -p "Review the API changes" \
  --allow 'Bash(git *)' \
  --allow 'Bash(gh *)' \
  --allow 'Read' \
  --allow 'Grep' \
  --deny 'Bash(rm -rf *)'

אפשר לחזור על --allow RULE ועל --deny RULE, והם תמיד נאכפים.

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

• Bash(git *): כל פקודה שמתחילה ב-git
• Bash(npm run build): פקודה מדויקת (או קידומת)
• Bash(git commit:*): צורת הסיומת cmd:*, שקולה להתאמת קידומת על git commit
• Read(src/**): גישת קריאה תחת src/
• Edit(**/*.rs): עריכת כל קובץ Rust
• Grep: כל פעולות grep
• MCPTool(my-server__*): כלי MCP משרת מסוים

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

#2. הגדרה מקורית (~/.grok/config.toml ו-.grok/config.toml)

[permission]
rules = [
  { action = "allow", tool = "bash", pattern = "git *" },
  { action = "allow", tool = "bash", pattern = "gh *" },
  { action = "allow", tool = "read" },
  { action = "allow", tool = "grep" },
  { action = "deny",  tool = "bash", pattern = "rm -rf *" },  # block a dangerous pattern
  { action = "ask",   tool = "edit" },
]

שדה tool המובנה מקבל את השמות באותיות קטנות bash, read, edit, grep, mcp, webfetch ו-websearch, בהתאם למחלקות הכלים ב-שמות כלים.

מכיוון ש-deny תמיד מנצח, אי אפשר לשלב את כללי ה-allow האלה עם deny כולל על bash כדי להתכוון ל-"only allow git/gh". כלל deny tool = "bash" יחסום גם את git וגם את gh. ל-deny כברירת מחדל, השתמשו ב-defaultMode: "dontAsk" בקובץ .claude/settings.json או ב-hook מסוג PreToolUse (בהמשך).

כללים מהקובץ הגלובלי ~/.grok/config.toml ומכל קובץ פרויקט .grok/config.toml (משורש המאגר ועד תיקיית העבודה) ממוזגים לקבוצת כללים אחת, יחד עם כל כללי .claude/settings.json.

הגדרה מנוהלת שפרס הארגון תורמת גם היא כללי [permission]: קובץ המערכת /etc/grok/managed_config.toml, ועותק ברמת המשתמש ש-Grok מתחזק אוטומטית ב-~/.grok/managed_config.toml. כללים מנוהלים מתמזגים כמו כללים מכל מקור אחר, עם שתי תכונות ייחודיות לכללי allow מנוהלים: כללי deny ו-ask שלכם מנצחים allow מנוהל (סדר חומרה), ו-allow מנוהל כולל מתעלמים ממנו כאשר always-approve נעול כבוי. לכללים שמשתמשים אינם יכולים לערוך ולהסיר, השתמשו בקובץ המערכת בבעלות root /etc/grok/requirements.toml.

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

מקטע [permission] המקורי מקבל גם את הצורה הקומפקטית של מערכי מחרוזות allow / deny / ask, עם אותן מחרוזות כללים כמו בדגלי --allow / --deny ובקובץ .claude/settings.json:

[permission]
deny = [
  "Read(/Users/you/private/**)",
  "Edit(/Users/you/private/**)",
  "Bash(rm -rf *)",
]
allow = [
  "Bash(git *)",
  "Bash(gh *)",
]

deny תמיד מנצח את allow (ההערכה היא deny > ask > allow), ללא תלות בסדר או במקור. כדי לחסום קריאות של נתיבים מחוץ לפרויקט גם ברמת מערכת ההפעלה, שלבו כללי deny עם פרופיל ארגז החול strict (ראו 18-sandbox.md).

#3. תאימות ל-Claude Code (.claude/settings.json)

Grok קורא את ~/.claude/settings.json ואת ~/.claude/settings.local.json, ובנוסף את <project>/.claude/settings.json ואת settings.local.json ברמת הפרויקט (בעלייה עד שורש המאגר). ב-worktree (git worktree או אחד מה-worktrees העצמאיים של Grok), Grok קורא גם את כללי ה-deny וה-ask של settings.local.json ב-checkout הראשי באותן רמות תיקייה (ראו היכן כללי ההרשאה נמצאים). המקור המקורי של .grok לכללי הרשאה הוא config.toml, שמתואר במקטע למעלה.

דוגמה:

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Read",
      "Grep",
      "Bash(git *)",
      "Bash(gh *)"
    ],
    "deny": [
      "Bash(rm -rf *)"
    ]
  }
}

ערכי defaultMode הנתמכים כוללים את default, auto, acceptEdits, bypassPermissions, dontAsk ו-plan. Grok קורא את defaultMode מהמיקום הקנוני שלו תחת permissions. defaultMode ברמה העליונה מתקבל גם כאשר המפתח המקונן חסר.

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

• כללים לכלי MCP יכולים להשתמש בצורה mcp__server__tool שנמצאת בקובצי .claude/settings.json או בצורה המקורית MCPTool(server__tool) (ראו כללי MCP).
• כללים שנותנים שם לכלי לא מוכר, וכללי פרמטרים כמו Agent(model:opus), מדולגים עם אזהרה במקום לכשל את הטעינה.
• ערך permissions.allow, deny או ask שאינו רשימה מדולג עם אזהרה. שאר הרשימות עדיין נטענות.
• רשומת רשימה שאינה מחרוזת מדולגת לבדה.
• קובץ ההגדרות המנוהל של Claude (/etc/claude-code/managed-settings.json ב-Linux, /Library/Application Support/ClaudeCode/managed-settings.json ב-macOS) נקרא באותו אופן, פרט לכך שערך deny או ask שאינו רשימה, או רשומה שאינה מחרוזת באחד מהם, גם מונע את טעינת רשימת ה-allow של אותו קובץ. כלל deny או ask שנכשל בפענוח מדולג לבדו. grok inspect מציג מה דולג מהקובץ הזה ולמה, פרט ל-defaultMode שאינו מחרוזת, והוא רק נרשם ללוג.
• permissions.additionalDirectories מפוענח אך אינו נתמך.

אפשר לייבא הגדרות Claude קיימות באופן אינטראקטיבי עם Ctrl+I ("Import Claude settings").

#הפניה להתאמת כללים

הסעיף הזה מגדיר בדיוק איך כללים מותאמים.

#כללי Bash

תבנית Bash(...) מתאימה לפקודה (כל מקטע בשרשרת, עבור כללי allow. ראה "פקודות משורשרות" למטה) באחת משתי דרכים:

• קידומת: הפקודה מתחילה בטקסט התבנית, בהשוואה תו אחר תו. אין דרישת גבול מילה, ולכן Bash(git) מתאים גם ל-gitleaks וגם ל-git status. כלול רווח בסוף ותו כללי (Bash(git *)) כדי לדרוש שהקידומת תהיה מילה שלמה.
• Glob: התבנית מתאימה לפקודה כולה (או למקטע כולו) כ-glob. * יכול להופיע בכל מיקום ומתאים לכל תווים, כולל רווחים ולוכסנים, ולכן Bash(git * main) מתאים ל-git checkout main. גם ? ו-[...] נתמכים.

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

סיומת :* בסוף כלל Bash מוסרת לקידומת רגילה: Bash(git commit:*) הופך לקידומת git commit. מכיוון שלקידומות אין גבול מילה, deny שנכתב כ-Bash(sed:*) חוסם גם פקודות כמו sed-custom.

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

• כללי deny ו-ask נבדקים מול כל מקטע, ומול המחרוזת כולה. מקטע אחד שנדחה דוחה את הפקודה כולה.
• כללי allow הם מצרפיים: הפקודה מאושרת אוטומטית על ידי כלל רק כאשר כל מקטע מתאים באופן עצמאי לכלל allow. Bash(git *) מאשר את git status && git diff, אבל לא את git status && rm -rf /. מקטע ה-rm לא מתאים לאף כלל allow, ולכן הפקודה עוברת לטיפול הרגיל של המצב (הנחיה במצב default. המסווג במצב auto, שעדיין יכול לאשר או לחסום אותה. דחייה תחת dontAsk). כלל allow יחיד לכן לעולם לא יכול לאשר שרשרת שמכניסה פנימה פקודה לא קשורה.

כללי allow אינם רשימת היתר סגורה. פקודה שלא מתאימה לאף כלל allow לא נדחית משום כך: היא עוברת למצב. במצב auto המסווג יכול לאשר פקודות שהכללים שלך לא מזכירים. למדיניות של דחייה כברירת מחדל, השתמש ב-dontAsk (או ב-always-approve יחד עם כללי deny לחסימות קשיחות), כפי שמתואר תחת הגדרת הרשאות.

פקודות שלא ניתן לפצל למקטעים פשוטים (תת-shell, החלפת פקודה $(...), backticks, רקע &, זרימת בקרה) מוצגות כהנחיה כיחידה אחת כאשר מוגדרות הגבלות Bash. בסשן לא אינטראקטיבי כמו grok -p, אף אחד לא יכול לענות להנחיה הזו, ולכן הפקודה נדחית והמודל מתבקש לכתוב אותה מחדש. אותו דבר חל כאשר קיימים כללי deny של Read או Edit וגרוק לא יכול לדעת לאילו קבצים פקודה נוגעת, לדוגמה rg רקורסיבי או grep -r. כלל ask תואם, או hook ששואל על פקודה שגרוק יכול לבדוק, עדיין מציג הנחיה וממתין עד שמנגנון הגיבוי של 600 השניות דוחה אותה.

כל מקטע מנורמל לפני התאמת הכללים. הקצאות סביבה מובילות כמו RUST_LOG=debug מוסרות, וקבוצה קבועה של עטיפות (timeout, nice, ionice, chrt, stdbuf, env) מוסרת, כך שהכללים מתאימים לפקודה הפנימית: Bash(npm test *) מאשר את RUST_LOG=debug timeout 30 npm test --workers=4. זה חל על כללי deny, ask ו-allow, על הרשאות שנשמרו, ועל רשימת הפקודות לקריאה בלבד.

עוד כמה פרטי התאמה:

• כללים חלים גם בתוך סקריפט מילולי שמועבר ל-bash -c. עבור allow, כל פקודה בתוך הסקריפט הזה חייבת להיות מותרת בעצמה.
• עטיפות שלא ברשימה (sudo, xargs, nohup, …) לא מוסרות. כתוב כללים שמציינים אותן במפורש.
• כאשר המנתח לא יכול להסיר צורה בבטחה (לדוגמה env -S), הפקודה מציגה הנחיה במקום להתאים לכלל allow.
• ההתאמה רואה מילים מילוליות מנותחות שמחוברות ברווחים בודדים, בלי מרכאות של ה-shell. משתני שם קובץ ששוחזרו שומרים על האיות שנכתב. ערכים אף פעם לא מורחבים לצורך התאמת כללים.
• כלל allow יכול לכסות משתנה של שם קובץ במרכאות כאשר הוא אופרנד קובץ של ls או rg שבא אחרי --, נושא קידומת מילולית / או ./, או הוקצה לו נתיב מילולי מוקדם יותר באותו סקריפט. echo, head ו-tail יכולים להופיע לצד זה עם ארגומנטים מילוליים בלבד, ואפשרויות דינמיות, כתיבות, תוכניות אחרות והגבלות Read/Edit עדיין מציגות הנחיה. המשתנה שומר על האיות שנכתב, כולל מרכאות (rg -n ERROR "$LOG"), ולכן התאם אותו עם *. גם Ask וגם Auto מכבדים allow מכסה כזה (והרשאה שמורה מדויקת עבור הסקריפט כולו) בלי המסווג. סקריפטים אחרים עם ארגומנטים משתנים הולכים למסווג ב-Auto.

#פקודות מסוכנות

רשימה מובנית (rm, chmod, chown, chgrp, chattr, pkill, kill, killall, git push) מציגה הנחיה גם כאשר מקטע מכוסה על ידי קידומת פקודה שנשמרה או על ידי רשימת הפקודות לקריאה בלבד. כלל allow מפורש בתצורה כן מאשר אותן, ומצב always-approve מאשר אותן אוטומטית כמו כל פקודה אחרת. השתמש בכללי deny כדי לחסום אותן ללא תנאי. בדוק כללים כמו Bash(rm *) בזהירות לפני שמוסיפים אותם ככללי allow.

#כללי Read, Edit ו-Grep

תבניות נתיב הן globs שמותאמים לנתיב הכלי אחרי נרמול לקסיקלי (./.. מכווצים. נתיבים יחסיים מצורפים לתיקיית העבודה של הסשן). נתיב כלי עם קידומת ~ מותאם באופן מילולי, בלי צירוף לתיקיית העבודה, כי הכלים מרחיבים את ~ לתיקיית הבית רק אחרי בדיקת ההרשאה:

• * ו-? לא חוצים /. ** כן. Read(src/*) מתאים ל-src/main.rs אבל לא ל-src/nested/mod.rs. השתמש ב-Read(src/**) עבור העץ כולו.
• שם קובץ חשוף מתאים רק למחרוזת המדויקת הזו. השתמש ב-**/.env כדי להתאים ל-.env בכל עומק.
• // מוביל בתבנית מטופל כטקסט glob מילולי. ~/ מוביל מציין את תיקיית הבית שלך: Read(~/.ssh/**) מתאים לקבצים תחתיה בין אם נתיב הכלי מאיית אותם עם ~/ או במלואו. כתוב תבניות של נתיב מוחלט, ~/ או **/ במקום תבניות //.
• מכיוון ש-./.. מכווצים לפני ההתאמה, אי אפשר לברוח מתבניות מושרשות באמצעות מעבר: Read(./**) מגביל לתיקיית העבודה (יחסיים חשופים כמו src/main.rs מתאימים. ./../../etc/passwd לא), ו-Read(src/**) נשאר תחת src/. תבניות לא מושרשות (*, או ** מוביל כמו ב-**/*.rs) מתאימות בכוונה בכל עומק, בכל מקום.
• כללי Read חלים גם על חיפושי grep. כללי Grep(...) מתאימים רק ל-grep.
• במסלול הנייטיב, חיפוש תיקייה עם grep של ערכת הכלים של grok משמיט את הקבצים שתבנית הנתיב של כלל ask של Read או Grep מכסה, במקום לשאול. כלל בלי תבנית נתיב, כמו Grep, Read או Read(*), שואל לפני כל חיפוש. חיפוש של נתיב שכלל ask מתאים אליו שואל קודם, ואחרי שאתה מאשר, הוא גם מחפש את הקבצים שהכלל מכסה שם. Read(secrets/**) מתאים ל-secrets/app אבל לא ל-secrets, ולכן חיפוש של secrets עצמו לא שואל ולא מוצא כלום תחתיו, ותחת כלל שמכסה כל נתיב, כמו Read(**), חיפוש בלי נתיב לא מוצא כלום. תחת always-approve, כללי ask לא משמיטים כלום. כללי deny עדיין כן. במסלול ה-daemon, ועם grep של ערכת הכלים לתאימות, חיפוש תיקייה עדיין קורא את הקבצים שתבנית הנתיב של כלל ask מכסה.
• חיפוש התיקייה קורא כל תבנית ask כמו שהכלל קורא: חשוף ועם ./ מתיקיית העבודה, ונגד הנתיבים המוחלטים ו-~/ של תיקיית העבודה, ולכן /home/**/.env ו-~/proj/secrets/** משמיטים קבצים גם כן. ארבעה מקרים עדיין מחזירים קבצים שקריאה הייתה שואלת עליהם: חיפוש של תיקייה מחוץ לתיקיית העבודה, תחת תבנית שלא מתחילה ב-** או /** ומתאימה לנתיב המוחלט או ל-~/ של התיקייה הזו, כמו /srv/data/** או ~/.ssh/**. חיפוש שהנתיב שלו עובר דרך symlink, או תחת תבנית שנכתבה לתיקייה שהקישור מוביל אליה או עם .. שיוצא מהקישור שוב. כאשר תיקיית העבודה עצמה מושגת דרך symlink, או שחיפוש מאיית את נתיב תיקיית העבודה באותיות אחרות במערכת קבצים שמתעלמת מאותיות, כמו ש-macOS ו-Windows עושים כברירת מחדל, כל תבנית שלא מתחילה ב-** או /**. וכן, ב-Linux וב-macOS, בתיקייה ליד תיקיית העבודה שהשם שלה מתחיל בשם של תיקיית העבודה, כמו app-secrets ליד app, תבנית שמציינת את התיקייה הזו, כמו **/app-secrets/**. חלק מהחיפושים משמיטים יותר ממה שהכללים מכסים: תבנית שמתאימה לתיקייה, כמו src/* או **/.env, משמיטה גם את כל מה שבתוכה. ?, [!...], או [...] עם טווח מעבר ל-ASCII יכולים לייצג עד ארבעה תווים. וחיפוש של תיקייה מעל תיקיית העבודה יכול גם להשמיט קבצים תואמים ליד תיקיית העבודה, כמו קבצים ב-proj-old ליד proj.
• בדיקות נייטיב של Read/Edit/Grep עוקבות אחרי symlinks בתוך הנתיב עבור deny ו-ask על היעד שנפתר. allow שמתאים רק ליעד שנפתר לא מעניק allow לארגומנט הכלי.
• symlink בתוך הנתיב שלא ניתן לפתור מציג הנחיה כאשר כל כלל קובץ deny או ask חל על הכלי הזה.

כללי deny של Read ו-Edit חלים בנוסף על נתיבי קבצים שפקודות shell נוגעות בהם (לדוגמה cat או sed על נתיב שנדחה), כולל סקריפטים מוטמעים מילוליים שמועברים ל-bash, sh, dash, zsh או ksh עם -c. הבדיקה ברמת ה-shell משתמשת באותו נרמול שמודע לתיקיית העבודה ובאותו מעקב אחרי symlink עבור deny/ask כמו כלי Read/Edit/Grep הישירים שתוארו למעלה (אופרנד מוחלט תחת תיקיית העבודה מתאים גם לכללים מושרשים כמו Read(src/**)). לאכיפה ברמת מערכת ההפעלה שמכסה כל תהליך, שלב כללי deny עם ארגז החול (18-sandbox.md).

#כללי MCP

תבניות MCPTool(...) מתאימות לשם הכלי המלא של גרוק בצורה server__tool, עם תמיכה ב-glob: MCPTool(linear__*) מתאים לכל כלי משרת linear. שמות הכלים של גרוק לא נושאים קידומת mcp__.

איות הכלל mcp__ שמשמש בקבצי .claude/settings.json מתקבל גם הוא ונכתב מחדש על אותו מתאם: mcp__linear (כל כלי בשרת linear), mcp__linear__get_issue (כלי אחד), mcp__linear__* (כל כלי בשרת), ו-mcp__* (כל כלי MCP).

#כללי WebFetch

• WebFetch(domain:example.com) מתאים למארח הזה ולכל תת-דומיין (api.example.com), בלי רגישות לאותיות. מ-www. מוביל מתעלמים רק כאשר נשארות לפחות שתי תוויות, ולכן www.com הוא מארח בפני עצמו, ואיות Unicode מתאים למארח ה-punycode שלו (bücher.example מתאים ל-xn--bcher-kva.example). תווים כלליים לא נתמכים בתוך תבניות domain:.
• תבנית בלי הקידומת domain: עושה glob מול ה-URL כולו: WebFetch(https://api.example.com/*).

#שמות כלים

שמות כלים מוכרים: Bash, Read, Edit (ו-Write), Grep (ו-Glob), MCPTool, WebFetch, WebSearch. כלל * חשוף מתאים לכל כלי. Globs לא נתמכים במיקום שם הכלי.

כללים שמציינים כלי לא מוכר (לדוגמה Agent(model:opus)) מדולגים עם אזהרה במקום שהטעינה תיכשל.

#סדר הערכה

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

#אישורים אינטראקטיביים ואיפה הם נשמרים

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

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

#"אפשר תמיד" לפי פקודה

קבוצה צרה יותר של אפשרויות זוכרת רק את הפקודה הספציפית, כלי ה-MCP, או דומיין ה-web-fetch שעליו מוצגת ההנחיה, לדוגמה "Always allow cargo test". השורות האלה פעילות כברירת מחדל. השבת אותן עם:

# ~/.grok/config.toml
[ui]
remember_tool_approvals = false

ארגונים יכולים להשבית אותן דרך אותו מפתח ב-requirements.toml או בתצורה מנוהלת. כאשר השער מופעל (ברירת המחדל), ההנחיות מקבלות:

• Always allow: <command>, ששומר allow עבור קידומת הפקודה.
• שורת "never allow" תואמת, ששומרת deny באותה דרך.
• שורות "always allow" ו-"never allow" מקבילות עבור כלי MCP ודומיינים של web-fetch. שורת "never allow" תמיד זוכרת את הכלי המדויק (אף פעם לא שרת שלם) או את הדומיין המדויק שעליו מוצגת ההנחיה. deny שנזכר מנצח כל הרשאה, ודומיין שנדחה מכסה גם את תת-הדומיינים שלו.

הקידומת שנזכרת מוגבלת לצורה קצרה של הפקודה: פקודות לקריאה בלבד שומרות רק את הקידומת הרשומה שלהן (לדוגמה git status, לא את רשימת הארגומנטים המלאה), ופקודות אחרות שומרות קידומת מובילה קצרה. ההנחיה מציגה בדיוק מה ייזכר לפני שאתה מאשר.

פקודות ברשימה המסוכנת (לדוגמה git push ו-rm) אף פעם לא מכבדות קידומת שנזכרה: רק הרשאה מדויקת עבור הפקודה כולה נחשבת, ולכן שורת "Always allow" שלהן ברירת המחדל היא הפקודה המלאה. אישור שלה עוצר הנחיות עבור ההפעלה המדויקת הזו בלבד. כל ארגומנטים שונים מציגים הנחיה שוב. פקודות שמריצות קוד ששמו מגיע מהארגומנטים שלהן מקבלות את אותו טיפול של מדויק בלבד: מפרשים ומריצים כמו python3, npx ו-sudo, ומשגרים כמו npm exec, pnpm dlx, yarn dlx, npm create ו-go run (כולל צורות עם דגל מוביל, כמו pnpm -C dir dlx). הרשאת קידומת שנזכרה עבור אחת מהן, כמו pnpm dlx או go run, מתעלמים ממנה, ולכן הפקודות האלה מציגות הנחיה שוב. כאשר אין הרשאה שאפשר לזכור שתעצור סקריפט מלהציג הנחיה שוב, פקודה מסוכנת מאחורי קידומת env, או שרשרת שהשלבים האחרים שלה עדיין יצטרכו אישור, שורת "Always allow" לא מוצעת בכלל, במקום לשמור כלל שלא יעבוד.

#השמירה היא לפי פרויקט

הרשאות אינטראקטיביות נשמרות בתיקיית המצב של גרוק עצמו תחת תיקיית הבית שלך, בתחום מאגר ה-git שבו הפעלת את גרוק (שורש המאגר שלו), כך שהרשאה שהתקבלה בשורש המאגר חלה גם בסשנים שהתחילו מתת-תיקייה של אותו מאגר. מחוץ למאגר git, ההרשאות בתחום תיקיית ההפעלה. worktree (git worktree או אחד מה-worktrees העצמאיים של גרוק) שומר את ההרשאות שלו וגם משתמש באלה של ה-checkout הראשי שלו: תשובות "always allow" ו-"never allow" של ה-checkout הראשי עבור פקודות, כלי MCP ודומיינים של web-fetch חלות ב-worktree, ו-"never allow" באחד מהם מנצח "always allow" באחד מהם. אישור גורף של כל פקודת shell בקובץ של ה-checkout הראשי לא עובר, וגם לא הגדרת עריכה מלבד דחיית עריכות. השיתוף רץ בכיוון אחד: תשובות שניתנו ב-worktree נשמרות במאגר של ה-worktree עצמו ואף פעם לא חלות ב-checkout הראשי. כדי להשאיר את תשובות "always allow" של ה-checkout הראשי מחוץ ל-worktrees שלו בכל מקום, הגדר [features] worktree_inherits_main_approvals = false או נעץ את זה ב-requirements.toml. תשובות "never allow" שלו עדיין חלות. GROK_WORKTREE_INHERITS_MAIN_APPROVALS=false עושה את אותו דבר עבור הסשנים שבהם הוא מוגדר, ומגיע לארגז החול של daemon סביבת העבודה רק כאשר ה-daemon עצמו רץ איתו. ב-Grok Desktop ובסביבות עבודה מתארחות, שער אישור הכלים בודק רק את התשובות של ה-worktree עצמו, אבל ארגז החול לפי פקודה של daemon סביבת העבודה (ראה מצב ארגז חול) גם מסרב לדומיינים של web-fetch שה-checkout הראשי דוחה, וכל עוד ההגדרה שלמטה פעילה, מתיר את אלה שהוא מתיר. הרשאה שנעשתה בפרויקט אחד אף פעם לא חלה בפרויקט אחר, ההרשאות לא נכתבות לתוך המאגר, והן לא מיועדות לעריכה ידנית.

כדי לבדוק או לאפס את ההרשאות של פרויקט, פתח את תת-התיקייה sessions של בית גרוק שלך (תיקיית .grok תחת תיקיית הבית שלך, או $GROK_HOME): כל תיקיית פרויקט שם (שורש התחום בקידוד URL) מחזיקה permission.toml (בתוספת וריאנטים permission_<client>.toml לפי לקוח) שמפרט את קידומות הפקודות שנזכרו, globs, כלי MCP או שרתים, דומיינים של web-fetch, ורשומות "never allow". מחיקת הקובץ מאפסת את ההרשאות של הפרויקט הזה. קריאת הכלי התואמת הבאה מציגה הנחיה שוב. איפוס ב-worktree מנקה רק את התשובות של ה-worktree עצמו: התשובות של ה-checkout הראשי שלו עדיין חלות עד שהן מוסרות מהקובץ של ה-checkout הראשי. התייחס לזה כמצב לקריאה בלבד. כדי להוסיף כללים, השתמש בתצורת [permission] ההצהרתית במקום.

הרשאות אינטראקטיביות הן מצב אישי, לפי מכונה. עבור רשימת היתר שאפשר לסקור בסקירת קוד ולשתף עם חברי צוות, השתמש בכללים הצהרתיים ב-.grok/config.toml של הפרויקט במקום.

#הגבלת Bash לפקודות מסוימות באמצעות הוק

הוק PreToolUse יכול לאכוף רשימת התרה על הכלי Bash שחלה בכל מצב הרשאות. הוקים נבדקים לפני מערכת ההרשאות. דחייה של הוק עוצרת את הקריאה, והתרה של הוק ממשיכה לבדיקות ההרשאה הרגילות (כך שכללי deny שלך עדיין חלים).

הערה: הוקים נכשלים במצב פתוח כברירת מחדל. אם סקריפט הוק קורס, פג הזמן שלו, או שהוא חסר, קריאת הכלי ממשיכה כאילו ההוק התיר אותה. ממשק המשתמש מדווח על הכשל. הגדר "failClosed": true על מטפל PreToolUse או UserPromptSubmit כדי לחסום בכשלים כאלה. הוק שמשמש כגבול אבטחה צריך להגדיר failClosed, לטפל בשגיאות שלו בעצמו, ולהתחשב בפקודות משורשרות. הדוגמה למטה מטפלת בשגיאות שלה ובפקודות משורשרות. ראה 10-hooks.md.

#דוגמה: התרה של git ו-gh בלבד

~/.grok/hooks/git-gh-only.json

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "git-gh-only.sh",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

~/.grok/hooks/git-gh-only.sh

#!/bin/sh
# Allow only git and gh commands, including within chained commands.

set -eu

deny() {
  echo '{"decision": "deny", "reason": "'"$1"'"}'
  exit 2
}

INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.toolInput.command // empty')

[ -n "$CMD" ] || deny "Empty command is not allowed"

# Normalize '&&' and '||' to ';' so chains can be checked segment by
# segment, then reject constructs this script cannot inspect.
CMD=$(echo "$CMD" | sed 's/&&/;/g; s/||/;/g')
case "$CMD" in
  *'$('*|*'`'*|*'&'*|*'>'*|*'<'*) deny "Substitution, background, and redirection are not permitted" ;;
esac

# Split on the separators and require every segment to start with git or gh.
echo "$CMD" | tr ';|' '\n\n' | while IFS= read -r SEGMENT; do
  SEGMENT=$(echo "$SEGMENT" | sed 's/^[[:space:]]*//')
  [ -n "$SEGMENT" ] || continue
  case "$SEGMENT" in
    git\ *|git|gh\ *|gh) ;;
    *) deny "Only git and gh commands are permitted. Blocked segment: $SEGMENT" ;;
  esac
done

chmod +x ~/.grok/hooks/git-gh-only.sh

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

להתקנת הוקים, לפורמט ה-JSON, למודל האמון של הוקי פרויקט ולאירועים אחרים, ראה 10-hooks.md, שכולל גם דוגמה משלימה של "חסימת תבניות מסוכנות".

#תצורות לדוגמה

#רק git ו-gh במצב headless (CI ואוטומציה)

grok -p "Implement the feature using only git and GitHub CLI" \
  --allow 'Read' \
  --allow 'Grep' \
  --allow 'Bash(git *)' \
  --allow 'Bash(gh *)'

התקן את הוק git-gh-only שלמעלה כדי לדחות כל פקודת Bash אחרת. לדחייה כברירת מחדל על כל הכלים, הגדר גם {"permissions": {"defaultMode": "dontAsk"}} בקובץ .claude/settings.json.

#בודק קוד לקריאה בלבד

# .grok/config.toml
[permission]
rules = [
  { action = "allow", tool = "read" },
  { action = "allow", tool = "grep" },
  { action = "deny",  tool = "edit" },
  { action = "deny",  tool = "bash" },
]

#פיתוח אינטראקטיבי

השתמש במצב default יחד עם כללי התרה צרים מסוג Bash(...) לפקודות שאתה מריץ הכי הרבה (git, cargo test, rg, ודומות).

#מדיניות ביצוע של PowerShell ב-Windows

ב-Windows, גרוק מפעיל את pwsh ואת Windows PowerShell עם -ExecutionPolicy Bypass עבור פקודות כלי Shell, כולל פקודות ברקע, עבור שורת סטטוס command, ועבור הוקים. המדיניות חלה על התהליך הזה ועל כל PowerShell שהוא מפעיל, דרך PSExecutionPolicyPreference, כך ש-.\script.ps1 של המודל רץ גם כשמדיניות LocalMachine או CurrentUser שלך היא AllSigned או RemoteSigned. מדיניות ביצוע של Group Policy עדיין חלה. מדיניות ביצוע אינה גבול אבטחה: כלי Shell יכול להריץ כל פקודה שסקריפט יכול להריץ. מסופי PTY אינטראקטיביים לא מוסיפים את הדגל.

#שילוב עם ארגז החול

ההרשאות קובעות מה המודל רשאי לבקש. ארגז החול ברמת מערכת ההפעלה (ראה 18-sandbox.md) קובע מה התהליך יכול לעשות גם אחרי שפקודה אושרה.

שילוב מומלץ לקוד לא מהימן:

1. dontAsk יחד עם כללי התרה צרים, או הוק מגביל
2. --sandbox strict או פרופיל מותאם
3. אמון בפרויקט יחד עם סקירה של כל הוקי SessionStart

#ניהול הרשאות ב-TUI

• החלטות הרשאה מופיעות בתמליל.
• הפקודה /always-approve מחליפה את מצב האישור התמידי. מצבים אחרים נקבעים דרך defaultMode (ראה איך לקבוע את המצב).
• בקשות הרשאה כוללות אפשרויות "Always allow" לכל פקודה, שנשמרות לפרויקט הנוכחי בלבד (פעיל כברירת מחדל. כיבוי עם [ui] remember_tool_approvals = false). ראה אישורים אינטראקטיביים.
• לניהול הוקים ותוספים, הרץ /hooks או /plugins. ראה 10-hooks.md.

#שיטות עבודה מומלצות

1. העדף תבניות צרות. Bash(git *) מעניק פחות גישה מכלל התרה של Bash בלי תבנית.
2. שלב שכבות. dontAsk, כללי התרה צרים, הוק מגביל וארגז החול מגבילים כל אחד בנפרד.
3. סקור תצורת פרויקט ממקורות לא מוכרים. אמון בתיקייה מתנה את כללי ההרשאות של הפרויקט ב-.grok/config.toml וב-.claude/settings.json, וגם את טעינת הוראות הפרויקט וה-skills בהפעלה. הפעלה במצב headless עם המקורות האלה דורשת --trust או הענקה קודמת. סקור אותם וכל הוק של הפרויקט לפני מתן אמון ב-checkout לא מוכר (ראה 10-hooks.md).
4. בדוק את המדיניות שלך. כש-defaultMode: "dontAsk" מוגדר (או כשהוק PreToolUse שלך מותקן), הרץ פקודות מייצגות וודא מה נחסם.
5. התייחס לרשימת הפקודות לקריאה בלבד כאמצעי נוחות, לא כגבול אבטחה.

#ראה גם

• הוקים: PreToolUse וסקריפטים אחרים של מחזור חיים
• מצב headless: CLI חד פעמי ודגלי אוטומציה
• מצב סוכן: ACP, stdio ושרתי סוכן
• ארגז חול: פרופילי בידוד ברמת מערכת ההפעלה
• תצורה: מבנה config.toml הילידי