📘 תיעוד 46

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

שלוט במה ש-Grok יכול לגשת אליו ולבצע: מצבי הרשאות, כללי allow/ask/deny, הוקים (hooks), וארגז החול האופציונלי ברמת מערכת ההפעלה (OS-level sandbox).

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

#מצבי הרשאות

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

מצבים מגדירים קו בסיס. כללי allow, ask, ו-deny עדיין חלים מעל כל מצב.

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

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. ראה מצב סוכן.

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

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>

הגדרות (Config):

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

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

#Always-approve

מדלג על בקשות אישור רגילות כך שכלים רצים בלי לחכות ללחיצה. כללי deny, הוקים, וחלק מכללי 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. ראה הגדרת הרשאות.

#מצב Auto

מפחית בקשות אישור אינטראקטיביות על ידי בדיקת קריאות כלים רבות לפני שהן רצות. עבודה מקומית שגרתית ממשיכה לעיתים קרובות. קריאה שהמסווג אינו מאשר אוטומטית מעלה בקשת אישור כדי שתוכל לאשר או לדחות אותה. בהפעלות שאינן אינטראקטיביות (grok -p, stdio ללא זיהוי), אותה קריאה נכשלת ומדווחת למודל (למשל Auto mode blocked this action …).

עבור אוטומציה שחייבת להריץ כלים ללא אישור אינטראקטיבי, השתמש ב-always-approve (ובכללי deny אם נדרשות חסימות קשיחות) במקום ב-auto בלבד.

#השבתת 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 לצורכי תאימות.

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

#כיצד קריאה לכלי מורשית

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

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

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

   • כלל deny תואם דוחה את הקריאה. deny גובר על כל כלל אחר.
   • כלל ask תואם מבקש ממך אישור, כולל עבור קריאת קבצים, חיפושים ופקודות מעטפת שאחרת היו מאושרים אוטומטית.
   • כלל allow תואם מאשר את הקריאה.

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

4. אישורים אוטומטיים מובנים. כלי קריאה בלבד וקבוצה קבועה מראש של פקודות מעטפת לקריאה בלבד רצים ללא בקשת אישור (ראו להלן).

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

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

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

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

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

