NVIDIA OpenShell: sandbox آمن لـ Claude Code وCodex — متى تعتمده فعلاً
لو بتدّي Claude Code أو Codex صلاحية sudo كاملة على جهازك علشان يشتغل، انت فعليًا بتثبت في إيد agent حر يعمل أي commit أو يفتح أي port. NVIDIA طلّعت OpenShell مفتوح المصدر تحت Apache 2.0 علشان تحلّ الجزء ده بالظبط: sandbox مع policy YAML بتتحكّم بالتفصيل في الملفات والـ network والـ binaries اللي الـ agent ينفّذها. وفي 20 أبريل 2026، أديوب أعلنت شراكة مع NVIDIA لبناء CX Enterprise Coworker فوق OpenShell، فالمشروع خرج رسميًا من فئة "تجربة" لفئة "بنية إنتاج".
المشكلة باختصار
الـ AI agent بطبيعته بيشغّل أوامر shell وبيقرا ملفات وبيعمل HTTP calls. لو سبته بدون حدود، ممكن يعمل rm -rf على مجلد مش بتاعه، أو يبعت مفاتيحك لـ endpoint غريب. الـ containers العادية (Docker/Podman) بتعزل الـ process، بس الـ policy بتكون على مستوى الـ image والـ network namespace — مش على مستوى "الـ binary اللي الـ agent سمح بتشغيله دلوقتي". الفرق ده هو سبب وجود OpenShell.
مثال بسيط قبل ما ندخل في التفاصيل
تخيّل إنك عيّنت مطوّر junior جديد. لو ادّيته مفتاح السيرفر وقلتله "اشتغل"، ده يشبه تشغيل agent بدون sandbox. لو حطّيته في حاوية Docker، ده زي ما ادّيته مكتب في طابق معزول، بس ساعات بتطلع منه مكالمات خارجية ومش عارف ليه. OpenShell بيحطّ حارس على باب المكتب، معاه ورقة A4 مكتوب فيها بالظبط: "يسمح لـ git push origin main، ميسمحش بـ curl لأي domain غير GitHub، وrm ممنوع على أي مجلد برّة /workspace". الحارس بيوقف أي حاجة مش في الورقة — من غير ما يسأل الـ junior.
ده بالظبط نموذج out-of-process policy enforcement اللي بتعتمد عليه OpenShell. السياسة مش جوّا الـ agent ومش جزء من كوده، فبالتالي الـ agent ميقدرش يعدّلها لنفسه.
المفهوم التقني بدقة
OpenShell بتقف بين الـ agent والـ OS. بتقدّم 4 مكوّنات رئيسية:
- Sandboxed execution: كل agent في sandbox منفصل بـ filesystem و network namespace خاصين بيه.
- Granular permissions: السماح أو الرفض على مستوى (binary, path, HTTP method).
- Privacy router: توجيه الـ inference requests بحيث تختار فين البيانات تمشي (local أو cloud أو endpoint محدد).
- Self-proposed policy updates: لو الـ agent اصطدم بحائط، بيقدر يقترح تعديل policy ويستنّى موافقة إنسانية قبل التنفيذ.
الـ default policy في أي sandbox جديد بيرفض كل outbound traffic — ياللي معندوش permit صريح ميطلعش. ده الفرق الكبير عن Docker اللي بيسمح بـ all outbound بشكل افتراضي.
التثبيت والتشغيل الأول
التثبيت سطر واحد:
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
أو عبر uv لو بتفضّل Python tooling:
uv tool install -U openshell
بعدها، لتشغيل Claude Code جوّا sandbox جديد:
openshell sandbox create -- claude
openshell sandbox list
openshell term # dashboard حي لمراقبة النشاط
الـ sandbox الافتراضي بيجي فيه Python 3.13 وNode 22 وGit وGitHub CLI. فبدون إعداد زيادة، عندك بيئة كتابة كود شبه كاملة، بس محصورة.
الـ Policy في ملف YAML واحد
السياسات قابلة للقراءة والمراجعة، ده مهم لفريق أمن أو compliance. المثال ده بيسمح للـ agent يشتغل git ويقرا من /workspace، وبيرفض أي HTTP خارج GitHub:
version: 1
name: workspace-dev
binaries:
allow:
- git
- node
- python3
deny:
- rm
- curl
filesystem:
read:
- /workspace/**
write:
- /workspace/projects/**
network:
outbound:
allow:
- host: api.github.com
methods: [GET, POST]
- host: github.com
methods: [GET]
default: deny
التطبيق:
openshell policy set workspace-dev --policy policy.yaml --wait
التعديلات بتدخل حيّز التنفيذ بدون إعادة تشغيل الـ sandbox — ده بيوفّر وقت كبير لمّا بتضبط سياسات متكرّرة.
OpenShell vs Docker — الفرق الحقيقي
Docker بيعزل الـ process، بس مش agent-aware. يعني مفيش فكرة "الـ binary ده جديد، الـ agent لسه نزّله من skill marketplace، اطلب موافقة". OpenShell بيقيّم الـ actions على 3 مستويات (binary + path + method)، وبيربطها بفكرة الـ skill install. لو الـ agent عايز يحمّل tool جديد، OpenShell بيقفه ويستنّى مراجعة إنسانية.
الـ trade-off هنا: OpenShell بيضيف layer على البنية. بتكسب تحكّم دقيق وأدلة audit واضحة. بتخسر دقيقة إضافية في الـ setup الأولي، وتحتاج كتابة policies YAML (مش مجرد Dockerfile). لو الـ agent بتاعك سيناريو بسيط وقاطع، Docker لوحده ممكن يكفي.
أرقام ومعايير مفيدة
NVIDIA ذكرت إن OpenShell بيتكامل مع Claude Code وCodex وCopilot من غير تعديل في كود الـ agent نفسه — عشان كده الـ adoption cost منخفض. من التجارب العملية على الـ repos بتاعة NVIDIA، الـ overhead في الـ latency عادةً أقل من 15% على commands عادية، وبيكون أعلى (~30%) لمّا الـ policy فيها regex معقّد على مسارات كتيرة. الافتراض هنا إن عندك CPU-bound workload؛ لو شغلك GPU-bound (تدريب نماذج)، التأثير أقل من ده بكتير.
متى لا تستخدم OpenShell
مش كل مشروع يحتاج الطبقة دي. فيه 3 حالات OpenShell هيكون فيها overkill:
- Agent بيشتغل مرة واحدة في job CI: لو الـ workflow بيخلص في 3 دقايق وبيتمسح، GitHub Actions container لوحده كفاية.
- لا يوجد sensitive data: sandbox للـ demos أو التجربة على جهازك الشخصي من غير مفاتيح إنتاج — الـ ROI ضعيف.
- فريق مش مستعد يكتب ويراجع policies: OpenShell قوّته في الـ policy-as-code. لو مفيش وقت لكتابة YAML مراجع، هتستخدمه سطحيًا وهتفقد أغلب فايدته.
الخطوة التالية
ركّب OpenShell على جهازك وشغّل sandbox تجريبي لـ Claude Code أو Codex بالـ policy المثال اللي فوق. جرّب تخلّيه يعمل git push لـ repo غريب — المفروض يترفض. لو نفّذ، معناه الـ policy محتاجة تضييق. ابعت الـ output بتاعك لو لقيت سلوك غريب، هشرح فين المشكلة بالظبط.