בניית ארגז חול בטוח ויעיל להפעלת Codex ב-Windows

כשהצטרפתי לצוות ההנדסה של Codex בספטמבר 2025, עדיין לא מומש ארגז חול ב-Codex ל-Windows. לכן, משתמשי Windows נאלצו לבחור בין שתי אפשרויות לא מוצלחות בעת השימוש בסוכני התכנות של OpenAI:

1. לאשר כמעט כל פקודה שסוכן תכנות רצה להריץ (אפילו פקודות קריאה) — תהליך לא יעיל ומעיק. אחד היתרונות המרכזיים של Codex הוא שלא צריך לעשות את כל העבודה המייגעת בעצמכם.

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

Codex⁠, סוכן התכנות שלנו, פועל במחשבים הניידים של מפתחים — דרך ה-CLI, התוסף לסביבת הפיתוח או האפליקציה למחשב. הוא מנהל שיחה בין אדם שיושב מול המקלדת לבין מודל שפועל בענן ומבצע הסקה.

כברירת מחדל, Codex פועל עם הרשאות של משתמש אמיתי, כלומר הוא יכול לעשות כל מה שהמשתמש יכול לעשות. זו יכולת עוצמתית שעלולה להיות מסוכנת. מודל התכנות עשוי להורות ל-harness להריץ פקודות מקומיות — מהרצת בדיקות, דרך קריאה או עריכה של קובץ ועד יצירת ענף ב-Git. לכן, מצב ברירת המחדל של Codex מנסה למצוא את האיזון הנכון בין יעילות לבטיחות. מצב ברירת המחדל הזה מאפשר ל-Codex לקרוא קבצים כמעט מכל מקום ולכתוב קבצים בתוך סביבת העבודה שלכם (כלומר, התיקייה שממנה אתם מריצים את Codex), ללא גישה לאינטרנט אלא אם תבקשו זאת במפורש. כדי להגביל באופן אוטומטי את כתיבת הקבצים ואת הגישה לרשת לגבולות בטוחים, Codex זקוק לסביבת ארגז חול שאוכפת את ההגבלות האלה בפועל.

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

כדי לממש ארגז חול יעיל, Codex זקוק ליכולות בידוד שנאכפות על ידי מערכת ההפעלה של המחשב. מערכות הפעלה מסוימות מספקות כלים שעושים זאת היטב (למשל, Seatbelt ב-macOS, או seccomp ו-bubblewrap ב-Linux); אבל Windows לא מספקת כיום יכולת כזו באופן מובנה.

כדי שהשימוש ב-Codex ב-Windows יהיה בטוח ונעים כמו בשאר הפלטפורמות, היינו צריכים לממש ארגז חול משלנו.

Windows מציעה כמה כלים ומנגנונים בסיסיים לבידוד. אף שאף אחד מהם לא ענה בדיוק על הדרישות שלנו, בחנו כמה פתרונות אפשריים — ובהם AppContainer, ‏Windows Sandbox ותיוג של Mandatory Integrity Control.

AppContainer

• מה זה: AppContainer הוא ארגז החול המובנה של Windows — מודל בידוד מבוסס יכולות, שנבנה עבור אפליקציות שיודעות מראש בדיוק לאילו משאבים הן צריכות לגשת.

• למה כן: פתרון מושך משום שהוא מספק גבול אמיתי שנאכף על ידי מערכת ההפעלה, ולא רק הגבלות שעושות כמיטב יכולתן.

• למה לא: Codex אינו אפליקציה אחת עם תחום פעולה מצומצם ומוגדר היטב. הוא מפעיל תהליכי פיתוח פתוחים ומגוונים: מעטפות פקודות, Git, ‏Python, מנהלי חבילות, כלי בנייה וכל קובץ בינארי אחר שהסוכן מחליט שהוא צריך. בפועל, זה הפך את AppContainer לפתרון שאינו מתאים לבעיה. הוא סיפק בידוד חזק, אבל לסוג משימות מצומצם בהרבה מ״לאפשר לסוכן לעבוד כמו מפתח״.

Windows Sandbox

• מה זה: Windows Sandbox היא מכונה וירטואלית קלת משקל וחד-פעמית של Microsoft. מקבלים שולחן עבודה נקי של Windows עם בידוד חזק, וכל מה שעושים בתוכו נעלם עם סיום ההפעלה.

