📘 תיעוד 87

ניהול מודים עבור הארגון

שלוט במודים של Claude Code באמצעות הגדרות מנוהלות: עצור מודים שהמשתמש התקין, אפשר רק את שלך, בדוק מה מוד יכול לעשות, ואכוף מדיניות עם מוד משלך.

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

הדף הזה מיועד לאדם שפורס הגדרות מנוהלות עבור Claude Code, בין כקובץ, דרך MDM, או ממסוף הניהול של claude.ai. מודים פועלים כברירת מחדל ב-Claude Code מגרסה v2.1.286 ואילך. התחל בסעיף שמתאים למה שבאת לעשות:

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

[!NOTE]

המקרים האלה מכוסים בדפים אחרים:

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

#עצירת טעינה של מודים שהמשתמש התקין

כדי למנוע מכל מוד שהמשתמשים שלך מביאים להריץ את ה-hooks שלו, הגדר את האפשרות allowManagedModsOnly על השומר המובנה, מוד מדיניות ש-Claude Code טוען לפני כל מוד שמשתמש מתקין. האפשרות נכנסת להגדרות המנוהלות תחת pluginConfigs, עם המפתח cc-plugin-sec-default@builtin:

{
  "pluginConfigs": {
    "cc-plugin-sec-default@builtin": {
      "options": {
        "allowManagedModsOnly": true
      }
    }
  }
}

כשהאפשרות מוגדרת בהגדרות המנוהלות:

• אף מוד שמשתמש מביא לא מריץ את ה-hooks שלו: זה מכסה מוד בתוך תוסף שהמשתמש התקין, מוד שנטען עם --plugin-dir, ומוד ש-Claude כתב במהלך סשן
• המודים של הארגון שלך עדיין רצים: מוד שנחשב של הארגון שלך אינו נבדק. כל מוד אחר נחשב של משתמש ומסורב. זה כולל מוד בתוך תוסף שאתה מפעיל מ-GitHub או משוק מרוחק אחר, ומוד שהארגון שלך מפעיל עבור החברים שלו ב-claude.ai. אם אף אחד לא נחשב שלך, אף מוד מותקן לא מריץ את ה-hooks שלו.
• משתמשים לא יכולים לבטל את זה: השומר קורא את האפשרות רק מההגדרות המנוהלות, ולכן אותה רשומה בקובץ הגדרות של משתמש, פרויקט או מקומי, או בקובץ שמועבר עם --settings, לא משנה דבר
• מדיניות בקובץ או ב-MDM מכסה כל ספק: כשאתה מספק את האפשרות כקובץ או דרך MDM, היא פועלת באותו אופן ב-Amazon Bedrock, ב-Agent Platform של Google Cloud, וב-Microsoft Foundry. לאספקה ממסוף הניהול של claude.ai, ראה זמינות פלטפורמה
• ההתאמות האחרות של המשתמשים ממשיכות לעבוד: ה-hooks שלהם בקובצי הגדרות וב-hooks/hooks.json של תוספים, שורות סטטוס, ו-/goal אינם מושפעים
• מודים מובנים ממשיכים לרוץ: מודים שבנויים בתוך Claude Code, כמו תמיכה ב-AGENTS.md, לכל אחד יש מתג משלו

כדי לאמת את האפשרות במחשב של משתמש, הפעל שם את Claude Code עם --plugin-dir ועם הנתיב של ספרייה שמחזיקה מוד, למשל claude --plugin-dir ./first-mod. ה-hooks של המוד לא רצים, והתמליל ויומן הדיבוג מכילים את ההודעה של השומר, שמציינת את המוד ואת allowManagedModsOnly. אם ההודעה לא שם, ראה בדיקה שמדיניות בתוקף ואת הכללים שמחליטים אם אפשרות נכנסת לתוקף.

אם הגדרת את CLAUDE_CODE_ENABLE_FUNCTION_HOOKS ל-0 במהלך הגישה המוקדמת, החלף אותו באפשרות הזו. Claude Code מגרסה v2.1.287 ואילך מתעלם מהמשתנה בכל ערך, ולכן 0 שם משאיר את המודים פעילים.

#דע מה קורה כברירת מחדל

בלי הגדרות מוד משלך, זה מה שהמשתמשים שלך מקבלים:

• מודים פעילים. משתמש יכול להתקין תוסף שמכיל מוד מכל שוק שהגדרות התוספים שלך מתירות, או לטעון אחד מספרייה עם --plugin-dir.

• שומר מובנה רץ ראשון. Claude Code טוען מוד מובנה בשם sec-default@builtin לפני כל מוד שמשתמש מתקין. משתמשים לא יכולים לכבות אותו. /plugin ויומן הדיבוג מציגים אותו כ-cc-plugin-sec-default. השומר נטען כשאחד מאלה נכון:

  • במחשב יש הגדרות מנוהלות
  • הסשן רץ על פרטי התחברות של /login לתוכנית Team או Enterprise

  משתמש שמתחבר עם מפתח API, או דרך Amazon Bedrock, Agent Platform של Google Cloud, או Microsoft Foundry, מקבל את השומר רק במחשב שיש בו הגדרות מנוהלות. סשן שרץ על CLAUDE_CODE_OAUTH_TOKEN ארוך טווח גם הוא לא נחשב להתחברות הזו, גם כשהתחברות Team או Enterprise שמורה במחשב.

• השומר מגן על מה שאתה מנהל. מוד של משתמש לא יכול לשנות את מה שה-hooks המנוהלים שלך מקבלים או מחליטים, את הנחיית המערכת, את CLAUDE.md המנוהל שלך והנחיות מנוהלות אחרות, את מה שכל מוד קורא כהגדרות, או את הכלים והתיאורים של שרתי MCP המנוהלים שלך.

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

• כללי הרשאה ו-hooks מסוג PreToolUse קודמים למוד של משתמש. כשהשומר טעון, כברירת מחדל מוד של משתמש לא יכול לאשר קריאה שכלל deny מסרב לה או שכלל ask מבקש עליה אישור, בלי קשר לקובץ ההגדרות שמחזיק את הכלל. המוד גם לא יכול לאשר קריאה שכל hook מסוג PreToolUse חסם.

  כללי הרשאה ו-hooks מסוג PreToolUse חלים על קריאות הכלים של Claude, לא על קריאות $.fs ו-$.process של מוד. כש-Read(.env) נדחה, מוד עדיין יכול לקרוא את הקובץ הזה עם $.fs.read או להפעיל תוכנית שעושה זאת. כדי להגביל את קריאות $.fs ו-$.process של המוד עצמו, מנע מהמוד להיטען או טפל בהן ב-מוד מדיניות.

• מוד של משתמש עדיין יכול לדלג על חלק מההנחיות. ב-מצב אוטומטי, קריאה שהמוד מאשר רצה בלי בדיקת מסווג, אלא אם השומר טעון והסשן רץ עם --permission-prompt-tool או עם callback של canUseTool ב-Agent SDK. שם המסווג בודק את הקריאה קודם. להנחיות שאישור של מוד לא מדלג עליהן, ראה הרחבת הרשאות עם hooks.

המקור של השומר ציבורי ב-ספריית mods/sec-default במאגר של Claude Code.

#דע אילו בקרות עדיין חלות

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

• hooks של הגדרות ממשיכים לעבוד. hooks מסוג command, HTTP, prompt ו-agent בקובצי הגדרות וב-hooks/hooks.json של תוספים רצים כמו קודם, לצד מודים.

• כללי deny קודמים במקום שבו השומר נטען. מוד של משתמש לא יכול לאשר קריאה שכלל deny מסרב לה, אלא אם הגדרת allowModsToOverrideDenyRules.

• hooks מנוהלים רצים ראשונים. hook מסוג PreToolUse בהגדרות המנוהלות רץ לפני hook מסוג tool.call של כל מוד, וכשה-hook המנוהל הזה חוסם קריאת כלי, אף hook מסוג tool.call של מוד לא רץ עבור הקריאה הזו. אם הקריאה ממשיכה ומוד משכתב אותה, ה-hooks המנוהלים שלך רצים שוב על הקריאה המשוכתבת, כך שהם עדיין יכולים לחסום אותה.

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