• 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

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 שהגדרת המאגר המקומי או עץ העבודה שלה מתקינה הוק הניתן להרצה (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. עבור כללים אישיים שאינם נשמרים במאגר (uncommitted) בפרויקט, השתמש ב-.claude/settings.local.json: Grok קורא אותו ישירות (ראה תאימות ל-Claude Code).
• החלטות "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 במשמעות של "רק לאפשר git/gh": כלל deny tool = "bash" יחסום גם את git וגם את gh. עבור מדיניות של חסימה כברירת מחדל (deny-by-default), השתמש ב-defaultMode: "dontAsk" בתוך .claude/settings.json או בהוק מסוג 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 (בעלייה במעלה התיקיות עד לשורש המאגר). המקור המקורי של .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.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. נתמכים גם ? ו-[...].

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

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

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

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

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

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

כל מקטע מנורמל לפני התאמת כללים. הקצאות סביבה בתחילה כגון 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.
• ההתאמה רואה את המילים המנותחות מחוברות ברווחים בודדים, ללא מרכאות מעטפת. כתוב תבניות מול הפקודה ללא מרכאות.

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

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

#כללי Read, Edit, ו-Grep

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

• * ו-? אינם חוצים /: ** כן חוצה. Read(src/*) מתאים ל-src/main.rs אך לא ל-src/nested/mod.rs: השתמש ב-Read(src/**) עבור כל העץ.
• שם קובץ בלבד מתאים רק למחרוזת המדויקת הזו. השתמש ב-**/.env כדי להתאים ל-.env בכל עומק.
• אין קידומות עוגן: קידומת // או ~/ בתבנית נחשבת כטקסט glob מילולי. כתוב במקום זאת תבניות נתיב מוחלט או תבניות **/.
• מכיוון ש-./.. מצומצמים לפני ההתאמה, לא ניתן לחמוק מתבניות מושרשות על ידי מעבר נתיבים (traversal): Read(./**) מוגבל לתיקיית העבודה (נתיבים יחסיים פשוטים כמו src/main.rs מתאימים: ./../../etc/passwd אינו מתאים), ו-Read(src/**) נשאר תחת src/. תבניות לא מושרשות (*, או קידומת ** כמו ב-**/*.rs) מתאימות בכוונה בכל עומק, בכל מקום.
• כללי Read חלים גם על חיפושי grep: כללי Grep(...) מתאימים רק ל-grep.
• בדיקות Read/Edit/Grep מקוריות עוקבות אחר קישורים סמליים (symlinks) בתוך הנתיב עבור deny ו-ask על היעד שנפתר. כלל allow שמתאים רק ליעד שנפתר אינו מעניק אישור עבור ארגומנט הכלי.
• קישור סמלי בתוך הנתיב שלא ניתן לפתור מקפיץ בקשת אישור כאשר כלל קובץ מסוג deny או ask חל על אותו כלי.

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

#כללי MCP

תבניות MCPTool(...) מתאימות לשם הכלי המלא ב-Grok בצורה server__tool, עם תמיכה ב-glob: MCPTool(linear__*) מתאים לכל כלי משרת ה-linear. שמות הכלים ב-Grok אינם נושאים קידומת 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.. תווים כלליים אינם נתמכים בתוך תבניות domain:.
• תבנית ללא קידומת domain: מבצעת התאמת glob מול כתובת ה-URL כולה: WebFetch(https://api.example.com/*).

#שמות כלים

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

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

#סדר הערכה

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

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

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

• Allow once: אשר הפעלה בודדת זו.
• Reject once: דחה אותה, אופציונלית עם הודעה בחזרה למודל.
• Enable always-approve mode: מאשר את כל הקריאות העתידיות לכלים, לא רק את זו שבקשת האישור קפצה עבורה.
• Allow all edits this session: מוצג עבור עריכות קבצים. אישור זה נשמר בזיכרון בלבד ואינו שורד הפעלה מחדש.

#"Always Allow" לכל פקודה

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

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

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

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

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

פקודות ב-רשימת הפקודות המסוכנות (למשל git push ו-rm) לעולם אינן מכבדות קידומת שנשמרה: רק אישור מדויק עבור הפקודה כולה נחשב, ולכן שורת ה-"Always allow" שלהן מוגדרת כברירת מחדל לפקודה המלאה. אישורה עוצר בקשות אישור עבור אותה הפעלה מדויקת בלבד: כל ארגומנט שונה יקפיץ שוב בקשת אישור. כאשר שום אישור שניתן לזכור לא יוכל למנוע מסקריפט לבקש אישור שוב (פקודה מסוכנת מאחורי קידומת env, או שרשרת ששאר צעדיה עדיין ידרשו אישור), שורת ה-"Always allow" אינה מוצעת כלל במקום לשמור כלל שלא יעבוד.

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

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

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

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

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

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

הערה: הוקים נכשלים במצב פתוח (fail open). אם סקריפט הוק קורס, מגיע ל-timeout, או חסר, הקריאה לכלי ממשיכה כאילו ההוק אישר אותה, והכישלון מדווח בממשק המשתמש. הוק המשמש כגבול אבטחה חייב לטפל בשגיאות של עצמו, וחייב לקחת בחשבון פקודות משורשרות, כפי שעושה הדוגמה להלן. ראה 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 ללא ראש (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 בתוספת כללי allow צרים מסוג Bash(...) עבור הפקודות שאתה מריץ בתדירות הגבוהה ביותר (git, cargo test, rg, וכדומה).

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

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

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

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

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

• החלטות הרשאה מופיעות בתעתיק (transcript).
• הפקודה /always-approve מעבירה בין מצבי always-approve: מצבים אחרים מוגדרים דרך defaultMode (ראה כיצד להגדיר את המצב).
• בקשות אישור כוללות אפשרויות "Always allow" לכל פקודה שנשמרות עבור הפרויקט הנוכחי בלבד (מופעל כברירת מחדל: ניתן להשבית באמצעות [ui] remember_tool_approvals = false). ראה אישורים אינטראקטיביים והיכן הם נשמרים.
• כדי לנהל הוקים ותוספים, הרץ /hooks או /plugins (במרבית מסופי הפקודה, Ctrl+L פותח גם את חלונית ההרחבות: ב-VS Code, Cursor, Windsurf, ו-Zed, המקש Ctrl+L משמש להתערבות באמצע תור). ראה 10-hooks.md.

#שיטות מומלצות

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

#ראה גם

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