• למה כן: פתרון מעניין מסיבות ברורות — הוא תואם למגוון תוכנות רחב בהרבה מ-AppContainer, ומבחינת אבטחה הוא מספק מעטפת בידוד חזקה הרבה יותר.

• למה לא: Codex צריך לפעול ישירות על עותק הקוד, הכלים והסביבה האמיתיים של המשתמש, ולא בתוך שולחן עבודה נפרד וחד-פעמי שדורש הקמה וגישור בין המחשב המארח לאורח. הייתה גם בעיית מוצר בסיסית: Windows Sandbox כלל אינה זמינה במהדורות Windows Home.

תיוג רמות שלמות באמצעות Mandatory Integrity Control ‏(MIC)

• מה זה: ב-Windows יש מושג שנקרא ״רמות שלמות״, כמו נמוכה, בינונית וגבוהה, שקובע עד כמה המערכת נותנת אמון באובייקטים ובתהליכים. הכלל הבסיסי הוא שתהליך ברמת שלמות נמוכה יותר אינו יכול לכתוב לאובייקט ברמת שלמות גבוהה יותר, גם אם רשימת בקרת הגישה (ACL) הרגילה הייתה מאפשרת זאת. למשל, תהליך ברמת שלמות נמוכה נחשב לפחות מהימן, ולכן Windows חוסמת אותו מלכתוב לאובייקטים רגילים ברמת שלמות בינונית, אלא אם התיוג שלהם שונה במפורש כדי לאפשר זאת.

• למה כן: על הנייר, MIC נראה אלגנטי — להריץ את Codex ברמת שלמות נמוכה, לתייג מחדש את תיקיות השורש המותרות לכתיבה כבעלות רמת שלמות נמוכה, ולתת ל-Windows לאכוף איסור כתיבה בכל מקום אחר. כך היינו מקבלים דרך פעולה ללא הרשאות מנהל, שמאחוריה מנגנון אמיתי של מערכת ההפעלה.

• למה לא: בדומה לרשימות ACL, תוויות שלמות משנות את מערכת הקבצים האמיתית של המחשב המארח, ובמקרה הזה השינוי במשמעות ההרשאות רחב במיוחד. סימון סביבת עבודה כבעלת רמת שלמות נמוכה אינו אומר רק ״Codex יכול לכתוב כאן״. הוא אומר שתהליכים ברמת שלמות נמוכה באופן כללי יכולים לכתוב שם. במחשב פיתוח אמיתי, זה הופך את עותק הקוד של המשתמש ליעד כתיבה לכל תהליך ברמת שלמות נמוכה במחשב המארח. זה מסוכן הרבה יותר מהענקת הרשאות ACL ממוקדות בקפידה למימוש אחד של ארגז חול. גם אם כלי פיתוח ברמת שלמות בינונית ממשיכים לעבוד, מודל האמון הבסיסי של סביבת העבודה משתנה באופן שקשה לתחום את השפעתו וקשה עוד יותר להצדיק.

לאחר שבחנו את כל האפשרויות ופסלנו אותן, התחלנו לתכנן פתרון משלנו שיספק למשתמשי Windows חוויית Codex טובה.

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

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

SID, או מזהה אבטחה, הוא הזהות שאליה Windows משייכת הרשאות. לכל משתמש יש SID, לקבוצות יש מזהי SID, ואפילו כל הפעלת כניסה למערכת מקבלת SID משלה. לדוגמה, להפעלת כניסה נוכחית למערכת עשוי להיות SID כמו S-1-5-5-X-Y. ה-SID שהוקצה לקבוצת המנהלים המקומיים עשוי להיות S-1-5-32-544.

Windows מאפשרת גם ליצור מזהי SID סינתטיים שאינם תואמים למשתמש אמיתי, אך עדיין יכולים להופיע ברשימות ACL (רשימות בקרת גישה), המגדירות מי יכול לקרוא, לכתוב או להריץ קבצים או תיקיות מסוימים. לכן מזהי SID הם אבן בניין שימושית לארגז החול שלנו: אפשר ליצור מזהים לשימוש בלעדי של ארגז החול של Codex, בלי להפריע לשום דבר אחר במחשב.

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

כדי שפעולת כתיבה תצליח, שתי בדיקות חייבות לעבור:

1. לזהות המשתמש הרגילה (״הבעלים״ של האסימון) חייבת להיות הרשאה לבצע אותה

2. גם לפחות SID אחד ברשימת מזהי ה-SID המוגבלים של האסימון חייב לקבל הרשאת גישה

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