• מדיניות רשת מכסה את $.http.fetch.

  • מדיניות הארגון שלך לא מתירה את WebFetch: Claude Code גם מסרב לכל בקשת $.http.fetch של מוד. ראה זמינות WebFetch.

  • אתה מכבה את כלי WebFetch עם CLAUDE_CODE_DISABLE_WEB_FETCH או עם כלל deny של WebFetch, בהגדרות המנוהלות או בכל קובץ הגדרות אחר: מודים עדיין יכולים לבצע בקשות $.http.fetch.

    כדי לעצור אותן עבור כל מוד שהמשתמשים שלך מתקינים, מנע טעינה של מודים שהמשתמש התקין, או חבר hook ל-http.fetch ב-מוד מדיניות וסרב לבקשות ממודים של משתמשים. תן ל-hook הזה מטפל .catch שגם הוא מסרב, כי Claude Code מדלג על hook שנכשל ואז הבקשה ממשיכה. אם רק מגבילים אילו תוספים משתמשים יכולים להתקין, פחות מודים נטענים, אבל אלה שאתה מתיר עדיין מבצעים את הבקשות האלה.

  • אתה מגדיר CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC: מוד שאתה או המשתמשים שלך מתקינים עדיין יכול לבצע את הבקשות האלה. המשתנה עוצר רק את המודים שבנויים בתוך Claude Code, וגם כל בקשת $.http.fetch שנושאת את פרטי ההתחברות של Anthropic של הסשן. לפני v2.1.288, המשתנה עצר כל בקשת $.http.fetch של מוד.

  אף אחד מאלה לא מכסה תוכנית שהמוד מפעיל עם $.process.run, שמגיעה לרשת עם הגישה של המשתמש עצמו.

• בקרות תוספים מכסות מודים. מוד הוא תוסף, ולכן ההגדרות שמגבילות מה משתמשים יכולים להתקין, כמו strictKnownMarketplaces, מחליטות אם אפשר להתקין אותו בכלל.

• מודים לא יכולים לשנות את הנחיית ההרשאה. מוד יכול לעצב מחדש חלק גדול מהממשק של Claude Code, אבל לא את הנחיית ההרשאה, ולכן הוא לא יכול לשנות מה הנחיה מציגה. מוד עדיין יכול לאשר או לסרב לקריאת כלי לפני שההנחיה מופיעה, כפי שדע מה קורה כברירת מחדל מתאר.

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

• --safe-mode מכבה מודים מותקנים, כולל שלך. הפעל סשן עם claude --safe-mode כדי לבדוק אם מוד גרם לבעיה.

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

#דע אילו hooks של מוד של משתמש לא רצים

במקום שבו השומר המובנה נטען, hook שמוד של משתמש רושם על אחד מהאירועים האלה אף פעם לא רץ, ו-/plugin אומר זאת למשתמש הזה בהערה. בשורות session.append, door הוא סוג השורה השמורה שה-hook מסונן אליה.

השומר גם עובר על hooks של משתמש במקרים אחרים, כמו התיאורים של הכלים של הארגון שלך, על tool.describe, והשורה השמורה עבור הטקסט של מיומנות. /plugin לא מציג הערה עבור אלה. אם hook על אירוע אחר לא עושה דבר, ראה גילוי למה מוד לא עושה דבר.

ההערה מופיעה בפרטי התוסף ובלשונית Errors של /plugin. היא דורשת Claude Code מגרסה v2.1.299 ואילך. היא מציינת כל hook מהטבלה כפי שהמוד רשם אותו, כמו בדוגמה הזו:

Its hooks on classic.Stop, prompt.section do not run here: where an organization manages Claude Code, these events pass over the plugins you install
Only a plugin that counts as your organization's own runs hooks on these events. An administrator sets that up in managed settings

כדי לאפשר ל-hooks האלה לרוץ, שנה את ההגדרות המנוהלות באחת משתי דרכים:

• הרץ את המוד כשל הארגון שלך: התקן את המוד כך שהוא נחשב שלך. ה-hooks שלו על האירועים האלה אז רצים, והשומר נשאר טעון עבור כל מוד אחר. המוד נדלק עבור כל מי שמקבל את ההגדרות האלה, והוא צריך לשבת בספרייה שאתה מציב בכל מחשב. אם אתה רושם אותו ב-prependPlugins, השאר את sec-default@builtin ברשימה.
• הסר את השומר: השאר את sec-default@builtin מחוץ ל-prependPlugins. רשימה ריקה, "prependPlugins": [], מספיקה. אתה מאבד את כל השומר, לא רק את האירועים האלה. מוד של משתמש יכול אז לעשות את מה שהשומר אחרת מונע ממנו לעשות, והאפשרויות של השומר לא חלות.

