דילוג לתוכן
תפריט
צריכים את זה?לאן סוכן יכול להגיע במחשב שלכםאיך זה עובדהשכבות שבין הסוכן למערכת שלכםהשוואהסביבות sandbox מובנות, Docker ומכונות וירטואליותהגדרהפותחים רק את מה שהמשימה צריכהאבטחהמודל האיומים והגבולות שלוהורדהקבצים בינאריים, checksums והערות גרסההתקנה
השוואה

לסוכן שלכם כבר יש sandbox. הוא מכסה חצי אחר.

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

למי שבוחר בין כלים. שש הסיטואציות למעלה עונות על רוב השאלות.

נבדק לאחרונה בתאריך 15 באוקטובר 2026. מוצרים אחרים משתנים מהר, ולכן כל טענה לגביהם מקושרת לתיעוד של היצרן עצמו.

בקצרה

שישה מצבים, תשובה אחת לכל אחד. שאר העמוד מראה את הראיות.

אתם משתמשים ביותר מסוכן אחד

ai-jail: קובץ מדיניות אחד, כל פקודה, התהליך כולו בפנים. התקנה.

אתם משתמשים רק ב-Claude Code

גם sandbox-runtime של Anthropic עוטף את התהליך כולו, בגרסת beta; ai-jail מוסיף תיקיית בית ריקה ורשת סגורה. לכרטיסים.

אתם רוצים את ה-sandbox ואת בקשות האישור של הסוכן עצמו

השאירו אותם דלוקים. הם עובדים בתוך ai-jail. השתמשו בשניהם.

אתם רוצים מדיניות לכל כלי, אישורים בזמן ריצה ויומן ביקורת חתום

בזה nono הולך רחוק יותר, במחיר של שפת מדיניות ו-supervisor. השוואת העטיפות.

אתם סוגרים ב-sandbox מתוך קוד, קריאת כלי אחת בכל פעם

ל-zerobox יש SDKs בשביל זה; הוא משאיר את הקריאה פתוחה, ולא יצאה לו גרסה מאז מאי 2026. השוואת העטיפות.

אתם לא סומכים על הקוד בכלל

מכונה וירטואלית חד-פעמית. כל כלי בעמוד הזה חולק איתכם את הקרנל. Docker, קונטיינרים ומכונות וירטואליות.

איפה עוברת החומה

נכון לזמן הכתיבה, ה-sandbox של Claude Code חל על פקודות shell ועל תהליכי הבן שלהן. כלי הקבצים שלו עוברים דרך מערכת ההרשאות, והתיעוד שלו אומר ששרתי MCP ו-hooks רצים על המארח בלי הגבלה. עם ai-jail הסוכן עצמו עולה בתוך החומה, ולכן גם כל מה שהוא מפעיל נמצא בפנים.

↔ החליקו לצדדים כדי לראות את התרשים המלא

החלק השמאלי מבוסס על התיעוד של Claude Code.

גם Codex מריץ בתוך sandbox את הפקודות שהוא מפעיל ומשאיר את התהליך codex בחוץ. לפי התיעוד שלו, שרתי MCP משתמשים בתהליך או ב-transport משלהם, מחוץ ל-sandbox.

בקשת אישור היא הגנה מסוג אחר

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

↔ החליקו לצדדים כדי לראות את התרשים המלא

בקשות אישור מועילות. הן שלב של בדיקה, ואילו sandbox הוא גבול.

מצבים שמוציאים את האדם מהתמונה

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

סוכןמצבמה היצרן אומר שהוא עושה
Claude Codeautoהכול רץ, ומודל שני בודק את הפעולות במקומכם. התיעוד מגדיר את המסווג הזה כבקרה ברמת הפעולה הבודדת, ולא כגבול בידוד.
Claude CodebypassPermissions, וגם --dangerously-skip-permissionsהכול רץ בלי שום בדיקה. לפי התיעוד, יש להשתמש בו רק בקונטיינרים מבודדים ובמכונות וירטואליות.
Codex CLIמדיניות אישורים neverהסוכן אף פעם לא שואל. מצב ה-sandbox ממשיך לחול. ראו אישורים ואבטחה.
Codex CLIdanger-full-access, או --yoloה-sandbox כבוי. עם --yolo אין גם אישורים.