בעזרת מזהי SID ואסימונים מוגבלי כתיבה, ארגז החול שלנו ללא הרשאות מוגברות פעל כך:

1. תהליך ההקמה של ארגז החול יצר SID סינתטי בשם sandbox-write.

2. ל-SID בשם sandbox-write הוענקו הרשאות כתיבה, הרצה ומחיקה במיקומים הבאים:

   1. תיקיית העבודה הנוכחית

   2. כל תיקייה נוספת תחת writable_roots שהוגדרה ב-config.toml.

3. תהליך ההקמה של ארגז החול שלל במפורש מאותו SID הרשאת כתיבה למיקומים מסוג ״קריאה בלבד בתוך אזור מותר לכתיבה״, כגון:

   1. <cwd>/.git

   2. <cwd>/.codex

   3. <cwd>/.agents

4. Codex הפעיל פקודות תחת אסימון מוגבל כתיבה שרשימת מזהי ה-SID המוגבלים שלו כוללת את Everyone, את ה-SID של הפעלת הכניסה הנוכחית למערכת ואת ה-SID הסינתטי sandbox-write.

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

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

משחומת האש של Windows ירדה מהפרק, הגבלנו את מה שהיה בשליטתנו. ניסינו להגדיר את סביבת תהליכי הבן כך שתחסום כברירת מחדל פעילות של כלי הרשת שמפתחים משתמשים בהם בפועל. כך, פקודות Git, מתקיני חבילות וכדומה ייכשלו בארגז החול, והמשתמש יצטרך לאשר כל פעולה שפונה לאינטרנט. הרעיון היה לשבש את נתיבי היציאה הברורים: להפנות תעבורה שמכבדת הגדרות פרוקסי ל-endpoint לא פעיל, לעשות אותו דבר לתעבורת HTTP(S) של Git, ולגרום ל-Git דרך SSH להיכשל מיד. בנוסף, הוספנו תיקייה קטנה בשם denybin לתחילת PATH ושינינו את הסדר ב-PATHEXT, כך שסקריפטים חלופיים מינימליים של SSH ו-SCP יימצאו לפני הקבצים הבינאריים האמיתיים.

לדוגמה, הנה כמה מהערכים שהגדרנו במשתני הסביבה כדי להגביל גישה לרשת:

• HTTPS_PROXY=http://127.0.0.1:9

• ALL_PROXY=http://127.0.0.1:9

• GIT_HTTPS_PROXY=http://127.0.0.1:9

• NO_PROXY=localhost,127.0.0.1,::1

• GIT_SSH_COMMAND=cmd /c exit 1

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

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

• מהירות ההקמה: החלת רשימות ACL על סביבת העבודה עלולה להיות יקרה, בהתאם למבנה התיקיות שלה.

• השפעה על המערכת: החלנו רשימות ACL אמיתיות על מערכת המפתח. עם זאת, השינוי אינו פולשני במיוחד, משום שכל הרשימות שהוחלו מתייחסות ל-SID סינתטי שנוצר במיוחד ומשמש רק את ארגז החול.

• כללי פעולה שקשה לשנות: ההסתמכות על רשימות ACL להגבלות ברמת הקבצים הופכת שינוי של כללי הפעולה של ארגז החול ליקר ומורכב. בעוד שב-macOS אפשר לשנות באופן דינמי את אופן יצירת קובץ ה-.sbpl שמגדיר את Seatbelt, בארגז החול של Windows התאמת רשימות ה-ACL עשויה לדרוש פעולה איטית ועתירת משאבים.

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

שלוש הבעיות הראשונות טבועות במימוש מותאם אישית של ארגז חול שגמיש מספיק לתהליכי עבודה אג'נטיים. אבל הסיפור של חסימת הגישה לרשת היה שונה.

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

כדי לשפר את חסימת הגישה לרשת, רצינו להשתמש בחומת האש של Windows, שמאפשרת לנו לחסום תעבורת רשת יוצאת עבור משתמשים או תוכנות. לצערנו, לא הצלחנו ליצור כלל חומת אש יעיל שיחול רק על הפקודות שמפעיל ה-harness של Codex, מכמה סיבות:

• Windows אינה מאפשרת להתאים כלל חומת אש לזהות שאינה הזהות הראשית של אסימון מוגבל. כלומר, לא יכולנו להחיל כלל חומת אש על ״כל אסימון שכולל את ה-SID הסינתטי שלנו ברשימת מזהי ה-SID המוגבלים שלו״.

