Kimi Code Never Ask: מצבים ופקודות מסוכנות
Markdownבמצב Never Ask, Kimi Code מריץ rm -rf ו-shutdown בלי לשאול. במה שונים 3 המצבים, ואיך אפשר לאסור פקודה מסוכנת ב-config.toml?
קריאת המאמר המלא
ב-Kimi Code, מצב Never Ask (/auto) מאשר הכול אוטומטית: הוא יבצע rm -rf, shutdown ו-reboot בלי לשאול אפילו שאלה אחת. הסוכן שואל לפני הפקודות האלה רק בשני המצבים האחרים, Always Ask ו-Ask When Needed.
אני עובדת ב-Claude Code עם האפשרות „לאפשר הכול” מופעלת; אחרת היינו יושבים ולוחצים: כן, כן, כן. אבל בכל פעם עשירית הסוכן עושה דברים בדרך שלו. בדוגמה היסטורית שתיאר ארטמיי מילר, הסוכן פשוט מחק פעם את מסד הנתונים: הוא החליט שצריך למחוק את כל העניין, ומחק אותו. למרבה המזל, היה גיבוי מלפני 3 ימים.
גם אב טיפוס אישי עלול לחשוף קבצים יקרי ערך ופרטי גישה. השתמשו בעותק מבודד או במכולה עם הרשאות מוגבלות וגיבוי מאומת; במערכות לקוחות תנו לסוכן גם זהות נפרדת למסד הנתונים, עם הגישה הנחוצה בלבד. כך, גם אם הוא ממש רוצה למחוק את מסד הנתונים, הוא לא יכול.
בואו נראה מה עושה כל מצב של Kimi Code, היכן ההגנה פועלת ואיך להגדיר איסור. קדימה.
למידע על השימוש בשירות, ראו את התיעוד של Ailoot.
הנקודה המרכזית
ל-Kimi Code יש 3 מצבים. ברירת המחדל היא Always Ask: קריאת קבצים מתבצעת אוטומטית, ועל כל פעולה אחרת צריך לאשר בנפרד. במצב Ask When Needed (/yolo) עריכות רגילות מאושרות אוטומטית, אבל הסוכן שואל לפני גישה לקבצים שמכילים מפתחות, הפעלת פקודות מסוכנות או יציאה ממצב התכנון. במצב Never Ask (/auto) הוא לא שואל כלום, וההגנה מפני פקודות מסוכנות לא פועלת. מגדירים איסור קבוע באמצעות כלל deny ב-~/.kimi-code/config.toml, ועדיף לא להפעיל Never Ask כשיש גישה למסד נתונים פעיל.
במה שונים 3 המצבים של Kimi Code?
אם כבר התקנתם את Kimi Code, ראיתם את לוח האישור: הסוכן רוצה לערוך קובץ או להריץ פקודה ומחכה ל„כן” שלכם. בעבר המצבים נקראו Manual, YOLO ו-Auto, ולכן הם עדיין משתמשים בפקודות הישנות: /yolo ו-/auto.
Always Ask. מצב ברירת המחדל. הסוכן קורא קבצים בלי לשאול, אבל אתם מאשרים כל עריכה וכל פקודה בנפרד. זה המצב האיטי ביותר.
Ask When Needed. מפעילים באמצעות /yolo. הסוכן מאשר בעצמו עריכות ופקודות רגילות, אבל שואל לפני גישה אל .env (הקובץ שמכיל את הסיסמאות והמפתחות של הפרויקט) ומפתחות SSH של שרת, לפני פקודות מסוכנות כמו shutdown (כיבוי המחשב) ו-rm -rf (מחיקת תיקייה שלמה תוך עקיפת סל האשפה), ולפני יציאה ממצב התכנון. הסוכן יכול גם לשאול אתכם שאלה בעצמו.
Never Ask. מפעילים באמצעות /auto. כל האישורים ניתנים אוטומטית, כולל אישורים לגישה לקבצים רגישים וליציאה ממצב התכנון. הסוכן לא שואל אתכם שאלות ומחליט הכול בעצמו.
מצב התכנון מופעל בנפרד, באמצעות Shift-Tab או /plan: הסוכן כותב תחילה תוכנית ומחכה לאישור שלכם, ואז נוגע בקבצים.
מתי אני עובדת בלי אישורים
ב-Claude Code, האפשרות „לאפשר הכול” מופעלת אצלי כברירת מחדל בכל צ'אט חדש. בלעדיה, כתיבת קוד לפי תחושת בטן אטית מדי. מי שכותב קוד לפי תחושת בטן כבר מבין מעט מאוד, ואז הוא צריך להמשיך ללחוץ על כפתורים: כן, כן, כן, לא, לא, לא.
אבל במצב הזה הסוכן יכול לעשות כל דבר פזיז, כולל למחוק מסד נתונים. אחר כך הוא יגיד „סליחה, אני מתנצל”, אבל לפעמים כבר אי אפשר לתקן את מה שעשה. לכן המצב הזה מיועד לחסרי פחד, והאחריות היא שלכם.
אלה הכללים שלי. בפרויקטים אישיים, בניסויים ובאבות טיפוס, השתמשו במצב ללא אישורים רק בתוך עותק מבודד או מכולה שאין בהם קבצים יקרי ערך או פרטי גישה לייצור, עם הרשאות מוגבלות וגיבוי. היעדר לקוחות אינו מגן על הקבצים האישיים או המפתחות שלכם, וגם את הבידוד צריך לבדוק. אבל אם תפעילו את המצב הזה באותו פרויקט שיש לו גישה לשרת ייצור, הנחיה אחת תספיק כדי שהסוכן ימחק שם את מסד הנתונים במהלך הלילה ויפרס שינויים באתר הפעיל.
למה איסור במילים לא מציל אתכם
אנשים רבים כותבים בהוראות לסוכן „אל תיגע במסד הנתונים”. אל תסמכו על כך שזה יציל אתכם. אתם אומרים לו: חבר, אל תיכנס לכאן. אבל הוא ייכנס בכל זאת וייקח את מה שהוא צריך כשיצטרך. במיוחד Kimi הסינית: היא תפר כל איסור שתגדירו. מודלים אמריקאיים מאומנים הרבה יותר טוב לא לעשות את זה.
אני עדיין משתמשת ב-Kimi בעבודה שלי. Kimi K3 קשוב מאוד; אני משתמשת בו כדי לבדוק פרויקטים לאיתור מפתחות שדלפו ולאסוף מידע. פעם אחת מיציתי את כל המגבלות שלו בתוך כמה ימים. Kimi לא עושה בעיות ועושה כל מה שמבקשים ממנו. לכן צריך בידוד כשעובדים איתו. תיארתי כאן איך בדקתי אותו במשימות שלי.
צריך שני סוגי בידוד:
- רשימת חסימה של פקודות בהגדרות. היא חוסמת קריאות כלי תואמות; תבנית לצורת כתיבה אחת של פקודה אינה גבול מלא מול כלים אחרים או פעולות שקולות. השתמשו בה לצד הרשאות מערכת ההפעלה, המכולה ומסד הנתונים.
- גישה למסד הנתונים לקריאה בלבד. במסד הנתונים הפעיל יש לסוכן משתמש נפרד עם הרשאות לקריאה בלבד. כך, גם במצב Never Ask, הסוכן לא יכול למחוק את מסד הנתונים.
היכן פועלת ההגנה מפני פקודות מסוכנות
ההגנה המובנית של Kimi Code מפני פקודות מסוכנות מופעלת כברירת מחדל. במצבי Always Ask ו-Ask When Needed היא מבקשת אישור לפני shutdown, reboot (הפעלה מחדש) או rm -rf. במצב Never Ask הפקודות האלה מתבצעות בלי לעצור.
יש שני חריגים:
rm -rfפועל בלי לשאול אם הוא מוחק רק את התוכן של תיקיות זמניות/tmpאו/temp(מאז גרסה 0.43.0);- במצב Ask When Needed, Kimi Code לא שואל על פקודות מסוף שאינו יכול לנתח מראש (מאז גרסה 2.0.1).
בגרסה 0.40.0, מצב Auto חסם פקודות מסוכנות; החסימה הוסרה ב-0.41.0.
אפשר להשבית את ההגנה באמצעות dangerous_command_guard = false במקטע [permission] בקובץ ההגדרות ~/.kimi-code/config.toml, או באמצעות המשתנה KIMI_CODE_DANGEROUS_COMMAND_GUARD=false. המפתחים ממליצים לעשות זאת רק במקום שבו פקודות מסוכנות כבר נחסמות באמצעים חיצוניים.
איך להגדיר איסור קבוע ב-Kimi Code
כשהסוכן רוצה לשנות משהו, Kimi Code מציג לוח אישור:
- אישור: השתמשו במקשי החצים וב-
Enter, או לחצו ישירות על1,2או3; - דחייה:
Esc,Ctrl-CאוCtrl-D; - אישור לפגישה הזו: אותו סוג של קריאה מאושר עד סוף הפגישה;
- כללים קבועים: כלל קבוע של allow או deny בקובץ ההגדרות.
כותבים כללים קבועים בקובץ ההגדרות ~/.kimi-code/config.toml, בתוך בלוקים של [[permission.rules]]. Kimi Code בודק אותם לפי הסדר, והכלל הראשון שמתאים חל, לכן הציבו איסורים לפני הרשאות. לכל כלל יש decision: allow (לאשר מיד), deny (לדחות מיד) או ask (לשאול בכל פעם).
איסור על rm -rf ושאלה לפני כל פקודת מסוף אחרת:
toml
[[permission.rules]]
decision = "deny"
pattern = "Bash(rm -rf*)"
[[permission.rules]]
decision = "ask"
pattern = "Bash"
בפקודות מסוף, התבנית מופיעה בסוגריים: Bash(command-pattern); בקריאת קבצים, משתמשים ב-Read(path-pattern). אפשר לאסור כלי MCP, AgentSwarm ואת הכלים שלכם רק לפי שמם המלא.
אם אינכם טכניים ואינכם רוצים לפתוח את קובץ ההגדרות, פשוט הדביקו את ההנחיה הבאה לסוכן: הוא ימצא בעצמו מה צריך להגביל. רק בקשו ממנו לומר תחילה עד כמה זה יאט אתכם. אם אתם רגילים לעבוד בלי אישורים, חלק מהדברים יפסיקו לפעול אחרי הוספת האיסורים. הנה ההנחיה שלי:
Analyze my project and tell me whether you have access to the production server, the staging database and production keys. If you do, configure protection against dangerous commands: prohibit deleting entire folders, commands that irreversibly rewrite the change history, and direct commands to the production database. First show a plan in the format “before - after” and honestly tell me how much this will slow me down.
סקרתי כיצד להגדיר את אותו הדבר ב-Claude Code במאמר נפרד. כדאי לעיין גם במאמר על האופן שבו מצב Auto ב-Claude Code בודק את פעולות הסוכן.
באיזה מצב לבחור
- רוצים לראות כל צעד שהסוכן עושה: Always Ask, מצב ברירת המחדל. מאשרים הכול חוץ מקריאה.
- פרויקט אישי או אב טיפוס ללא לקוחות אמיתיים: התחילו ב-Always Ask או ב-Ask When Needed. שקלו Never Ask רק לעותק מבודד שאפשר להשליך, עם הרשאות מוגבלות וללא נתונים יקרי ערך או מפתחות; הוא אינו נעשה בטוח רק מפני שאין בפרויקט לקוחות.
- פרויקט עם לקוחות אמיתיים וגישה לשרת: אל תפעילו Never Ask. הגדירו איסורי
denyב-config.tomlותנו לסוכן גישה למסד הנתונים לקריאה בלבד.
וגבו את מסד הנתונים במחשב נפרד מהמחשב שעליו נמצא הפרויקט. כללי הבטיחות האחרים מרוכזים במאמר נפרד.
התאימו את מצב האישור להרשאות הגישה של הפרויקט ובדקו היכן נדרשים איסורים.
מקורות
- Kimi Code: אינטראקציה וקלט — שלושת מצבי ההרשאה,
/yolo,/auto, ההגנה מפני פקודות מסוכנות בכל מצב, לוח האישור ומצב Plan. - Kimi Code: קובצי תצורה —
[[permission.rules]], סדר בדיקת הכללים,dangerous_command_guard,KIMI_CODE_DANGEROUS_COMMAND_GUARD, הנתיב אלconfig.toml. - Kimi Code: יומן שינויים — הגרסאות 0.40.0, 0.41.0, 0.43.0 ו-2.0.1: ההגנה מפני פקודות מסוכנות ושינוי שמות המצבים.
הכירו את Ailoot.
פרטים נוספים
שאלות ותשובות: Kimi Code Never Ask: מצבים ופקודות מסוכנות
האם Never Ask בטוח רק משום שאין לפרויקט שלי לקוחות?
לא. הסוכן עדיין יכול להזיק לקבצים אישיים או לחשוף מפתחות. השתמשו בהרשאות מוגבלות, בעותק מבודד שאפשר להשליך או במכולה ובגיבוי לפני שתשקלו מצב ללא אישורים.
האם כלל deny ל-rm -rf מחליף בידוד?
לא. הוא חוסם קריאות כלי תואמות, ולא כל דרך שקולה לשנות קבצים. השאירו נתונים יקרי ערך ופרטי גישה לייצור מחוץ לגישת הסוכן והשתמשו בזהות נפרדת למסד הנתונים עם ההרשאות שהמשימה דורשת בלבד.