זה לצד זה

כל מה שכתוב כאן מתאר את התיעוד של כל מוצר נכון לזמן הכתיבה. כשהתיעוד שקראנו לא עונה על שאלה, זה מה שכתוב בתא.

ה-sandbox של Claude Codeה-sandbox של Codex CLIה-sandbox של Gemini CLIai-jail
מה מוסיפה עטיפה סביב הסוכן כולו
מה נמצא בתוך החומהפקודות Bash, PowerShell ו-Monitor ותהליכי הבן שלהן. התהליך claude, כלי הקבצים שלו, שרתי ה-MCP וה-hooks נמצאים בחוץ.הפקודות שהסוכן מפעיל. התהליך codex נמצא בחוץ. לפי התיעוד, שרתי MCP מקומיים ומרוחקים משתמשים בתהליך או ב-transport משלהם, ולכן גם הם בחוץ.תהליך ה-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 לנתיבים כמו **/.env*, וההגדרה המוקשחת של OpenAI עצמה עושה את זה. ברירת המחדל ב-macOS: לא מתועד.פרופיל ברירת המחדל ב-macOS, permissive-open, מתיר קריאה רחבה של קבצים. פרופילים מחמירים יותר הם opt-in.לא. הסוכן מקבל תיקיית בית חדשה וריקה. הדגל --ssh הוא opt-in.
משתני סביבהפקודות שרצות ב-sandbox יורשות כברירת מחדל את סביבת האב, כולל פרטי גישה. עם sandbox.credentials אפשר לחסום או למסך אותם.לא מתועדלא מתועדרשימת היתרים מינימלית של משתני טרמינל, locale ו-toolchain, ובנוסף מפתח ה-API של ה-harness שהופעל, שמועתק כברירת מחדל יחד עם ההתחברות שלו; --no-agent-state עוצר את זה. משתנים אחרים מוסיפים לפי שם עם --env.
פתח מילוט שהמודל יכול להשתמש בוהמודל רשאי לנסות שוב פקודה עם dangerouslyDisableSandbox, והיא עוברת בתהליך ההרשאות הרגיל. ההגדרה allowUnsandboxedCommands: false מכבה את זה.במדיניות on-request הסוכן מבקש לצאת מה-sandbox לצורך עריכות מחוץ ל-workspace או לצורך רשת.לא מתועדאין. אתם קובעים את המדיניות לפני שהסוכן עולה, וקובץ .ai-jail של הפרויקט יכול להדק אותה ולעולם לא לפתוח.
עובד עם כל סוכןרק Claude Codeרק Codexרק Gemini CLIכל פקודה, עם קובץ מדיניות אחד לכל הסוכנים שלכם.
מודל הרשתפרוקסי עם רשימת היתרים לפי דומיין. דומיין חדש מקפיץ בקשת אישור, וכל פקודה עדיין מקבלת אישור משלה. התיעוד מציין שהפרוקסי סומך על שם ה-host שהלקוח שולח, ולכן domain fronting יכול לעקוף אותו.כבויה כברירת מחדל במצב workspace-write. הגדרה אחת מדליקה אותה, ופרוקסי אופציונלי מוסיף כללי allow ו-deny לפי דומיין. לפי התיעוד, הפרוקסי לא מסנן חיבורים לשרתי MCP, חיפוש באינטרנט או את הדפדפן.פרופיל ברירת המחדל מתיר רשת. פרופילים מחמירים יותר ופרופילים עם פרוקסי הם opt-in.שלושה מצבים. ברירת המחדל סגורה, חוץ מה-host של ה-API של סוכן מוכר בשתי הפלטפורמות, וב-Linux כשה-toolchains דלוקים גם רשימה קבועה של registries של חבילות שכוללת את github.com, ולכן git clone ב-HTTPS עובד; --no-network סוגר את שניהם. --allow-host מוסיף hosts ואת תת-הדומיינים שלהם, באכיפה של ה-network namespace ב-Linux או של כלל seatbelt ב-macOS, דרך פרוקסי שפותר כל שם פעם אחת ומחייג לכתובת שבדק. --network פותח הכול. הסינון הוא TCP בלבד, בלי כללים לפי נתיב ובלי בקשות אישור: host שמחוץ לרשימה נדחה, ו---audit-log מתעד את הניסיון. host מורשה זוכה לאמון מלא. ב-Linux, --forward-port מעביר פורט אחד מה-loopback של המארח אל תוך ה-sandbox, בלי שום כלל על מה שעובר בו.
מה סביבות ה-sandbox המובנות עושות טוב יותר
אישור לכל פקודהכן. מצבי הרשאות, plan mode, מודל מסווג ומדיניות ארגונית מנוהלת.כן. מדיניות אישורים, כללים לפי קטגוריה וסוכן בודק אופציונלי.לא מתועדאין. הפקודות הבודדות לא עוברות דרך ai-jail, והוא אף פעם לא שואל.
נתיבים מוגנים בתוך הפרויקטכן. .git/hooks, .git/config, הגדרות .claude, .mcp.json, קובצי rc של ה-shell ועוד נשארים לקריאה בלבד.כן. .git, .agents ו-.codex שנמצאים תחת שורשים פתוחים לכתיבה הם לקריאה בלבד.לא מתועדאין הגנה מובנית. הפרויקט כולו פתוח לכתיבה, כולל .git/, ו-git בצד המארח סומך על מה שהוא מוצא שם. ממסכים או חוסמים נתיבים בעצמכם עם --mask ועם deny_paths. למה .git/ חשוב.
הסתרת סודות מהסוכן בלי לוותר על השימוש בהםמיסוך פרטי גישה יכול להזריק את הסוד האמיתי בפרוקסי. זה דורש הגדרה ניסיונית.לא מתועדלא מתועדכן, מגרסה 2.2, עם --secret KEY=host. ב-sandbox נמצא placeholder, והפרוקסי מכניס את הערך האמיתי רק לבקשות אל אותו host אחד. זה מכסה לקוחות ששולחים HTTP רגיל לפרוקסי בשביל אותו host; במנהרות HTTPS הוא לא נוגע. קובץ ממוסך נשאר קובץ ריק.
פלטפורמותעובד ב-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 permissions, Codex Linux sandbox, Gemini CLI sandbox, Antigravity terminal sandbox, Antigravity permissions, nono security model, zerobox README.