• אמנם יכולנו ליצור כלל חומת אש שמתאים לקובץ בינארי מסוים, אבל זה היה מאפשר לנו להגביל תקשורת רק עבור codex.exe עצמו. הכלל לא היה חל על התהליכים שהסוכן מפעיל מטעם המשתמש, כמו תהליכי Git או Python.

• גם קריטריונים אחרים להתאמת כללי חומת אש לא התאימו לצורך. בתכנון ללא הרשאות מוגברות, כללים ברמת המשתמש עדיין התאימו למשתמש Windows האמיתי, ולא רק לתהליך הבן המוגבל. כללים לפי נתיב התוכנה היו גורפים מדי: הם יכלו לחסום את codex.exe או את python.exe באופן כללי, אבל לא רק את ההפעלה המסוימת הזו של python.exe בתוך ארגז החול. גם כללים המבוססים על יציאות או כתובות ייצגו מדיניות שונה לחלוטין מזו שנדרשה. למשל, לא רצינו לחסום את יציאה 443; רצינו לחסום כל גישה יוצאת של עץ התהליכים המוגבל המסוים הזה.

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

הגרסה הבאה של ארגז החול, שהיא המימוש הנוכחי שלנו, דורשת הגברה להרשאות מנהל בזמן ההקמה. לכן אני מכנה אותה ״ארגז החול עם הרשאות מוגברות״. בנקודה שבה Codex מפעיל פקודה במערכת, ארגז החול הזה נראה כמו הגרסה ללא הרשאות מוגברות. הוא עדיין מריץ תהליכי בן תחת אסימון מוגבל — גם כאן אסימון write_restricted עם אותה רשימת מזהי SID מוגבלים: [Everyone, Logon, Synthetic]. אלא שהזהות הראשית של האסימון אינה עוד משתמש Windows בפועל, אלא אחד משני משתמשים מקומיים ש-Codex עצמו יוצר:

• CodexSandboxOffline (המשתמש שעליו חלים כללי חומת האש)

• CodexSandboxOnline (המשתמש שעליו לא חלים כללי חומת האש)

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

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

בתכנון של ארגז החול ללא הרשאות מוגברות היה שלב הקמה פשוט ומצומצם יחסית:

• יצירת SID סינתטי במידת הצורך

• החלת רשימות ACL עבור ה-SID הסינתטי sandbox-write

לעומת זאת, בארגז החול עם הרשאות מוגברות יש יותר עבודה:

• יצירת SID סינתטי, אם טרם נוצר

• יצירת משתמשי ארגז החול המקוון והלא-מקוון, אם טרם נוצרו

• שמירת פרטי הכניסה של המשתמשים החדשים באופן מקומי והצפנתם באמצעות Windows Data Protection API ‏(DPAPI), במיקום שמשתמשי ארגז החול אינם יכולים לקרוא

• יצירת כללי חומת אש שחוסמים כל גישה יוצאת לרשת עבור המשתמש CodexSandboxOffline, או בדיקת תקינותם אם הם כבר קיימים

בשלב ההקמה יש מורכבות נוספת. ארגז החול של Codex אמור לקבל הרשאות קריאה זהות לאלו של משתמש Windows בפועל. בארגז החול ללא הרשאות מוגברות, שבו ה-SID הראשי של האסימון המוגבל היה של משתמש Windows, זה אכן הושג. אבל זה לא קורה מאליו כשהזהות הראשית הופכת למשתמש CodexSandbox חדש. תיקיות רלוונטיות רבות ב-Windows מעניקות הרשאות קריאה והרצה לקבוצת ״משתמשים מאומתים״. דוגמה בולטת היא תיקיית הפרופיל של המשתמש. כברירת מחדל, משתמשי Windows אינם יכולים לקרוא את תיקיות הפרופיל של משתמשי Windows אחרים, ולכן בתרחישים רבים אפילו קריאה פשוטה של קבצים הייתה נכשלת.

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

• C:\Users\<real-user>

• C:\Windows\

• C:\Program Files\

• C:\Program Files (x86)\

• C:\ProgramData\

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

