الصلاحيات، وبيئة العمل المعزولة، والموافقة: تحكّم كامل في القيود والتسهيلات
📚 التنقل في السلسلة: المقال السابق 14 · سير العمل الشائع قام بدمج Codex في روتين التطوير اليومي الخاص بك. هذا المقال ينتقل إلى بعد آخر - لا يتعلق بـ "كيف يعمل"， بل "ما الذي يجرؤ على لمسه": من طلب الإذن لكل أمر، إلى التشغيل التلقائي الكامل. كيف يمكنك ضبط مفاتيح التحكم الخاصة ببيئة العمل المعزولة (sandbox) والموافقة (approval)، وما هي الإعدادات المناسبة لكل سيناريو؟ هذا المقال سيوضح لك كل شيء.
سأخبركم بشيء أحمق قمت به في الشتاء الماضي. كنت قد انتهيت للتو من إعداد Codex، ولتوفير الوقت قمت بكتابة sandbox_mode كـ danger-full-access بشكل دائم في ~/.codex/config.toml بحجة أن "النوافذ المنبثقة مزعجة". وذات يوم، كنت في مجلد مؤقت لم يتم تهيئة Git فيه وطلب منه "تنظيف الملفات غير المفيدة". فقام بالبحث في مجلدي الرئيسي بالكامل - لأنه تحت وضع الوصول الكامل لم تكن هناك حدود لـ "منطقة العمل" تمنعه. قمت بضغط Esc بسرعة لمقاطعته، وفي تلك اللحظة شعرت برعب شديد.
بعد مراجعة ما حدث، لم تكن المشكلة في Codex بل كانت فيّ: لقد قمت بتعيين تكوين خطير كافتراضي عالمي، وهو أمر لا ينبغي استخدامه إلا في حاوية معزولة. لم يكن هو من خرج عن السيطرة، بل أنا من أرخيت له الحبل في مكان لم يكن ينبغي لي ذلك.
في المقال 02 قمنا بالفعل بشرح مفاهيم بيئة العمل المعزولة والموافقة بالتفصيل باستخدام تشبيه "سياج حديقة الأطفال" و"بوابة الأمن + الحارس" - لن نكرر التعريفات هنا، بل سنركز على شيء واحد: إرشادك خطوة بخطوة حول كيفية الإعداد والاختيار. ما هي الإعدادات التي تتوافق معاً، وكيفية تغييرها مؤقتاً عبر سطر الأوامر، وكيفية حفظها كإعدادات افتراضية في ملف التكوين، وأين تكمن الخطوط الحمراء لوضع الخطر.
بقراءة هذا المقال، ستحصل على:
- جدول يوضح كيفية الجمع بين أوضاع بيئة العمل المعزولة الثلاثة (
read-only/workspace-write/danger-full-access) واستراتيجيات الموافقة الثلاثة (untrusted/on-request/never) - قوالب لتعديل الإعدادات مؤقتاً عبر سطر الأوامر باستخدام
--sandbox/--ask-for-approvalأو حفظها كافتراضية فيconfig.toml - الوضع الافتراضي الذي يعينه Codex عند البدء (والذي يعتمد على ما إذا كان المجلد يحتوي على Git أم لا)، والسبب وراء ذلك
- الإعدادات الافتراضية الهامة مثل كون الشبكة مغلقة افتراضياً و
.gitمحمي للقراءة فقط في وضعworkspace-write - أين تكمن الخطوط الحمراء لاستخدام
--yolo(التحكم الكامل بدون قيود)، ولماذا يجب تجنبه تماماً على جهازك المحلي أو خادم الإنتاج
⚠️ جميع الأوامر، خيارات التكوين، والقيم الافتراضية الواردة أدناه تستند إلى المستندات الرسمية لـ Codex؛ أما أرقام الإصدارات وأسماء النماذج التي تتغير مع التحديثات فستعتمد على ما يظهر لديك محلياً. "ملفات تعريف الصلاحيات (permission profiles)" المذكورة هي ميزة تجريبية (Beta) قد تتغير، وسنتحدث عنها بشكل منفصل في القسم 05.
01 أولاً: تذكر أنك تضبط "مفتاحين مستقلين"
دعنا نوضح أمراً يسبب اللبس كثيراً: بيئة العمل المعزولة والموافقة ليسا مستويين لشيء واحد، بل هما مفتاحا تحكم مستقلان تماماً، وكل منهما يدير جانباً مختلفاً.
لقد ضربنا مثالاً في المقال 02، وهنا سنضيف فقط كيفية تطبيق ذلك على التكوين - فهما مفتاحان منفصلان في ملف config.toml ومعاملان منفصلان في سطر الأوامر:
| المفتاح | ماذا يدير | مفتاح التكوين | معامل سطر الأوامر | الاختصار |
|---|---|---|---|---|
| وضع بيئة العمل المعزولة (sandbox mode، حدود نظام الملفات والوصول إلى الشبكة) | ما هو نطاق حركته | sandbox_mode | --sandbox | -s |
| استراتيجية الموافقة (approval policy، هل يتوقف عند كل خطوة بانتظار تأكيد بشري) | هل يسألك أم لا | approval_policy | --ask-for-approval | -a |
لماذا نؤكد على "الاستقلالية"؟ لأن الخطأ الأكثر شيوعاً بين المبتدئين هو الاعتقاد بأن "إذا قمت بتمكين الوصول الكامل، فلن تظهر النوافذ المنبثقة مجدداً" - هذا غير صحيح. الوصول الكامل (تحريك مفتاح بيئة العمل المعزولة لأقصى حد) وعدم السؤال (تحريك مفتاح الموافقة لأقصى حد) هما أمران مختلفان تماماً. يمكنك إعداد النظام ليكون "قادراً على التحكم في الجهاز بأكمله، ولكنه يسألك عند كل خطوة"، أو "قادراً على القراءة فقط، ولكنه يقرأ بصمت دون إزعاجك". التأثير الفعلي الذي تشعر به هو نتيجة المزج بين هذين الإعدادين.
تشبيه: "الترس" و"حد السرعة" عند قيادة السيارة. وضع بيئة العمل المعزولة يشبه ترس الحركة - وضع P (read-only) يجعل السيارة لا تتحرك على الإطلاق، ووضع D (workspace-write) يسمح لها بالتحرك على الطريق، ووضع الدفع الرباعي (danger-full-access) يسمح لها بالذهاب إلى أي مكان؛ أما الموافقة فتشبه تنبيه تجاوز السرعة الذي تحدده لنفسك - يمكن أن يكون "ينبهك فقط عند تجاوز السرعة" (on-request)، أو "ينبهك عند رؤية أي شخص غريب" (untrusted)، أو "إيقاف التنبيهات والقيادة بصمت" (never). الترس يحدد أين يمكن للسيارة أن تذهب، وحد السرعة يحدد متى يتم تنبيهك - ولا يغني أحدهما عن الآخر.
إليك بعض السيناريوهات التي ستواجهها لمساعدتك في فهم هذا الفصل:
- تريد منه قراءة الكود فقط وإعداد تحليل: اضبط بيئة العمل المعزولة على
read-onlyوالموافقة كما تشاء - بما أنه لا يمكنه تعديل أي شيء، فلن يهم إن ظهرت النوافذ المنبثقة أم لا. - تريد منه التعديل بحرية داخل المشروع، ولكن عليه تنبيهك إذا حاول الخروج منه: هذا هو المزيج الذهبي اليومي: بيئة العمل المعزولة
workspace-write+ الموافقةon-request. - تريد تشغيل مهام دفعية داخل حاوية معزولة تماماً دون أي إزعاج: اضبط بيئة العمل المعزولة على
danger-full-accessوالموافقة علىnever- كلا المفتاحين في أقصى حد - ولكن داخل الحاوية المعزولة فقط، كما سنؤكد أدناه مراراً.
💡 ملخص في جملة واحدة: بيئة العمل المعزولة (
--sandbox) تدير "نطاق الحركة"، والموافقة (--ask-for-approval) تدير "هل يسألك أم لا"؛ هما مفتاحان مستقلان ومفصلان في التكوين، والتأثير الذي تشعر به هو نتيجة الجمع بينهما.
توضح هذه الصورة المفتاحين في جدول ثنائي الأبعاد: المحور الأفقي يمثل وضع بيئة العمل المعزولة (من الأكثر صرامة read-only إلى الأكثر تساهلاً danger-full-access)، والمحور الرأسي يمثل استراتيجية الموافقة (من الأكثر حذراً untrusted إلى الأقل إزعاجاً never). كل تقاطع يمثل تركيبة فعلية - المربع الأزرق workspace-write + on-request هو المزيج الذهبي اليومي، بينما المربع الأحمر في الأسفل على اليمين danger-full-access + never (المعروف بـ --yolo) يجب ألا يلمس إلا في حاوية معزولة تماماً.
02 أوضاع بيئة العمل المعزولة الثلاثة: نطاق الحركة يحدده هذا الإعداد
يحتوي مفتاح بيئة العمل المعزولة على ثلاثة خيارات، وتعرفها المراجع الرسمية بوضوح. سأدرجها لك في ثلاثة أعمدة توضح "هل يمكن تعديل الملفات / هل يمكن الاتصال بالشبكة / لأي المهام هي الأنسب" - هذا هو الجدول الأهم في هذا القسم:
| وضع بيئة العمل المعزولة | هل يمكن تعديل الملفات؟ | هل يمكن الاتصال بالشبكة؟ | المهام الأنسب |
|---|---|---|---|
read-only (للقراءة فقط) | ❌ لا (يجب الموافقة أولاً للتعديل) | ❌ | مراجعة الكود، تقديم المقترحات، التخطيط، "لا تلمس ملفاتي" |
workspace-write (الكتابة في منطقة العمل) | ✅ داخل منطقة العمل فقط | ❌ مغلق افتراضياً، يجب تفعيله يدوياً | الوضع الافتراضي للتطوير اليومي، إزعاج منخفض |
danger-full-access (الوصول الكامل الخطر) | ✅ الجهاز بأكمله | ✅ | الحاويات المعزولة / الآلات الافتراضية، اسمها يحتوي على danger لسبب وجيه |
إليك بعض التفاصيل التي يسهل الوقوع في الخطأ بشأنها:
أولاً، الاتصال بالشبكة مغلق افتراضياً في وضع workspace-write. قد يبدو هذا غير منطقي - قد تظن "بما أنه يستطيع كتابة الملفات، فيجب أن يكون قادراً على الاتصال بالشبكة لتثبيت التبعيات"، لكن هذا غير صحيح. تنص المستندات الرسمية بوضوح على أن وضع workspace-write يغلق الوصول إلى الشبكة افتراضياً، ويجب عليك تفعيله بنفسك في التكوين. لفتح الشبكة، أضف هذا الجزء في config.toml:
[sandbox_workspace_write]
network_access = trueفي المرة الأولى التي طلبت فيها من Codex تشغيل npm install في وضع workspace-write، توقف وظهرت العديد من أخطاء الشبكة. ظننت أنها مشكلة في البروكسي، واستغرق الأمر مني وقتاً طويلاً لأتذكر - أن بيئة العمل المعزولة لم تمنحه صلاحية الشبكة افتراضياً. تذكر هذه المعلومة، فقد توفر عليك ساعات من البحث.
ثانياً، منطقة العمل لا تعني فقط "المجلد الحالي". تشير الوثائق الرسمية إلى أن منطقة العمل تشمل تلقائياً المجلدات المؤقتة (مثل /tmp). لمعرفة المجلدات الدقيقة الموجودة داخل منطقة العمل، اكتب /status داخل الجلسة. سيكون المخرج المتوقع شبيهاً بهذا:
Sandbox: workspace-write
Approval: on-request
Workspace directories:
/Users/you/myproject
/tmpالسطران اللذان يبدآن بـ Sandbox و Approval يوضحان الإعداد الحالي، وقائمة Workspace directories توضح النطاق الذي يمكنه الكتابة فيه.
ثالثاً، حتى لو قمت بتفعيل workspace-write، هناك مجلدات تظل محددة كـ "للقراءة فقط". هذه شبكة أمان مصممة خصيصاً في Codex - فحتى في منطقة العمل القابلة للكتابة، تظل المسارات التالية غير قابلة للمس:
| المسار المحمي | لماذا هو محمي |
|---|---|
<Workspace>/.git | لمنع تعديل سجل Git بالخطأ وتخريب المستودع |
<Workspace>/.agents | لمنع تعديل إعدادات الوكيل سراً |
<Workspace>/.codex | كما أعلاه، مجلد إعدادات Codex نفسه |
هذا الحظر يتم بشكل متداخل (recursive) - أي أن كل محتويات هذه المجلدات تظل للقراءة فقط. لذلك لا داعي للقلق من إمكانية تعديل .git بمجرد تفعيل الكتابة، فـ Codex يغلق هذه المجلدات الحساسة تلقائياً.
رابعاً، لا تقتصر بيئة العمل المعزولة على عمليات القراءة والكتابة الخاصة بـ Codex نفسه، بل تشمل أيضاً الأوامر التي يشغلها. تم ذكر هذا في المقال 02 ونؤكد هنا على أهميته العملية: حتى لو استدعى Codex أوامر مثل git أو npm أو سكربتات الاختبار، فإن هذه الأوامر الفرعية تخضع لنفس القيود - لذا لن تواجه موقفاً يتم فيه تقييد العملية الرئيسية بينما تتمكن الأوامر الفرعية من الخروج وتعديل مجلدات أخرى.
💡 ملخص في جملة واحدة: من بين أوضاع بيئة العمل المعزولة الثلاثة، يعد
workspace-writeهو الوضع الافتراضي اليومي، ولكن تذكر أن الشبكة معطلة افتراضياً، والمجلدات.git/.agents/.codexمحمية للقراءة فقط؛ لتفعيل الشبكة يجب تشغيلnetwork_accessيدوياً، ولمعرفة نطاق العمل اكتب/status.
03 استراتيجيات الموافقة الثلاثة: هل يسألك أم لا، هذا الإعداد يحدد ذلك
مفتاح الموافقة يحتوي أيضاً على ثلاثة خيارات. بعد أن تحدد بيئة العمل المعزولة الحدود، تأتي استراتيجية الموافقة لتقرر متى يجب التوقف وسؤالك:
| استراتيجية الموافقة | سلوك Codex | بالعامية |
|---|---|---|
untrusted | يشغل فقط العمليات المعروفة بأنها آمنة للقراءة فقط، ويسأل قبل تشغيل أي شيء آخر | يمنع كل الأوامر غير المألوفة، الأكثر حذراً |
on-request | يعمل تلقائياً داخل حدود بيئة العمل المعزولة، ويتوقف للسؤال فقط عند محاولة الخروج منها | الخيار الأكثر توازناً واستخداماً |
never | لا يطلب موافقة، يعمل بصمت | يستخدم للتشغيل الآلي؛ تظل الصلاحيات محددة ببيئة العمل المعزولة، ويكون منطقياً فقط عند دمجه مع الوصول الكامل |
هناك تفصيل هام في الوثائق الرسمية - untrusted لا تعني "للقراءة فقط". هي تظل تنفذ عمليات القراءة المعروفة بأنها آمنة تلقائياً، ولكن أي أمر "قد يغير الحالة أو يؤدي إلى تنفيذ خارجي" (مثل عمليات Git المدمرة، أو الأوامر التي تحتوي على معاملات لتجاوز الإعدادات) سيتطلب موافقتك أولاً. لذلك، تشعر مع untrusted بأن "القراءة متاحة بحرية، ولكن أي حركة فعلية تتطلب إذناً"، وهو أكثر تفصيلاً وحذراً من on-request.
هناك وضع متقدم يجب أن تعرفه: يمكن دمج never مع أي وضع لبيئة العمل المعزولة. يعتقد الكثيرون أن never (عدم السؤال) يعادل "إطلاق العنان الكامل"، وهذا خطأ. تنص الوثائق الرسمية بوضوح على أن --ask-for-approval never يمكن دمجه مع أي وضع لـ --sandbox - يمكنك تماماً استخدام read-only + never، وهو ما يعني "اسمح له بالقراءة فقط، ولا تسألني عن أي شيء أثناء ذلك"، وهو التكوين القياسي للتحليل للقراءة فقط في بيئة التطوير المستمر (CI)، وهو آمن للغاية. "عدم السؤال" و"منح الصلاحيات الكاملة" هما أمران مختلفان تماماً، وهذا يؤكد مجدداً على مفهوم "المفتاحين المستقلين" الذي شرحناه في القسم 01.
أما بالنسبة لـ "من يقوم بالموافقة"， فالافتراضي هو أنت شخصياً (approvals_reviewer = "user"). توفر الوثائق الرسمية أيضاً خيار auto_review (المراجعة التلقائية) - ليتولى وكيل مراجعة آخر فحص الطلبات التي تتطلب موافقة بدلاً منك. هذه ميزة متقدمة وتتطور باستمرار، وسيشرح المقال 16 · الأمان وحدود المخاطر منطق تقييمها ومخاطرها بالتفصيل. هنا يكفي أن تعرف وجود هذا المفتاح، وأن خيار user كافٍ للاستخدام اليومي.
💡 ملخص في جملة واحدة: من بين استراتيجيات الموافقة الثلاثة، يعد
on-requestهو الافتراضي اليومي؛ بينماuntrustedأكثر حذراً (القراءة متاحة، ولكن أي حركة فعلية تتطلب إذناً)؛ أماneverفيعني "عدم السؤال" وليس "منح الصلاحيات الكاملة"، ويمكن دمجه مع أي وضع لبيئة العمل المعزولة، مثل استخدامread-only+neverفي عمليات التحليل للقراءة فقط في بيئات CI.
04 كيفية الدمج: التعديل المؤقت عبر سطر الأوامر، والتثبيت عبر config.toml
بعد أن تعرفنا على الأوضاع والاستراتيجيات، تتبقى طريقة الإعداد وهي تنقسم إلى طريقين: التعديل المؤقت عبر معاملات سطر الأوامر، أو التثبيت الدائم في ملف التكوين.
التعديل المؤقت: معاملات سطر الأوامر (لهذه الجلسة فقط)
عند بدء التشغيل، يمكنك تمرير المعاملين لتحديد درجة القيود لهذه الجلسة فقط. المزيج الافتراضي منخفض المخاطر المقترح رسمياً يبدو كالتالي:
codex --sandbox workspace-write --ask-for-approval on-requestالحدود مغلقة، ويسألك فقط عند محاولة الخروج منها، وهو إعداد آمن وغير مزعج. ويمكنك استخدام الاختصارات -s و -a لتكون أقصر:
codex -s read-only -a on-request "راجع هذا الكود فقط، لا تقم بتعديله"هل تريد التغيير أثناء الجلسة؟ لا داعي للخروج، استخدم الأمر المائل لتغيير الإعداد مباشرة:
/permissionsستظهر قائمة اختيار لتحديد الوضع المطلوب (Read Only / Auto / Full Access وغيرها) لتطبيقه فوراً. أسلوبي المعتاد هو: عند البدء في مشروع جديد، أستخدم أولاً /permissions للتحول لوضع القراءة فقط لجعله يقرأ الكود ويقترح الحلول، وعندما أثق في الخطة أنتقل لوضع workspace-write للبدء في العمل - هذا الأسلوب أنقذني عدة مرات من تعديلات عشوائية في كود لم أكن قد فهمته بعد.
⚠️ قد تختلف القائمة في الإصدارات الجديدة: بدءاً من الإصدار 0.142 لـ codex-cli، قدمت الوثائق الرسمية permission profiles (ميزة تجريبية Beta قد تتغير) لتكون بديلاً للخيارات القديمة. قد يظهر لك عند كتابة
/permissionsخيارات مثلAsk for approval/Approval for me/Full accessوهي تتعلق بـ استراتيجيات الموافقة، ولن تجد خيارRead Onlyمباشرة. للتحول لوضع القراءة فقط استخدم معامل بدء التشغيلcodex --sandbox read-only، أو اكتبsandbox_mode = "read-only"في ملف~/.codex/config.toml(حيث تحتفظ الوثائق الرسمية بالوضع القديم للتوافق). هذا التنبيه ينطبق على أي مكان يذكر فيه استخدام/permissionsللتحول للقراءة فقط في هذا القسم.
Tوضح الصورة التالية خطوتي اتخاذ القرار: "التحقق من بيئة العمل المعزولة أولاً، ثم التحقق من استراتيجية الموافقة":
توضح هذه الصورة ما يلي: عند القيام بأي خطوة، يتحقق Codex أولاً "هل تقع داخل حدود بيئة العمل المعزولة" (بيئة المعزل تقرر)، وإذا خرجت عنها يتحقق "هل يجب التوقف لسؤالك" (الموافقة تقرر) - خطوتان متتاليتان، كلاهما ضروري.
التثبيت الدائم: config.toml كافتراضي (يطبق في كل مرة)
كتابة المعاملات في كل مرة أمر مزعج، لذا يفضل كتابة المزيج المفضل في ملف التكوين بشكل دائم. الملف يقع في ~/.codex/config.toml، أضف هذين السطرين:
approval_policy = "on-request"
sandbox_mode = "workspace-write"هل تريد المزيج الأكثر حذراً وأماناً؟ الإعداد "السؤال دائماً" المقترح رسمياً هو كتابة
approval_policy = "untrusted"معsandbox_mode = "read-only"، مما يعني بدء التشغيل بأقصى درجات الحذر دائماً، وتوسيع الصلاحيات يدوياً عند الحاجة. هذا المزيج مناسب للمشاريع الحساسة أو الأجهزة المشتركة.
إذا كان لديك عدة تركيبات تفضلها (مثل "تركيبة للتطوير اليومي، وأخرى لبيئة CI")، فلا تقم بتعديل نفس الملف باستمرار - بل يدعم النظام ملفات تعريف التكوين (profiles)، حيث يمكنك حفظ كل تركيبة في ملف منفصل واستدعائها باستخدام --profile:
# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode = "read-only"وعند الاستخدام، حدد الملف المطلوب فقط:
codex --profile full_auto⚠️ تذكر أن profile (ملف تعريف التكوين) المذكور هنا يختلف عن permission profile (ملف تعريف الصلاحيات) الذي سنتحدث عنه في القسم 05، فالاسم متشابه ولكنهما مختلفان: الأول هو الطريقة القديمة لحفظ مجموعة إعدادات وتسميتها، والثاني هو آلية تجريبية (Beta) أحدث لتحديد حدود نظام الملفات والشبكة. التكوين الحالي باستخدام
sandbox_mode+approval_policyهو الطريقة الأساسية المتبعة حالياً، لذا ركز على إتقانها أولاً.
💡 ملخص في جملة واحدة: للتعديل المؤقت استخدم
-s/-aأو/permissionsداخل الجلسة، وللتثبيت الدائم اكتب في ملف~/.codex/config.tomlالخيارينsandbox_mode+approval_policy؛ وللتبديل بين عدة تركيبات استخدم--profile- هذه هي الطريقة الأساسية حالياً.
05 مستوى متقدم: تحديد دقيق للأوامر عبر rules وتحديد دقيق للحدود عبر permission profiles (Beta)
التكوين المذكور في القسم 04 باستخدام "وضع بيئة العمل المعزولة + استراتيجية الموافقة" هو ضبط عام. إذا كنت تريد التحكم بدقة مثل "السماح دائماً بهذا الأمر وتثبيت الحظر على أمر آخر"، فإن Codex يوفر أداتين أكثر دقة. يمكن للمبتدئين تجاوز هذا القسم في البداية والعودة إليه عند الحاجة الفعلية.
rules: تحديد قواعد للأوامر الفردية (تجريبية)
⚠️ ميزة تجريبية قد تتغير. تعتبر rules ميزة تجريبية وفقاً للوثائق الرسمية.
الآلية التي يستخدمها Codex للتحكم الدقيق في الأوامر الفردية تسمى rules (القواعد)، ويرجى ملاحظة أن خيارات اتخاذ القرار فيها هي allow / prompt / forbidden وليست ask / approve / deny كما يكتب في بعض الشروحات - يرجى عدم الخلط بينها.
المشكلة التي تحلها هي: بيئة العمل المعزولة تضع حدوداً عامة للمجلدات، ولكن قد ترغب أحياناً في ضبط إعدادات مثل "السماح بتشغيل gh pr view مباشرة حتى لو خرج عن الحدود دون الحاجة للسؤال في كل مرة" أو "حظر grep تماماً لإجبار نفسك على استخدام rg". في هذه الحالات، توسيع نطاق بيئة المعزل بالكامل أمر غير عملي، والحل الأفضل هو كتابة قاعدة (rule) مخصصة.
تكتب القواعد في ملفات تنتهي بـ .rules داخل المجلد ~/.codex/rules/ باستخدام لغة تشبه Python (وهي لغة Starlark فعلياً). تبدو القاعدة كالتالي:
prefix_rule(
pattern = ["gh", "pr", "view"],
decision = "prompt",
justification = "السماح بعرض PR، ولكن بعد موافقتي",
)خيارات decision هي ثلاثة، ويتم تحديد أولويتها بشكل صارم - الأكثر صرامة هو الذي يفوز (forbidden > prompt > allow):
| decision | التأثير |
|---|---|
allow | التشغيل مباشرة خارج المعزل بدون سؤال |
prompt | السؤال قبل كل تشغيل عند مطابقة القاعدة |
forbidden | الحظر التام، لا يسأل ولا يشغل |
هناك ميزة أمان ذكية: إذا واجه أمراً مدمجاً في سطر واحد مثل git add . && rm -rf /، فإن Codex سيقوم بتقسيم الأوامر وفحصها بشكل فردي لضمان الأمان - فحتى لو سمحت بـ git add باستخدام allow، فسيتم فحص وحظر rm -rf / بشكل منفصل، ولن يمرر متخفياً. لاختبار القواعد بعد تعديلها، استخدم الأمر codex execpolicy check لمعرفة كيف سيتم التعامل مع الأمر قبل تشغيله فعلياً.
permission profiles: تحديد حدود نظام الملفات والشبكة في ملف تعريف واحد (Beta)
⚠️ ميزة تجريبية (Beta) قد تتغير، ولا يمكن دمجها مع إعدادات بيئة المعزل القديمة. هذا أمر تؤكد عليه الوثائق الرسمية بوضوح - فإذا ظهر خيار
sandbox_modeفي أي ملف تكوين أو مررت المعامل--sandbox، فإن Codex سيعود لاستخدام الإعدادات القديمة ولن يطبق permission profiles. يجب اختيار إحدى الطريقتين فقط.
إذا كنت تشعر أن workspace-write ليس دقيقاً بما يكفي وتريد تحديد المجلدات القابلة للكتابة بدقة، وحظر أي ملف .env تماماً، وتحديد النطاقات المسموح بزيارتها على الإنترنت، فإن permission profiles (ملفات تعريف الصلاحيات) هي الحل. فهي تجمع قواعد نظام الملفات وقواعد الشبكة في ملف تعريف واحد مسمى، وتستخدم default_permissions لتحديد الملف الافتراضي.
توفر الوثائق الرسمية ثلاثة ملفات تعريف مدمجة (تبدأ بنقطتين رأسيين):
| ملف التعريف المدمج | التأثير |
|---|---|
:read-only | إبقاء الأوامر المحلية في وضع القراءة فقط |
:workspace | السماح بالكتابة في مجلد العمل الرئيسي والمجلد المؤقت للنظام |
:danger-full-access | إزالة قيود بيئة المعزل المحلية، ولا يستخدم إلا عند الحاجة لصلاحيات واسعة جداً |
ويمكنك تخصيص ملف تعريف كالتالي (تحديد دقيق لنظام الملفات يسمح بالكتابة في منطقة العمل وحظر ملفات .env تماماً):
default_permissions = "project-edit"
[permissions.project-edit]
extends = ":workspace"
[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"
[permissions.project-edit.network]
enabled = true
[permissions.project-edit.network.domains]
"api.openai.com" = "allow"هناك ثلاث صلاحيات لنظام الملفات: read / write / deny، والأولوية تتبع نفس منطق القواعد - deny هو الأقوى (deny > write > read)، والمسارات الأكثر تحديداً لها الأولوية. ميزة هذا التصميم هي: يمكنك جعل منطقة العمل قابلة للكتابة بشكل عام، مع حظر ملفات .env بشكل خاص، مما يجمع بين التسهيل العام والتحكم الدقيق في إعداد واحد. والشبكة تتبع أسلوب القائمة البيضاء - فإذا لم تحدد allow لن يتم السماح بالاتصال بأي نطاق، ويظل deny أقوى من allow دائماً.
نصيحتي لك واضحة: كمبتدئ، لا تلمس profiles حالياً، واستخدم الطريقة الأساسية الموضحة في القسم 04 لتسيير عملك اليومي. وعندما تظهر لديك حاجة حقيقية لحظر ملفات حساسة محددة أو نطاقات معينة، يمكنك دراستها - وتذكر أنه لا يمكن خلطها مع إعدادات بيئة المعزل القديمة، ويجب إزالة sandbox_mode من التكوين قبل الانتقال إليها.
💡 ملخص في جملة واحدة: القواعد (rules) تتحكم بدقة بناءً على بادئة الأمر (
allow/prompt/forbiddenوالأكثر صرامة يفوز)، أما ملفات تعريف الصلاحيات permission profiles (Beta) فتحدد الحدود بدقة بناءً على المسارات والنطاقات (denyهو الأقوى)؛ كلاهما من الخيارات المتقدمة، وعلى المبتدئين البدء بالطريقة الأساسية واستخدام الخيارات المتقدمة عند الحاجة فقط، مع تذكر عدم خلط profiles مع إعدادات بيئة المعزل القديمة.
06 القيم الافتراضية عند البدء والخطوط الحمراء لوضع الخطر
بعد شرح الآليات، نأتي لسؤال "ماذا يجب أن أختار؟"، وقبل ذلك يجب أن تعرف أمراً هاماً: يقوم Codex باختيار قيمة افتراضية ذكية لك عند بدء التشغيل - ويعتمد هذا الاختيار على ما إذا كان المجلد يحتوي على Git أم لا.
ما هو الوضع الافتراضي الذي يعينه لك Codex؟
المنطق الذي يتبعه متميز جداً: عند بدء التشغيل، يتحقق أولاً هل المجلد يخضع لإدارة النسخ (يحتوي على Git أم لا)، ويقترح وضعاً افتراضياً مختلفاً بناءً على ذلك:
| المجلد الذي تشغل فيه Codex | الاقتراح الافتراضي |
|---|---|
| مجلد يحتوي على Git (version-controlled) | وضع Auto (workspace-write + on-request) |
| مجلد لا يحتوي على Git (non-version-controlled) | وضع read-only (للقراءة فقط) |
هذا التصميم يركز على نقطة جوهرية: بوجود Git لحمايتك، يمكنك مراجعة التغييرات عبر git diff والتراجع عنها إن أخطأ، لذا يسمح له بالكتابة في منطقة العمل؛ أما المجلدات التي لا تحتوي على Git فالتعديل فيها نهائي ولا يمكن التراجع عنه بسهولة، لذا يكون الوضع الافتراضي هو القراءة فقط لضمان الأمان. وتذكر قصتي في البداية - لقد استخدمت الوصول الكامل في "مجلد مؤقت لا يحتوي على Git"، وهو ما يعني أنني قمت بإزالة طبقتي الحماية اللتين وضعهما Codex لي، فكان من الطبيعي أن تحدث مشكلة.
أيضاً هناك تفصيل آخر: في بعض الحالات قد يبدأ Codex بوضع read-only أولاً، حتى تؤكد له "ثقتك" في هذا المجلد (مثلاً عبر رسالة التوجيه الأولى أو باستخدام /permissions). لذا إن وجدته في البداية حذراً ويرفض الكتابة، فلا تقلق، فهو ينتظر موافقتك وتأكيد ثقتك في المجلد، وليس عطلاً فيه.
وهناك قيمة افتراضية أخرى تتعلق بـ "الاتصال بالإنترنت" يجدر بك تذكرها - البحث في الويب (web search) يعتمد على التخزين المؤقت (cached) افتراضياً وليس البحث الحي اللحظي. تحتفظ الجهة المطورة بقائمة نتائج مفهرسة مسبقاً، ويعيد وضع التخزين المؤقت نتائج من هذه القائمة بدلاً من البحث الفعلي في المواقع الحية. الفائدة من ذلك هي تقليل خطر التعرض لهجمات "حقن التعليمات البرمجية" (prompt injection) المخفية في الصفحات الحية. وتذكر أمراً قد يبدو غير متوقع: إذا قمت بتفعيل الوصول الكامل (مثل استخدام --yolo)، فإن البحث في الويب سيتحول تلقائياً إلى الوضع الحي (live). لإجبار النظام على البحث الحي استخدم --search، ولإيقافه تماماً اضبط web_search = "disabled"، وسنشرح اعتبارات الأمان المتعلقة بهذا الجانب بالتفصيل في المقال 16 · الأمان وحدود المخاطر.
--yolo: الخطوط الحمراء للوصول الكامل
أخيراً نأتي لـ الخط الأحمر، وهو بطل قصتي في البداية - الوصول الكامل والحر تماماً. في Codex هناك طريقتان متطابقتان لكتابته:
- في ملف التكوين: كتابة
sandbox_mode = "danger-full-access"معapproval_policy = "never" - في سطر الأوامر مباشرة:
--dangerously-bypass-approvals-and-sandbox(والاختصار الشهير--yoloوهو يعبر عن "أنت تعيش مرة واحدة فقط")
اسم --yolo يوضح تماماً أنه يجب تجنبه في الأحوال العادية. فهو يزيل بيئة العمل المعزولة ويلغي نظام الموافقة تماماً، مما يعطي Codex الحرية الكاملة لعمل ما يريد على جهازك دون أن يسألك أبداً. للتعرف على متى يمكنك استخدامه، راجع هذا الجدول:
| السيناريو | هل تجرؤ على استخدام --yolo / الوصول الكامل؟ |
|---|---|
| الحاويات المعزولة / الآلات الافتراضية / بيئات dev container | ✅ نعم، فالبيئة مؤقتة وحذفها لا يضر |
| تشغيل مهام لمرة واحدة في بيئات CI (داخل حاوية) | ✅ نعم، بشرط أن تكون البيئة نفسها معزولة |
| جهازك المحلي للتطوير اليومي | ❌ لا، يفضل الانتظار لثوانٍ للموافقة على الأمان |
| الأجهزة التي تحتوي على كود الشركة أو بيانات هامة وحساسة | ❌ لا يمكن استخدامه أبداً، فهو خطر كبير |
موقف المطورين الرسميين واضح جداً: الوصول الكامل محدد بـ (not recommended) (غير مستحسن). إذا كان جهازك المضيف لا يدعم بيئة العمل المعزولة لنظام Linux، أو كانت شركتك تعتمد على التطوير داخل حاويات، فالأسلوب الصحيح هو استخدام Docker أو dev container لتأمين العزل الخارجي أولاً، ثم تشغيل --yolo داخل الحاوية - لتكون الحاوية هي حدود الأمان لحماية جهازك. وتوفر المستندات الرسمية مثالاً جاهزاً لإعداد devcontainer آمن (يحتوي على تحكم في الاتصالات الصادرة)، وهو مرجع مفيد جداً.
ولكن يجب أن ننقل لك هذا التنبيه الهام أيضاً: حتى داخل devcontainer، فإن فتح الصلاحيات بالكامل ليس آمناً بنسبة 100% - فقد يقوم مشروع خبيث بسرقة كل ما يمكن الوصول إليه داخل الحاوية (بما في ذلك بيانات تسجيل دخول Codex الخاصة بك). لذا حتى داخل الحاويات، لا تقم بهذا الإجراء إلا مع مستودعات الأكواد الموثوقة فقط، وراقب تحركات النظام وكأنه بيئة ذات صلاحيات عالية.
ملخص تجربتي القاسية هو: الوصول الكامل لا يفعل إلا في بيئات معزولة تماماً لا تبالي بفقدانها أو تخريبها، ويحظر تماماً على جهازك الشخصي أو خوادم الإنتاج. الانزعاج من النوافذ المنبثقة ليس مبرراً - فالانزعاج أفضل بكثير من التعرض للرعب وفقدان الملفات.
💡 ملخص في جملة واحدة: يختار Codex إعداداته الافتراضية بناءً على "وجود Git من عدمه" (بوجود Git يختار Auto، وبدونها يختار للقراءة فقط)، فلا تزل هذه الحماية؛ كما أن بحث الويب يعتمد على التخزين المؤقت لمنع هجمات الحقن؛ أما وضع
--yolo(الوصول الكامل) فلا يلمس إلا داخل حاويات معزولة تماماً، ويحظر تماماً على جهازك الشخصي أو أجهزة الإنتاج.
07 خطوات عملية: 5 دقائق لتجربة الأوضاع الثلاثة بنفسك
القراءة وحدها لا تكفي للحفظ. سنقوم معاً بإنشاء مجلد فارغ، لتشاهد بنفسك كيف يتعامل Codex مع نفس الطلب في الأوضاع المختلفة، وهل يتوقف للسؤال أم ينفذ مباشرة. الخطوات لا تتطلب أي مشروع جاهز.
الخطوة الأولى: إنشاء مجلد فارغ والدخول إليه لتشغيل Codex.
على أنظمة Mac / Linux (لأنظمة Windows استخدم PowerShell، واستبدل mkdir -p بـ mkdir):
mkdir ~/perm-demo
cd ~/perm-demo
codexتنبيه: هذا المجلد لا يحتوي على Git. بناءً على منطق القيم الافتراضية المشروح في القسم 06، سيبدأ Codex على الأرجح بوضع
read-only- وهذا ممتاز، فهو يوفر علينا عناء التغيير يدوياً.
الخطوة الثانية: التحقق من الوضع الحالي.
عند بدء الجلسة، تحقق أولاً من الإعدادات الحالية:
/statusالمتوقع: ستشاهد وضع بيئة العمل المعزولة الحالي، واستراتيجية الموافقة، ونطاق مجلدات منطقة العمل. اجعل هذه الشاشة هي مرجعك الأساسي.
الخطوة الثالثة: طلب عملية تتطلب كتابة ملف أثناء وضع القراءة فقط.
تأكد أولاً أنك في وضع القراءة فقط (إذا لم تكن كذلك، اكتب /permissions واختر Read Only)، ثم اطلب منه:
أنشئ ملفاً جديداً باسم hello.txt واكتب بداخله "hello codex".المتوقع: لن يقوم بإنشاء الملف بصمت، بل سيتوقف لطلب الموافقة - لأن "كتابة الملف" تتجاوز حدود وضع read-only المسموح بها، وبناءً على استراتيجية الموافقة يجب أن يسألك أولاً، وسيكون نص السؤال شبيهاً بهذا:
أحتاج لإنشاء ملف باسم hello.txt، وهذا يتجاوز صلاحيات وضع القراءة فقط الحالي، هل تسمح بذلك؟بمجرد أن يتوقف ليسألك، ستكون قد شاهدت عمل نظام بيئة المعزل والموافقة معاً: حددت بيئة المعزل أن "هذه الخطوة تخرج عن الحدود"، وتدخل نظام الموافقة ليسألك للحصول على إذنك.
الخطوة الرابعة: الانتقال لوضع الكتابة في منطقة العمل ومشاهدة سهولة التنفيذ.
/permissionsمن قائمة الاختيار، انتقل لوضع Auto أو Workspace Write، ثم اطلب منه إنشاء ملف hello.txt مرة أخرى. المتوقع: هذه المرة سيقوم بإنشاء الملف مباشرة دون أن يسألك - لأن كتابة الملفات داخل منطقة العمل تقع بالفعل ضمن حدود بيئة العمل المعزولة المسموح بها، فلا داعي لطلب الموافقة.
تم إنشاء hello.txtالخطوة الخامسة (اختيارية): تجربة كون الشبكة مغلقة افتراضياً.
أثناء بقائك في وضع الكتابة في منطقة العمل، اطلب منه القيام بعملية تتطلب الشبكة:
استخدم curl لزيارة https://example.com، واعرض لي المحتوى الذي يظهر لك.المتوقع: بما أن وضع workspace-write يغلق الشبكة افتراضياً (كما أوضحنا في القسم 02)، فإنه إما سيتوقف لطلب إذن الاتصال بالشبكة، أو سيظهر لك رسالة تفيد بفشل الاتصال مباشرة - وهذا يثبت أن "صلاحية كتابة الملفات لا تعني صلاحية الاتصال بالشبكة". لتفعيل الشبكة فعلياً، يجب الانتقال لملف config.toml وتفعيل network_access، ولكن لا داعي للقيام بذلك في هذا التدريب.
باتباع هذه الخطوات، تكون قد قمت بتجربة عملية للتحقق من أثر "منع الكتابة في وضع القراءة فقط، والسماح بها في وضع الكتابة، وإغلاق الشبكة افتراضياً". كل عمليات ضبط الصلاحيات اللاحقة تعتمد بالأساس على هذه المبادئ.
💡 ملخص في جملة واحدة: أنشئ مجلداً فارغاً، واستخدم
/statusلمعرفة الوضع الحالي، واطلب منه كتابة ملف في وضع القراءة فقط لتشاهد المنع، ثم انتقل لوضع الكتابة لتشاهد السماح، وجرب الاتصال بالشبكة لتتحقق من حجبها افتراضياً - تجربة هذه الأوضاع بنفسك عملياً تغنيك عن حفظ عشرات المعاملات.
08 ملخص
شرحنا في هذا المقال الصلاحيات والقيود في Codex بالتفصيل - وكيف أن درجات التسهيل والتقييد تعتمد بالكامل على المزج بين مفتاحي بيئة العمل المعزولة والموافقة.
دعنا نستعرض النقاط الأساسية معاً بشكل سريع:
| ما تريد القيام به | ما تستخدمه | نقاط هامة |
|---|---|---|
| ضبط "نطاق الحركة" | بيئة العمل المعزولة --sandbox | تتوفر في ثلاثة خيارات: read-only / workspace-write / danger-full-access |
| ضبط "هل يسألك أم لا" | استراتيجية الموافقة --ask-for-approval | تتوفر في ثلاثة خيارات: untrusted / on-request / never وهي مستقلة عن المعزل |
| تعديل مؤقت لهذه المرة | معاملات سطر الأوامر / /permissions | إمكانية تبديل الوضع فوراً أثناء الجلسة |
| حفظ الإعداد كافتراضي دائم | ملف config.toml | إعداد sandbox_mode + approval_policy؛ واستخدام --profile للتبديل |
| تحكم دقيق في الأوامر والمسارات | القواعد rules / ملفات تعريف الصلاحيات permission profiles | خيارات متقدمة، يفضل البدء بالطريقة الأساسية، ويحظر خلط profiles مع الإعدادات القديمة |
| الوصول الكامل والحر | وضع --yolo | لا يستخدم إلا داخل حاويات معزولة فقط، ويمنع تماماً على الأجهزة المحلية أو الإنتاجية |
يجب أن تكون الآن قادراً على: فهم الغرض من أوضاع بيئة المعزل الثلاثة واستراتيجيات الموافقة الثلاثة والجمع بينها، واستخدام معاملات --sandbox / --ask-for-approval للتعديل المؤقت أو حفظ الإعدادات في config.toml كإعدادات افتراضية، ومعرفة أن Codex يحدد إعداداته الافتراضية بناءً على "وجود Git من عدمه"، وفهم أن وضع workspace-write يغلق الشبكة افتراضياً ويحمي .git للقراءة فقط، وتثبيت قاعدة أن وضع --yolo لا يستخدم إلا في البيئات المعزولة تماماً. هذا التحكم المرن والآمن في الصلاحيات هو ما يمنحك الثقة للعمل مع Codex دون خوف أو قلق.
المقال التالي 16 · الأمان وحدود المخاطر - قمنا هنا بشرح "كيفية إعداد الصلاحيات"، ولكن الإعدادات هي مجرد أدوات، والسؤال الأهم هو: هل يجب أن نثق في الذكاء الاصطناعي للوصول إلى الكود والنظام الخاص بنا؟ كيف تستغل هجمات حقن التعليمات البرمجية (prompt injection) الثغرات؟ كيف نحمي البيانات الحساسة من التسريب؟ وكيف نقيم الأمان عند استخدام التخزين المؤقت للبحث والمراجعة التلقائية المذكورة سابقاً؟ بعد أن أمسكنا بالحبل، سنتحدث في المقال التالي عن "متى يجب الشد ومتى يمكن الإرخاء" لتنمية حس التقييم والأمان لديك.