אם אתה מספק רשימה בלי השומר דרך הגדרות מנוהלות בשרת, השומר נשאר טעון עד שהשרת מאשר את ההגדרות עבור הסשן. כדי לאמת כל אחד מהשינויים במחשב שמריץ v2.1.299 ואילך, פתח את /plugin בסשן שם ובדוק שההערה נעלמה.

hook מסוג session.append בלי מסנן door עדיין רץ ולא מקבל הערה, אבל השורות השמורות בטבלה לא מגיעות אליו.

#להחליט אם להשאיר מודים מופעלים

מוד יכול לעשות יותר משאר החלקים של תוסף כי הוא רץ בתוך Claude Code. הוא רואה כל פרומפט וכל קריאת כלי, יכול לשנות אותם, ויכול לאשר או לדחות קריאת כלי לפני שמופיעה בקשת הרשאה.

מה שמשתמש יכול לטעון כמוד תלוי בבקרות התוספים שכבר יש לך:

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

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

#סקירה של מה מוד יכול לעשות

אפשר לראות מה מוד מסוגל לעשות בלי להריץ אותו. במעטפת שלך, הרץ את claude plugin validate על ספריית התוסף:

claude plugin validate ./some-mod

שורות hooks: ו calls: בפלט מתארות את הקוד של המוד:

  ❯ ./register.js hooks: session.start, tool.call, ui.render{component=Pane}
  ❯ ./register.js calls: $.fs.read, $.http.fetch, $.store.set, $.ui.open

שורה hooks: מפרטת את האירועים שהמוד מקבל. שורה calls: מפרטת את מתודות ה API של המודים שהקוד שלו קורא להן. ה API של המודים, שנכתב $ בקוד של מוד, הוא הדרך שבה מוד מגיע לקבצים, לתהליכים ולרשת. Claude Code מסרב לטעון מוד שמשתמש ב API של המודים באופן שהפקודה הזאת לא יכולה לקרוא.

הסתכל בשורה calls: על אלה:

בשורה hooks:, tool.call ו prompt.submit אומרים שהמוד רואה כל קריאת כלי וכל פרומפט, ויכול לשנות אותם. session.append אומר שהמוד יכול לכתוב מחדש כל שורה של השיחה לפני שהיא נשמרת, מלבד השורות שהשומר פוסח עליהן. ui.render{component=AskUserQuestion} אומר שהמוד יכול לצייר מחדש את תיבת הדו שיח ש Claude משתמש בה כדי לשאול את המשתמש שאלה. tool.check אומר שהמוד יכול לאשר או לדחות קריאת כלי לפני שמופיעה בקשת הרשאה. לדעת מה קורה כברירת מחדל מפרט אילו מהכללים ומההוקים שלך גוברים על התשובה שלו.

#בחירה כמה לאפשר

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

מה כל הגדרה עושה:

• allowManagedModsOnly: אפשרות על השומר המובנה. Claude Code מסרב למודים של המשתמשים עצמם, כך שאף אחד מההוקים שלהם לא רץ. הוקים של הגדרות המשתמשים, שורות סטטוס, ו /goal ממשיכים לעבוד. עצירת טעינה של מודים שהמשתמש התקין מפרטת מה זה מכסה.
• allowManagedHooksOnly: הגדרה רחבה יותר. רק המודים של הארגון שלך והמודים המובנים ב Claude Code נטענים. מוד שמשתמש התקין בעצמו לא נטען. ההגדרה גם חוסמת הוקים בקבצי ההגדרות של המשתמשים עצמם. קרא מה רץ תחת allowManagedHooksOnly לפני שאתה מגדיר אותה.
• disableAllHooks: ההגדרה הרחבה ביותר. בהגדרות מנוהלות, היא עוצרת את המודים בכל תוסף מותקן, כולל שלך, ומכבה כל הוק בקבצי הגדרות, כך שהוק PreToolUse בהגדרות המנוהלות שלך כבר לא חוסם דבר. שורות סטטוס מותאמות ו /goal מפסיקים לעבוד גם כן. קרא disableAllHooks לפני שאתה מגדיר אותה.
• disableSideloadFlags: דוחה את --plugin-dir ואת --plugin-url בעת ההפעלה, ומונע טעינה של מודים ש Claude כותב במהלך סשן. ההגדרה גם דוחה את --agents ואת --mcp-config. קרא disableSideloadFlags לפני שאתה מגדיר אותה.