ריכזנו את לוגיקת ההקמה בקובץ בינארי נפרד, בין היתר כדי לחצות את גבול בקרת חשבון המשתמש (UAC) רק כשצריך. אבל הסיבה העמוקה יותר הייתה ארכיטקטונית: תהליך ההקמה של ארגז החול ממלא תפקיד שונה מהותית מזה של codex.exe. שמירת לוגיקת ההקמה בקובץ בינארי ייעודי אפשרה ל-codex.exe להישאר harness רגיל ללא הרשאות מוגברות; מנעה ממנגנוני ההקמה הייחודיים ל-Windows לנפח את codex.exe בפלטפורמות אחרות; הפרידה בין עבודת הקמה ממושכת לבין משך החיים של התהליך הראשי; וסיפקה לנו מקום אחד לטיפול במסלולי ההקמה השונים שארגז החול דורש.

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

• codex.exe פועל תחת משתמש Windows האמיתי. לאחר מכן, Codex מבצע לפי הסדר:

  • קורא ל-LogonUserW(...) עבור משתמש ארגז החול.

  • קורא ל-CreateRestrictedToken(...) על האסימון של משתמש ארגז החול.

  • באמצעות האסימון המוגבל של משתמש ארגז החול, קורא ל-CreateProcessAsUserW(...) כדי להפעיל את תהליך הבן הסופי.

בפועל, התהליך המתוכנן הזה לא עבד, בגלל חסם הרשאות בקריאה ל-CreateProcessAsUserW(...). כלומר, codex.exe יכול היה ליצור אסימון מוגבל עבור משתמש ארגז החול, אבל לא יכול היה להפעיל באופן אמין תהליך בן עם האסימון הזה מצדו של המשתמש האמיתי בגבול ההפרדה. היינו צריכים תהליך שכבר פועל תחת משתמש ארגז החול — כך שלב ההגבלה וההפעלה הסופית יוכלו להתבצע בצדו של משתמש ארגז החול בגבול ההפרדה, במקום בצדו של המשתמש האמיתי.

הדרישה הזו הובילה ליצירת codex-command-runner.exe, קובץ בינארי חדש שתפקידו היחיד הוא ליצור אסימון מוגבל ולהפעיל את הפקודה המבוקשת. במקום לבקש מ-codex.exe לבצע את כל התהליך בעצמו (משתמש אמיתי ← משתמש ארגז חול ← אסימון מוגבל ← תהליך בן), פיצלנו את התהליך לשניים:

חלק 1

• codex.exe קורא ל-CreateProcessWithLogonW(...) כדי להפעיל את codex-command-runner.exe תחת משתמש ארגז החול, עדיין ללא שימוש באסימון מוגבל.

חלק 2

• בתוך מריץ הפקודות, הקריאה OpenProcessToken(GetCurrentProcess(), ...) פותחת את האסימון של המריץ עצמו, שכבר שייך למשתמש ארגז החול.

• המריץ קורא ל-GetTokenInformation(...) כדי לחלץ את ה-SID של הכניסה למערכת של ארגז החול, ואז ל-CreateRestrictedToken(...) כדי לבנות את האסימון המוגבל הסופי.

• עדיין מתוך המריץ, מתבצעת קריאה ל-CreateProcessAsUserW(...) עם האסימון המוגבל הזה כדי להפעיל את תהליך הבן בפועל.

אלברט איינשטיין אמר: ״יש לעשות הכול פשוט ככל האפשר, אך לא פשוט יותר מכך״. ברוח זו, התכנון שלנו סיפק מענה הולם לכל בעיה. הארכיטקטורה הסופית כוללת את ארבע השכבות שסקרנו קודם:

• codex.exe עצמו

• codex-windows-sandbox-setup.exe לטיפול בכל עבודת ההקמה שדורשת הרשאות מוגברות

• codex-command-runner.exe להרצת פקודות עם אסימון מוגבל

• תהליך הבן

כשניגשתי לפרויקט הזה לראשונה, לא היה לי מושג ברור לאן הוא יוביל. בחרתי להתחיל בשילוב יכולת ההרצה בארגז חול בנקודת הממשק שבין Codex למערכת ההפעלה. הגישה הזו דומה מאוד לאופן שבו ארגז החול של Codex ממומש ב-macOS וב-Linux.

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

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

כשעבדנו על חוויית שימוש טובה ב-Codex עבור משתמשי Windows, המטרה הייתה ליצור משהו בטוח בלי להתפשר על התועלת — הרי כל הרעיון בשימוש ב-Codex הוא לאפשר לסוכנים לעבוד בלי שתצטרכו לשים לב אליהם כל הזמן.

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

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

סקרנים לראות את ארגז החול של Codex בפעולה? נסו אותו⁠.