סוכנים אחרים, כרטיס לכל אחד

השתמשו בשניהם

סוכן מוכר לא צריך שיפתחו לו כלום. ההתחברות שלו מעוגנת כברירת מחדל, והפרוקסי המסנן מעביר את ה-host של ה-API של המודל, וב-Linux גם את מאגרי החבילות. כשכלי צריך עוד, מוסיפים hosts עם --allow-host או פותחים את כל הרשת.

ברירת המחדל: API ומאגרים ב-Linux
cd ~/Projects/my-appai-jail claude
פשוט יותר: כל הרשת
ai-jail --network claude

הכלי ai-jail מכיר את ה-host של ה-API של סוכן מוכר ומתיר אותו כברירת מחדל, וב-Linux גם את ה-registries של החבילות. רשימת --allow-host מפורשת מתווספת לברירת המחדל הזו, ולכן ה-host של ה-API נשאר מורשה. ההתחברות מעוגנת כברירת מחדל; --no-agent-state נותן הרצה ללא התחברות. כל הדגלים בעמוד ההגדרה.

↔ החליקו לצדדים כדי לראות את התרשים המלא

החומה החיצונית היא ai-jail. בתוכה, בקשות האישור והכללים של הסוכן ממשיכים לעשות את העבודה שלהם.

מה הבדיקות של הסוכן עצמו ממשיכות לעשות

בקשות אישור, כללי allow ו-deny ו-plan mode הם חלק מתוכנת הסוכן, ולכן הם עובדים בתוך הכלא בדיוק כמו מחוצה לו. הם תופסים את הפקודה שלא הייתם מאשרים.

מה ai-jail מבטיח מתחת לזה

הסוכן, שרתי ה-MCP שלו וה-hooks שלו לא רואים את תיקיית הבית שלכם, את המפתחות שלכם או את הטוקנים שב-shell, ולא משנה מה תאשרו. היוצא מן הכלל היחיד הוא ההתחברות ומפתח ה-API של הסוכן עצמו, שמעוגנים כברירת מחדל כדי שהוא יעלה מחובר. מה שהסוכן יכול לקרוא הוא עדיין יכול לשלוח ל-host של ה-API שלו ולכל host שהתרתם, ולכן מסכו את הסודות שבתוך הפרויקט.