מודים מובנים ב Claude Code, כמו תמיכה ב AGENTS.md, לא מושפעים מההגדרות האלה. לכל אחד יש מתג משלו.

משתמש שהמוד שלו נדחה או לא נטען מוצא את הסיבה ביומן הדיבאג שלו. הודעות סירוב מפרט את השורות עבור allowManagedHooksOnly ו disableAllHooks, והודעות מהשומר המובנה כולל את השורה עבור allowManagedModsOnly.

#לאפשר רק את המודים של הארגון שלך

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

{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "directory", "path": "/opt/acme/claude-plugins" }
    }
  },
  "enabledPlugins": { "acme-guard@acme-tools": true },
  "prependPlugins": ["acme-guard@acme-tools", "sec-default@builtin"],
  "pluginConfigs": {
    "cc-plugin-sec-default@builtin": {
      "options": { "allowManagedModsOnly": true }
    }
  },
  "disableSideloadFlags": true
}

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

• extraKnownMarketplaces, enabledPlugins, ו prependPlugins: מתקינים את המוד שלך כך שהוא נחשב כשלך, ומריצים אותו ראשון כשהשומר אחריו. התקנת המודים של הארגון שלך וקביעת הסדר מכסה את הספריה שהמפתחות האלה מצביעים אליה.
• pluginConfigs: מגדיר את אפשרות allowManagedModsOnly של השומר, כך ש Claude Code מסרב למודים של המשתמשים עצמם. הוקים של ההגדרות שלהם, שורות סטטוס, ו /goal ממשיכים לעבוד.
• disableSideloadFlags: ראה disableSideloadFlags עבור הדגלים שהוא דוחה בעת ההפעלה

כדי לאמת את המדיניות במכונת בדיקה, במעטפת שלך התחל סשן עם claude --debug וקרא את יומן הדיבאג:

• המוד שלך: בשורה hooks module שלו יש tier prepend
• מוד שהמשתמש התקין: שורה אומרת refused by cc-plugin-sec-default: mods are limited to your organization's by policy (allowManagedModsOnly). שורה מוקדמת יותר אומרת שמודול ההוקים של המוד הזה loaded, אז חפש את הסירוב.
• ספריית תוסף: claude --plugin-dir ./any-mod יוצא עם הודעה שמתחילה ב --plugin-dir is disabled by your organization's managed settings (disableSideloadFlags)

כדי גם להגביל אילו marketplaces משתמשים יכולים להוסיף, שלב את הקובץ הזה עם הגבלות ה marketplace שלך.

#החלת בקרות התוספים שלך על מודים

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

• ראה אילו תוספים נטענים ברחבי הצי שלך: ביקורת וסקירה
• החלט מתי תוסף שסקרת יכול להתעדכן: הגדרת מדיניות עדכון
• תן לקבוצה אחת מדיניות שונה, כמו פיילוט: תכנון למה שהגדרות מנוהלות לא יכולות לאכוף
• בדוק אילו אפליקציות וסוגי סשן מחילים את מפתחות התוסף: מתי כל משטח מחיל את מפתחות התוסף
• הגדר CI ומכולות: זריעת מכולות ו CI
• הצע מודים שהמשתמשים שלך רשאים להתקין: אירוח marketplace. מוד ש Claude Code מעתיק ממקור GitHub, git, URL, או npm נחשב של משתמש, ולא כשל הארגון שלך.

#הגדרת אפשרויות על השומר המובנה

השומר המובנה מקבל אפשרויות. הגדר אותן בהגדרות מנוהלות תחת pluginConfigs, לפי המפתח cc-plugin-sec-default@builtin, כמו שעושה הדוגמה בעצירת טעינה של מודים שהמשתמש התקין.

הטבלה נותנת מה המשתמשים שלך מקבלים כשכל אפשרות לא מוגדרת וכשהיא מוגדרת ל true:

הכללים האלה מחליטים אם אפשרות נכנסת לתוקף:

