קלוד קוד מקבל מודים: מה הם משנים, ולמה לבדוק אותם לפני התקנה

ב-1 באוקטובר 2026 אנתרופיק השיקה את המודים של קלוד קוד: פונקציות קטנות ב-TypeScript או ב-JavaScript שרצות בתוך קלוד קוד עצמו ומשנות איך הוא עובד ואיך הוא נראה. מוד יכול לשכתב פרומפט לפני שהוא מגיע למודל, לחסום או לתקן קריאה לכלי, להוסיף חלונית לצד השיחה, או להחליף פיצ’ר מובנה בגרסה משלכם.

המודים נכנסו בגרסה 2.1.287, והם דלוקים כברירת מחדל. הם מגיעים בתוך תוספים (plugins), כך שמתקינים ומשתפים אותם כמו כל תוסף. ויש פסקה אחת בתיעוד שכדאי לקרוא לפני שמתקינים את הראשון, כי היא משנה את מה שידעתם על ההרשאות.

מה מוד יכול לעשות ש-hook לא יכול?

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

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

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

איך מתחילים?

הדרך הקצרה ביותר היא להסתכל על מה שכבר יש. חלק מהפיצ’רים של קלוד קוד הם עכשיו מודים: ‎/diff‎, התמיכה ב-AGENTS.md (מה שמסביר למה הקובץ לפעמים לא נטען), וגם מוד בשם ״You should know״, סוכן צד שעוקב אחרי משימות ארוכות ומתריע על מה שאתם או קלוד עלולים לפספס. הוא כבוי כברירת מחדל, ונדלק כך:

/plugin enable cc-plugin-you-should-know@builtin

לפי ה-changelog, הוא זמין בסשנים מול אנתרופיק ישירות, רק כשהטלמטריה דלוקה.

אנתרופיק מפרסמת גם שלושה מודים לדוגמה במאגר ‎claude-code-playground‎, בלי תמיכה. השימושי ביותר מביניהם הוא ‎blast-radius‎: הוא עוצר פקודה מסוכנת כמו ‎rm -rf‎ או force push, מראה מה היא תשנה, ונותן כפתור להמשיך או לבטל.

איפה זה מסוכן?

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

הנקודה העדינה יותר היא ההרשאות. מוד שמאזין לאירוע ‎tool.check‎ עונה אחרי שכללי ההרשאות וה-hooks שלכם כבר החליטו, והתשובה שלו יכולה להחליף את שלהם. לפי תיעוד ההרשאות:

כללי ask: מוד יכול לאשר קריאה שהייתה אמורה לעצור לשאלה
hook של PreToolUse שחסם: מוד יכול לאשר את הקריאה בכל זאת, אלא אם ה-hook יושב בהגדרות מנוהלות של הארגון
מצב אוטומטי: קריאה שמוד אישר רצה בלי בדיקה של המסווג
כללי deny: כאן הכול תלוי במכונה. במחשב עם הגדרות מנוהלות, או כשמחוברים במסלול Team או Enterprise, כללי deny גוברים על המוד כברירת מחדל, והארגון יכול לשנות את זה. בכל מקום אחר, מוד יכול לאשר קריאה שכלל deny חוסם

כלומר, במחשב אישי בלי הגדרות מנוהלות, עם Pro או Max, כלל deny הוא כבר לא המילה האחרונה ברגע שמותקן מוד שמאשר קריאות. זה אותו עיקרון שמאחורי ״אישור ההרשאות אינו גבול אבטחה״, רק בשכבה עמוקה יותר. דבר אחד מוד לא יכול לעשות: לשנות את מה שחלון ההרשאה עצמו מציג לכם.

איך בודקים מוד לפני שמתקינים?

מורידים את קבצי התוסף, למשל ב-clone של המאגר, ומריצים בטרמינל:

claude plugin validate ./some-mod

שתי שורות בפלט חשובות. ‎hooks:‎ מפרטת לאילו אירועים המוד מאזין, ו-‎calls:‎ מפרטת מה הוא מבקש לעשות: קריאת קבצים, הרצת תהליכים, פנייה לרשת. אם ‎tool.check‎ מופיע ברשימת האירועים, המוד מחליט על הרשאות. אם ‎tool.call‎ או ‎prompt.submit‎ מופיעים, הוא רואה כל קריאה לכלי וכל פרומפט, ויכול לשנות אותם. למוד אין דרך אחרת לגעת בקבצים, בתהליכים או ברשת מלבד ה-API הזה, וקלוד קוד מסרב לטעון מוד שמשתמש בו בצורה שהפקודה לא מצליחה לקרוא. לכן הפלט הוא תמונה אמינה של מה שהמוד מסוגל לעשות.

ואיך מכבים?

שלוש רמות, לפי כמה רוצים לעצור:

מוד אחד: מכבים או מסירים את התוסף שלו בלשונית Installed שב-‎/plugin‎
כל המודים, לסשן אחד: מפעילים את קלוד קוד עם ‎--safe-mode‎, שמשאיר בחוץ גם את שאר ההתאמות האישיות
כל המודים, תמיד: ‎"disableAllHooks": true‎ בקובץ ‎~/.claude/settings.json‎. זה עוצר גם את ה-hooks הרגילים ואת שורת הסטטוס המותאמת

אף אחת מהשלוש לא עוצרת את המודים המובנים. לכל אחד מהם יש מתג משלו ב-‎/plugin‎.

ומה בארגון?

בארגונים ההגנה מגיעה מובנית. מוד בשם ‎sec-default‎ נטען לפני כל מוד שמשתמש מתקין, והמשתמש לא יכול לכבות אותו. הוא שומר על מה שהארגון מנהל: ה-hooks המנוהלים, פרומפט המערכת וה-CLAUDE.md המנוהל, וכברירת מחדל גם את כללי ה-deny. מי שרוצה לחסום מודים של משתמשים לגמרי מגדיר ‎allowManagedModsOnly‎ בהגדרות המנוהלות.

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

שורה תחתונה

המודים מזיזים את הגבול של מה שאפשר לשנות בקלוד קוד: בפעם הראשונה אפשר לשנות את הכלי עצמו, לא רק לנהל אותו מבחוץ, ואפשר לבקש מקלוד לעשות את זה בשבילכם. אבל מוד הוא קוד שרץ כמוכם, ובמחשב אישי הוא יכול לעקוף גם את כללי ה-deny. מתקינים רק ממקור שסומכים עליו, ומריצים קודם ‎claude plugin validate‎.

איך ה-hooks, הסקילים וההרשאות מתחברים יחד: המדריך לשליטה בקלוד קוד. המקורות: Customize Claude Code with mods, Mods overview וManage mods for your organization.