בזמן האחרון כשאני מתעסק עם LLM CLI (כמו Codex / Claude Code / Gemini CLI), גיליתי ש״ביצוע אוטומטי״ לא אמור להיות רק עם שתי דרגות: או לשאול בכל צעד, או לשחרר לגמרי. אם ניקח את Codex כדוגמה, הוא מפרק את האוטומציה לשני מצבים שימושיים יותר:
1）אוטומציה מבוקרת: --full-auto（אוטומטי אבל עם גבולות）
הרעיון המרכזי הוא ״משחררים בתוך הפרויקט, בולמים כשחוצים גבול״:
- בתוך סביבת העבודה אפשר לערוך קבצים ולהריץ פקודות אוטומטית, וכך לצמצם אישורים תכופים
- כשמדובר בקבצים מחוץ לסביבת העבודה (כמו
~/.zshrc、/etc/hosts) או בגישה לרשת, זה יעצור ויבקש ממך אישור
מתאים למחשב הפיתוח היומיומי הראשי: יעילות גבוהה, ובו־בזמן נקודות סיכון קריטיות נשארות נשלטות.
2）אוטומציה קיצונית: --dangerously-bypass-approvals-and-sandbox（--yolo）
הרעיון המרכזי הוא ״לעקוף אישורים + לכבות את הסנדבוקס״:
- בלי לשאול, בלי לחסום, כמעט הכול פתוח
- הסיכון הוא לא רק בקוד שיישבר (זה אפשר להחזיר לאחור), אלא בעיקר בפעולות ש־Git לא שולט בהן: הגדרות מערכת, התקנת תוכנה, משיכת תלותים מהאינטרנט וכדומה
מומלץ רק לשימוש קצר בתוך Docker/מכונה וירטואלית/סביבה חד־פעמית, ואז להשמיד אותה; לא להפעיל במחשב הראשי ובסביבת ייצור.
תוספת: לרצות פחות חלונות קופצים לא אומר שצריך לכבות סנדבוקס
אם פשוט מפריעים לך אישורים תכופים, אפשר להשאיר את סנדבוקס ה־workspace ורק להתאים את מדיניות האישורים (למשל: לשאול פחות בתוך הפרויקט, אבל עדיין לחסום כשחוצים גבול).
מסקנה במשפט אחד
ביום־יום משתמשים ב״אוטומציה מבוקרת״, ובניסויים בלבד ב־״YOLO״; אם אפשר להפעיל סנדבוקס—אל תכבה, ואם אפשר להשאיר אישורים—אל תבטל.