• למזהה יש צורה אחת כאן: Claude Code קורא את האפשרויות רק תחת cc-plugin-sec-default@builtin. prependPlugins מקבל גם את sec-default@builtin, ו pluginConfigs לא.
• רק הגדרות מנוהלות נספרות: אותה רשומה בקובץ הגדרות של משתמש, פרויקט, או מקומי, או בקובץ שהועבר עם --settings, לא מגדירה אפשרות ולא משחררת אפשרות
• השומר חייב להיטען: אם אתה מגדיר prependPlugins, ציין את השומר ברשימה. במקום שהשומר לא נטען, אף אפשרות לא חלה.
• השומר נכשל סגור: אם השומר לא יכול לקרוא הגדרות מנוהלות, הוא מסרב לכל מוד של משתמש בטעינה. אם הוא לא יכול לבדוק את כללי ה deny עבור קריאה שמוד של משתמש אישר, הוא מסרב לקריאה.

ההודעות מהשומר המובנה הן מה שהמשתמשים שלך רואים כשאחת מהאפשרויות חלה.

#הפעלת המודים של הארגון

אפשר לפרוס מודים משלכם לכל משתמש, לבחור איפה הם רצים ביחס למודים של המשתמשים, ולהשתמש באחד כדי לאכוף מדיניות.

#התקנת המודים של הארגון וקביעת הסדר

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

• enabledPlugins מנוהל מגדיר את התוסף של המוד ל-true
• הגדרות מנוהלות מציינות את ה-marketplace של התוסף כספרייה במחשב של המשתמש, לפי נתיב מוחלט. רשומת extraKnownMarketplaces עושה זאת וגם רושמת את ה-marketplace עבור המשתמש.
• ה-marketplace מציין את התוסף לפי נתיב יחסי, כך ש-Claude Code טוען אותו במקום מאותה ספרייה

כדי לעמוד בהם, תנו לניהול המכשירים שלכם להעתיק את ספריית ה-marketplace לאותו נתיב בכל מחשב. הפכו את הספרייה וכל ספרייה מעליה לניתנות לכתיבה רק על ידי מנהל, כמו קובץ ההגדרות המנוהלות. כל מי שיכול לכתוב שם יכול לשכתב את המוד שלכם. הגדרות מנוהלות שאתם מספקים ממסוף הניהול של claude.ai יכולות לשאת את המפתחות, אבל הן לא יכולות לשים את הספרייה על מחשב.

הספרייה מחזיקה את המניפסט של ה-marketplace ואת התוסף:

/opt/acme/claude-plugins/
├── .claude-plugin/
│   └── marketplace.json
└── plugins/
    └── acme-guard/
        ├── .claude-plugin/
        │   └── plugin.json
        └── hooks/
            ├── hooks.json
            └── register.js

המניפסט מציין את התוסף לפי הנתיב שלו יחסית לספרייה הזו:

{
  "name": "acme-tools",
  "owner": { "name": "Acme" },
  "plugins": [
    { "name": "acme-guard", "source": "./plugins/acme-guard", "description": "Acme policy mod" }
  ]
}

תוסף ש-Claude Code מעתיק למטמון שלו נחשב לתוסף של משתמש, גם כאשר enabledPlugins מנוהל מפעיל אותו. זה מכסה כל תוסף ממקור GitHub, git, URL או npm. המוד שלו רץ בין המודים של המשתמשים, prependPlugins ו-appendPlugins מדלגים עליו, allowManagedModsOnly מסרב לו, ו-allowManagedHooksOnly מונע ממנו להיטען. ביומן הדיבוג של המשתמש יש שורה שמתחילה במזהה של התוסף וב-is enabled by managed settings, but.

Claude Code יורה אירוע בכל פעם שהוא עומד לפעול, למשל להריץ כלי, ומעביר אותו לכל מוד בתורו. מוד שנחשב לשלכם רץ לפני המודים של המשתמשים גם כשאתם לא מציינים אותו בשום מקום. כדי לקבוע את מקומו, ציינו את המזהה שלו באחת משתי הגדרות. המזהה הוא שם התוסף, @, ושם ה-marketplace, למשל acme-guard@acme-tools.

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

הדוגמה הזו מצהירה על ה-marketplace acme-tools ב-/opt/acme/claude-plugins, מפעילה את acme-guard ממנו, ומריצה את המוד הזה ראשון, עם השומר המובנה אחריו:

