לסוכן שלכם כבר יש sandbox. הוא מכסה חצי אחר.
סביבות sandbox מובנות ובקשות אישור משגיחות על הפקודות שהמודל מריץ. לעומתן, ai-jail קובע מה תוכנת הסוכן כולה יכולה לראות במחשב שלכם. השניים עובדים יחד.
נבדק לאחרונה בתאריך 21 בספטמבר 2026. מוצרים אחרים משתנים מהר, ולכן כל טענה לגביהם מקושרת לתיעוד של היצרן עצמו.
איפה עוברת החומה
נכון לזמן הכתיבה, ה-sandbox של Claude Code חל על פקודות shell ועל תהליכי הבן שלהן. כלי הקבצים שלו עוברים דרך מערכת ההרשאות, והתיעוד שלו אומר ששרתי MCP ו-hooks רצים על המארח בלי הגבלה. עם ai-jail הסוכן עצמו עולה בתוך החומה, ולכן גם כל מה שהוא מפעיל נמצא בפנים.
גם Codex מריץ בתוך sandbox את הפקודות שהוא מפעיל ומשאיר את התהליך codex בחוץ. התיעוד שלו לא אומר איפה רצים שרתי MCP מקומיים.
בקשת אישור היא הגנה מסוג אחר
בקשת אישור שואלת בן אדם, ובן אדם אפשר להלחיץ או להטעות. לעומת זאת, sandbox שואל את הקרנל, והקרנל נותן את אותה תשובה בכל פעם.
מצבים שמוציאים את האדם מהתמונה
נכון לזמן הכתיבה, לכל אחד מהסוכנים האלה יש מצב שמפסיק לשאול. כשבקשת האישור נעלמת, ה-sandbox הוא ההגנה היחידה שנשארת, אם הוא בכלל דלוק.
| סוכן | מצב | מה היצרן אומר שהוא עושה |
|---|---|---|
| Claude Code | auto | הכול רץ, ומודל שני בודק את הפעולות במקומכם. התיעוד מגדיר את המסווג הזה כבקרה ברמת הפעולה הבודדת, ולא כגבול בידוד. |
| Claude Code | bypassPermissions, וגם --dangerously-skip-permissions | הכול רץ בלי שום בדיקה. לפי התיעוד, יש להשתמש בו רק בקונטיינרים מבודדים ובמכונות וירטואליות. |
| Codex CLI | מדיניות אישורים never | הסוכן אף פעם לא שואל. מצב ה-sandbox ממשיך לחול. ראו אישורים ואבטחה. |
| Codex CLI | danger-full-access, או --yolo | ה-sandbox כבוי. עם --yolo אין גם אישורים. |
זה לצד זה
כל מה שכתוב כאן מתאר את התיעוד של כל מוצר נכון לזמן הכתיבה. כשהתיעוד שקראנו לא עונה על שאלה, זה מה שכתוב בתא.
| ה-sandbox של Claude Code | ה-sandbox של Codex CLI | ה-sandbox של Gemini CLI | ai-jail | |
|---|---|---|---|---|
| מה מוסיפה עטיפה סביב הסוכן כולו | ||||
| מה נמצא בתוך החומה | פקודות Bash, PowerShell ו-Monitor ותהליכי הבן שלהן. התהליך claude, כלי הקבצים שלו, שרתי ה-MCP וה-hooks נמצאים בחוץ. | הפקודות שהסוכן מפעיל. התהליך codex נמצא בחוץ. שרתי MCP מקומיים: לא מתועד. | תהליך ה-CLI כולו, או רק כלי ה-shell והכתיבה כשמגדירים security.toolSandboxing. | עץ התהליכים כולו: הסוכן, כלי הקבצים שלו, שרתי ה-MCP, ה-hooks וכל פקודה. |
| דלוק כברירת מחדל | לא. מדליקים אותו עם /sandbox או עם sandbox.enabled. כשחסרה תלות הוא מזהיר ומריץ פקודות בלי sandbox, אלא אם הגדרתם sandbox.failIfUnavailable. | כן. מצב ברירת המחדל הוא workspace-write. | מדליקים אותו עם -s, עם GEMINI_SANDBOX או עם tools.sandbox. | דלוק בכל פעם שמעלים את הסוכן דרכו. אם ההגדרות לא תקינות, הוא מסרב לעלות. |
האם קוד שרץ ב-sandbox יכול לקרוא את ~/.ssh כברירת מחדל? | כן. לפי התיעוד, ברירת המחדל עדיין מתירה לקרוא קובצי פרטי גישה כמו ~/.aws/credentials ו-~/.ssh/. כללי deny הם opt-in. | ב-Linux כן, כי כל מערכת הקבצים מעוגנת שם לקריאה בלבד. רשומות deny הן opt-in. ברירת המחדל ב-macOS: לא מתועד. | פרופיל ברירת המחדל ב-macOS, permissive-open, מתיר קריאה רחבה של קבצים. פרופילים מחמירים יותר הם opt-in. | לא. הסוכן מקבל תיקיית בית חדשה וריקה. הדגל --ssh הוא opt-in. |
| משתני סביבה | פקודות שרצות ב-sandbox יורשות כברירת מחדל את סביבת האב, כולל פרטי גישה. עם sandbox.credentials אפשר לחסום או למסך אותם. | לא מתועד | לא מתועד | רשימת היתרים מינימלית של משתני טרמינל, locale ו-toolchain. משתנים אחרים מוסיפים לפי שם עם --env. |
| פתח מילוט שהמודל יכול להשתמש בו | המודל רשאי לנסות שוב פקודה עם dangerouslyDisableSandbox, והיא עוברת בתהליך ההרשאות הרגיל. ההגדרה allowUnsandboxedCommands: false מכבה את זה. | במדיניות on-request הסוכן מבקש לצאת מה-sandbox לצורך עריכות מחוץ ל-workspace או לצורך רשת. | לא מתועד | אין. אתם קובעים את המדיניות לפני שהסוכן עולה, וקובץ .ai-jail של הפרויקט יכול להדק אותה ולעולם לא לפתוח. |
| עובד עם כל סוכן | רק Claude Code | רק Codex | רק Gemini CLI | כל פקודה, עם קובץ מדיניות אחד לכל הסוכנים שלכם. |
| מה סביבות ה-sandbox המובנות עושות טוב יותר | ||||
| מודל הרשת | פרוקסי עם רשימת היתרים לפי דומיין. דומיין חדש מקפיץ בקשת אישור. התיעוד מציין ש-domain fronting יכול לעקוף אותו. | כבויה כברירת מחדל במצב workspace-write. הגדרה אחת מדליקה אותה, ופרוקסי אופציונלי מוסיף כללי allow ו-deny לפי דומיין. | פרופיל ברירת המחדל מתיר רשת. פרופילים מחמירים יותר ופרופילים עם פרוקסי הם opt-in. | הכול או כלום. הרשת כבויה כברירת מחדל, ו---network פותח את כולה. אין סינון לפי דומיין, בכוונה. |
| אישור לכל פקודה | כן. מצבי הרשאות, plan mode, מודל מסווג ומדיניות ארגונית מנוהלת. | כן. מדיניות אישורים, כללים לפי קטגוריה וסוכן בודק אופציונלי. | לא מתועד | אין. הפקודות הבודדות לא עוברות דרך ai-jail, והוא אף פעם לא שואל. |
| נתיבים מוגנים בתוך הפרויקט | כן. .git/hooks, .git/config, הגדרות .claude, .mcp.json, קובצי rc של ה-shell ועוד נשארים לקריאה בלבד. | כן. .git, .agents ו-.codex שנמצאים תחת שורשים פתוחים לכתיבה הם לקריאה בלבד. | לא מתועד | אין הגנה מובנית. הפרויקט כולו פתוח לכתיבה. ממסכים או חוסמים נתיבים בעצמכם עם --mask ועם deny_paths. |
| הסתרת סודות מהסוכן בלי לוותר על השימוש בהם | מיסוך פרטי גישה יכול להזריק את הסוד האמיתי בפרוקסי. זה דורש הגדרה ניסיונית. | לא מתועד | לא מתועד | לא. קובץ ממוסך הוא קובץ ריק. |
| פלטפורמות | עובד ב-macOS, ב-Linux וב-WSL2. לא עובד ב-Windows מקורי או ב-WSL1. | עובד ב-macOS, ב-Linux, ב-WSL2 וב-Windows מקורי. | מנגנון Seatbelt ב-macOS, Docker או Podman, gVisor, LXC (ניסיוני) ו-Windows מקורי. | עובד ב-Linux וב-macOS. ב-Windows רק דרך WSL2. |
| התקנה | מגיע עם הסוכן. ב-Linux הוא צריך את bubblewrap ואת socat. | מגיע עם הסוכן. | מגיע עם הסוכן. ה-backends מבוססי הקונטיינר צריכים Docker או Podman. | קובץ בינארי נפרד. ב-Linux הוא צריך את bubblewrap. |
מקורות: Claude Code sandboxing, Claude Code sandbox environments, Codex approvals and security, Codex Linux sandbox, Gemini CLI sandbox.
השתמשו בשניהם
כשהרשת כבויה, סוכן שרץ מול הענן לא יכול להגיע ל-API של המודל שלו. בפועל פותחים שני דברים: את הרשת ואת ההתחברות של הסוכן.
cd ~/Projects/my-appai-jail --network --agent-state claude
מה הבדיקות של הסוכן עצמו ממשיכות לעשות
בקשות אישור, כללי allow ו-deny ו-plan mode הם חלק מתוכנת הסוכן, ולכן הם עובדים בתוך הכלא בדיוק כמו מחוצה לו. הם תופסים את הפקודה שלא הייתם מאשרים.
מה ai-jail מבטיח מתחת לזה
הסוכן, שרתי ה-MCP שלו וה-hooks שלו לא רואים את תיקיית הבית שלכם, את המפתחות שלכם או את הטוקנים שב-shell, ולא משנה מה תאשרו. מה שהסוכן יכול לקרוא הוא עדיין יכול לשלוח, ולכן מסכו את הסודות שבתוך הפרויקט.
קונטיינרים של Docker, dev containers ומכונות וירטואליות
גם אלה תשובות טובות, ומכונה וירטואלית היא תשובה חזקה יותר. ההבדל ביניהן הוא במה שצריך לבנות ולעדכן.
| מה מקבלים | מה זה עולה | |
|---|---|---|
| קונטיינר Docker | מערכת קבצים, רשימת תהליכים ורשת משלו. הסוכן רואה רק את מה שאתם מעגנים. | צריך לבנות ולתחזק image, ולהתקין בו את ה-toolchains שלכם פעם נוספת. אם מעגנים את ה-socket של Docker, הקונטיינר שקול ל-root על המארח. |
| Dev container | אותו בידוד כמו של קונטיינר, מתואר בקובץ שהעורך שלכם מבין והצוות יכול לשתף. | אותה תחזוקת image, ובנוסף עורך או כלי שמבין את הפורמט. |
| מכונה וירטואלית | קרנל משלה. זה הגבול החזק ביותר כאן, והגבול הנכון לקוד שאתם מאמינים שהוא עוין. | האפשרות הכבדה ביותר: מערכת אורחת שצריך להתקין, לעדכן, להקצות לה זיכרון ולהעתיק אליה את הפרויקט. |
| ai-jail | סביבת sandbox סביב פקודה אחת, שמשתמשת בקומפיילרים וב-runtimes שכבר מותקנים אצלכם. בלי image, בלי daemon ובלי root. | הוא חולק איתכם את הקרנל, ולכן exploit בקרנל או בדרייבר נמצא מחוץ לגבולות שלו. הוא חלש יותר ממכונה וירטואלית. |
התיעוד של ai-jail עצמו מגדיר אותו כשכבה מועילה שלא מחליפה מכונה וירטואלית חד-פעמית. למודל האיומים.
שאלות על הרצה משולבת
כדאי לכבות את ה-sandbox ואת בקשות האישור של הסוכן עצמו?
האם ai-jail בטוח יותר מ-Docker?
למה אין רשימת היתרים לרשת לפי דומיין?
IPAddressAllow=, או קונטיינר או מכונה וירטואלית שמחזיקים את ה-network namespace.אני משתמש רק ב-Claude Code. אני עדיין צריך את ai-jail?
@anthropic-ai/sandbox-runtime של Anthropic, שנמצאת ב-beta research preview, עוטפת את התהליך כולו. גם ai-jail עוטף את התהליך כולו, מתחיל כשתיקיית הבית ומשתני הסביבה סגורים, ומחיל את אותה מדיניות על כל סוכן אחר שתנסו בהמשך. ראו את ההשוואה של Anthropic בין סביבות sandbox.שימו את הסוכן מאחורי סורגים
כל ai-jail הוא קובץ בינארי אחד, בלי daemon ובלי root. מוסיפים מילה אחת לפני הפקודה שאתם מריצים ממילא.
brew tap akitaonrails/tap && brew install ai-jailai-jail claude