קונטיינרים של Docker, dev containers ומכונות וירטואליות

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

מה מקבליםמה זה עולה
קונטיינר Dockerמערכת קבצים, רשימת תהליכים ורשת משלו. הסוכן רואה רק את מה שאתם מעגנים.צריך לבנות ולתחזק image, ולהתקין בו את ה-toolchains שלכם פעם נוספת. אם מעגנים את ה-socket של Docker, הקונטיינר שקול ל-root על המארח.
Dev containerאותו בידוד כמו של קונטיינר, מתואר בקובץ שהעורך שלכם מבין והצוות יכול לשתף.אותה תחזוקת image, ובנוסף עורך או כלי שמבין את הפורמט.
מכונה וירטואליתקרנל משלה. זה הגבול החזק ביותר כאן, והגבול הנכון לקוד שאתם מאמינים שהוא עוין.האפשרות הכבדה ביותר: מערכת אורחת שצריך להתקין, לעדכן, להקצות לה זיכרון ולהעתיק אליה את הפרויקט.
ai-jailסביבת sandbox סביב פקודה אחת, שמשתמשת בקומפיילרים וב-runtimes שכבר מותקנים אצלכם. בלי image, בלי daemon ובלי root.הוא חולק איתכם את הקרנל, ולכן exploit בקרנל או בדרייבר נמצא מחוץ לגבולות שלו. הוא חלש יותר ממכונה וירטואלית.

התיעוד של ai-jail עצמו מגדיר אותו כשכבה מועילה שלא מחליפה מכונה וירטואלית חד-פעמית. למודל האיומים.

למעריכים: עטיפות ופלטפורמות אחרות

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

הצגת פרטי העטיפות והפלטפורמות

פלטפורמות להרצת סוכנים

NVIDIA OpenShell הוא קטגוריה אחרת: gateway שרץ ברקע, נותן לכל סוכן קונטיינר או MicroVM משלו ומציב מנוע מדיניות לפני הרשת. הכלי ai-jail הוא תהליך אחד שעוטף פקודה אחת ויוצא יחד איתה. הכתוב כאן מבוסס על התיעוד של OpenShell נכון לזמן הכתיבה, עוד לפני גרסה 1.0 שלו.

OpenShellai-jail
מה מריץ את ה-sandboxdaemon של gateway על Docker, Podman, Kubernetes או KVM. הסוכן חי בתוך image של קונטיינר שמגיע עם הכלי.רק הקובץ הבינארי. הסוכן רץ מול הפרויקט שלכם עם הקומפיילרים וה-runtimes שכבר מותקנים במחשב.
רשתחסימה כברירת מחדל. הכללים מתאימים תוכנית, host ופורט, עם בדיקה אופציונלית של methods, נתיבים וכלי MCP. endpoint שנדחה אפשר לאשר מצד המפעיל.כבויה, מסוננת לפי host, או פתוחה. הסינון הוא גדר של namespace ופרוקסי CONNECT. הוא רואה hosts ופורטים ולא תוכן, ו-host מורשה זוכה לאמון מלא. גם פורט loopback של המארח שמועבר עם --forward-port זוכה לאמון מלא, בלי שום כלל עליו.
פרטי גישהמתווכים דרך ה-gateway ומוזרקים לכל בקשה בנפרד, ואף פעם לא נכתבים לדיסק של ה-sandbox.סביבתיים. ההתחברות של ה-harness עצמו מעוגנת כברירת מחדל, לקריאה וכתיבה, ומה שאתם מעבירים עם --env או --env-from-file גלוי לכל מה שרץ בפנים; --no-agent-state נותן הרצה ללא התחברות. פרטי גישה של כלים (--github, --aws, --kube, --gcloud, --docker-config) הם עיגונים לקריאה בלבד ב-opt-in, והתיעוד אומר במפורש שקריאה בלבד לא מונעת שימוש בהם.
תקרת הבידודדרייבר MicroVM נותן גבול אמיתי של מכונה וירטואלית, וסביבות sandbox יכולות לעצור, לעלות מחדש ולשמור את ה-workspace שלהן.חולק את הקרנל שלכם וחד-פעמי בכוונה. לקוד עוין, התיעוד שלו עצמו אומר להשתמש במכונה וירטואלית חד-פעמית.
macOSרץ בתוך מכונת ה-Linux של Docker Desktop. המארח של macOS נמצא מחוץ למדיניות.פרופילי seatbelt מקוריים שנוצרים על המארח.
טלמטריה ויציבותטלמטריה אנונימית דלוקה כברירת מחדל, עם אפשרות לכבות. פורמט המדיניות עדיין משתנה.בלי טלמטריה. כל גרסה חדשה ממשיכה לקרוא את ההגדרות שגרסאות ישנות כתבו, ובדיקות אוכפות את זה. שתי ביקורות קוד בלתי תלויות בספטמבר 2026, שפורסמו בריפוזיטורי, הובילו לתיקונים של גרסה 2.4.0.