{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "directory", "path": "/opt/acme/claude-plugins" }
    }
  },
  "enabledPlugins": { "acme-guard@acme-tools": true },
  "prependPlugins": ["acme-guard@acme-tools", "sec-default@builtin"]
}

כל מפתח עושה עבודה אחת:

• extraKnownMarketplaces: מציין את הספרייה שמחזיקה את ה-marketplace acme-tools. path הוא הנתיב המוחלט של הספרייה שמכילה את .claude-plugin/marketplace.json.
• enabledPlugins: מפעיל את acme-guard לכל משתמש שמקבל את ההגדרות המנוהלות האלה
• prependPlugins: שם את acme-guard ראשון ואת השומר המובנה שני, שניהם לפני כל מוד שמשתמש מתקין. Claude Code עוקב אחר הסדר שאתם מציינים.

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

כדי לאשר איפה המוד רץ, התחילו סשן במחשב הזה עם claude --debug וחפשו ביומן הדיבוג את המזהה של המוד:

• hooks module acme-guard@acme-tools loaded, עם tier prepend: המוד נחשב למוד של הארגון ורץ ראשון
• אותה שורה עם tier user: Claude Code מתייחס אליו כאל מוד של משתמש. שורה שנייה, prependPlugins names acme-guard@acme-tools, which is not an enabled managed plugin with a hooks module; skipped, אומרת שהרשימה דילגה עליו.

הכללים האלה קובעים אילו מזהים בשתי הרשימות נכנסים לתוקף:

• הרשימה מחליפה את ברירת המחדל: כשמגדירים את prependPlugins בהגדרות מנוהלות, ציינו בה את sec-default@builtin כדי להשאיר את השומר המובנה. השומר מובנה ואינו זקוק לרשומת enabledPlugins.
• המזהים שלכם חייבים להיחשב לשלכם: בהגדרות מנוהלות, Claude Code מדלג על מזהה שהתוסף שלו אינו עומד בתנאים של מוד ארגון
• מאגרים לא יכולים להגדיר אותם: Claude Code קורא את שתי ההגדרות מהגדרות מנוהלות, ולעולם לא מקובץ ההגדרות של מאגר. משתמש יכול להגדיר אותן ב-~/.claude/settings.json כדי לסדר את המודים שלו רק במחשב בלי הגדרות מנוהלות, ורק כאשר פרטי הגישה של הסשן אינם /login של Team או Enterprise. בכל מקום אחר, Claude Code מתעלם משני המפתחות בהגדרות המשתמש. רשימה שם לא מוסיפה ולא מסירה את השומר המובנה.

#אכיפת מדיניות עם מוד משלכם

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

בכל פעם שמוד אחר עומד להיטען, המוד שלכם מקבל את הרשימה ש-claude plugin validate מדפיס, באירוע בשם plugin.register. מוד ב-prependPlugins יכול לקרוא את הרשימה הזו ולסרב למוד. הוא יכול גם לטפל בכל קריאת API של מודים לפי שם כדי לתעד או לסרב לקריאה הזו עבור כל מוד אחר. השם הוא המתודה בלי ה-$., כך ש-hook על fs.write רואה כל קריאת $.fs.write.

מוד המדיניות הזה מסרב לכל מוד של משתמש שהקוד שלו קורא ל-$.process.run או ל-$.process.spawn. הוא גם שומר יומן ביקורת, וכותב כל קריאת כלי וכל קובץ שמוד כותב אל יומן הדיבוג. מכיוון שהוא רץ ראשון, היומן מתעד את מה שהתבקש, לפני שכל מוד של משתמש משנה אותו. שמרו אותו כ-acme-guard/hooks/register.js:

// The methods no user's mod may call, each spelled namespace.method
const BLOCKED_CALLS = ['process.run', 'process.spawn']

export function register(on) {
  // Runs each time another mod is about to load
  on('plugin.register', async ($, e, next) => {
    // Keep the calls in that mod's code that are on the blocked list
    const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
    if (e.tier === 'user' && blocked.length > 0) {
      // Returning refuse keeps the mod from loading, and the text is the reason
      return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
    }
    // Let every other mod load
    return next(e)
  })

  // Record each tool call, then let it go ahead unchanged
  on('tool.call', async ($, e, next) => {
    $.ui.log('audit tool.call ' + e.tool, { to: 'debug' })
    return next(e)
  })

  // Record which mod wrote a file, then the path, quoted because the mod chose it
  on('fs.write', async ($, e, next) => {
    $.ui.log('audit fs.write by ' + next.origin.plugin + ' ' + JSON.stringify(e.path), { to: 'debug' })
    return next(e)
  })
}