ההשוואה בריפוזיטורי של ai-jail, docs/openshell-comparison.md, כתובה לשני הכיוונים, ומשם הגיעה רשימת ה-hosts המורשים.

שאלות על הרצה משולבת

כדאי לכבות את ה-sandbox ואת בקשות האישור של הסוכן עצמו?
השאירו את בקשות האישור ואת הכללים. הם בודקים פקודות בודדות, דבר ש-ai-jail אף פעם לא עושה. ה-sandbox של הסוכן ברמת מערכת ההפעלה הוא עניין אחר ב-Linux: קריאות המערכת ש-sandbox מקונן של bubblewrap צריך חסומות בתוך ai-jail, והתיעוד שלו לא אומר שהשילוב עובד. אם הסוכן מדווח בתוך הכלא שה-sandbox שלו לא זמין, הכלא עדיין שם.
האם ai-jail בטוח יותר מ-Docker?
שניהם גבול מאותו סוג. שניהם חולקים איתכם את הקרנל, ואף אחד מהם הוא לא מכונה וירטואלית. בכלא של ai-jail הכול מתחיל סגור, ולא צריך image, daemon או root. קונטיינר מעגן את מה שאתם אומרים לו, ו-socket מעוגן של Docker שקול ל-root על המארח. לקוד שאתם מאמינים שהוא עוין, השתמשו במכונה וירטואלית חד-פעמית.
במה רשימת ה-hosts המורשים שונה מזו של הסוכנים עצמם?
הפרוקסי של הסוכנים הוא משהו שהתוכנית ב-sandbox צריכה לבחור להשתמש בו. ב-ai-jail הגדר היא הקרנל: ב-Linux ה-sandbox שומר על network namespace פרטי שהיציאה היחידה ממנו היא הפרוקסי, וב-macOS כלל seatbelt מתיר תעבורה יוצאת רק לפורט של הפרוקסי, ולכן תוכנית שמתעלמת מ-http_proxy לא מגיעה לשום מקום. הסינון לא מכסה UDP, ולכן DNS בתוך ה-sandbox נכשל ב-Linux וה-resolver של המערכת לא מגודר ב-macOS. הוא גם לא בודק את תוכן החיבור, ולכן host מורשה זוכה לאמון מלא. אי אפשר לשלב אותו עם --network או עם --browser.
אני משתמש רק ב-Claude Code. אני עדיין צריך את ai-jail?
נכון לזמן הכתיבה יש לכם שלוש אפשרויות. ה-sandbox המובנה מכסה פקודות shell. החבילה @anthropic-ai/sandbox-runtime של Anthropic, שנמצאת ב-beta research preview, עוטפת את התהליך כולו. גם ai-jail עוטף את התהליך כולו, מתחיל כשתיקיית הבית ומשתני הסביבה סגורים, ומחיל את אותה מדיניות על כל סוכן אחר שתנסו בהמשך. ראו את ההשוואה של Anthropic בין סביבות sandbox.

שימו את הסוכן מאחורי סורגים

כל ai-jail הוא קובץ בינארי אחד, בלי daemon ובלי root. מוסיפים מילה אחת לפני הפקודה שאתם מריצים ממילא.

terminal
brew tap akitaonrails/tap && brew install ai-jailai-jail claude