הקובץ רושם שלושה hooks:

• plugin.register: מחליט אם מוד אחר נטען. הוא מסרב למוד של משתמש שקורא למתודה חסומה, ומעביר כל מוד אחר הלאה.
• tool.call: כותב שורה כגון audit tool.call Bash ליומן הדיבוג עבור כל קריאת כלי, ולא משנה דבר
• fs.write: כותב שורה כגון audit fs.write by reader "/tmp/notes.md" עבור כל קריאת $.fs.write שמוד אחר מבצע, ולא משנה דבר. שם המוד מופיע ראשון והנתיב במרכאות, כך שנתיב שמוד בוחר לא יכול להיחשב לשדה אחר של השורה.

ה-hook plugin.register קורא שני שדות של האירוע:

• e.tier: איפה המוד היה רץ, אחד מבין prepend, user, append או builtin. כל מוד שאדם מתקין הוא user.
• e.uses.calls: מתודות ה-API של המודים שהמוד קורא להן, כל אחת כתובה namespace.method כגון process.run, בלי ה-$. ש-claude plugin validate מדפיס

כאשר משתמש מתקין מוד שקורא ל-$.process.run, המוד לא נטען, וביומן הדיבוג שלו יש שורה שמסתיימת ב-refused by acme-guard: ובסיבה שלכם. הסירוב מגיע גם לתמליל בסשן שטוען מחדש באופן חם ספריית תוסף. כדי לחסום קריאה בלי לסרב למוד כולו, החזירו { deny: 'your reason' } מ-hook על שם הקריאה הזו.

כדי לשלוח את שורות הביקורת למקום שאינו יומן הדיבוג, קראו ל-$.http.fetch מאותם hooks.

סשן יכול לרוץ בלי המוד שלכם. אם חוט העובד שמריץ מודים מותקנים קורס שלוש פעמים, Claude Code פורק כל מוד שאינו מובנה, כולל שלכם, עד שהמשתמש מריץ /reload-plugins או מתחיל סשן חדש. ומשתמש שמתחיל את Claude Code עם --safe-mode רץ בלי מודים מותקנים, כולל שלכם.

יצירת מוד מכסה את הקבצים שמוד צריך. בדיקת מוד מדיניות כוללת קובץ בדיקה למוד המדיניות הזה.

#סירוב למודים כשהבדיקה נכשלת

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

const BLOCKED_CALLS = ['process.run', 'process.spawn']

// The same check as before, moved into a function of its own
async function checkMod($, e, next) {
  const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
  if (e.tier === 'user' && blocked.length > 0) {
    return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
  }
  return next(e)
}

export function register(on) {
  // The handler runs only when checkMod throws or exceeds its time limit
  on('plugin.register', checkMod).catch(async ($, e, next) => {
    // Let your organization's mods and built-in mods load
    if (e.tier !== 'user') return next(e)
    // Refuse the user's mod that couldn't be checked
    return { refuse: 'Acme policy check failed, so this mod was not loaded' }
  })
}

כשהמטפל במקום, מוד שנבדק בזמן שהבדיקה זרקה או חרגה מזמן לא נטען, ושורת הסירוב נושאת את הסיבה השנייה, כמו ב-refused by acme-guard: Acme policy check failed, so this mod was not loaded. המטפל מעביר כל מוד מחוץ לדרגת user אל next(e), כך שבדיקה שנכשלה לא עוצרת את המודים שהארגון מציין. טיפול ב-hook שנכשל מכסה את .catch לאירועים אחרים.

#הצעדים הבאים

• אבטחת תוספים: מה כל תוסף יכול לעשות במחשב של משתמש, ואיך לסקור אחד לפני שהוא מותקן
• סקירת מודים: מהו מוד ואיך הוא משתווה ל-hooks, ל-skills ולשרתי MCP
• הסדר שבו מודים רצים: איך prependPlugins ו-appendPlugins משתלבים עם המודים של המשתמשים
• הגדרות ומשתני סביבה: כל הגדרה ששמה מופיע בדף הזה בטבלה אחת