هل يطلب Codex الموافقة باستمرار؟ شرح سياسات الموافقة وبيئة الحماية (sandbox) وخيار «لا تسأل مرة أخرى»
يطلب Codex الموافقة عندما يحتاج أمر ما إلى الخروج من بيئة الحماية (sandbox). معظم شكاوى «يظل يسأل» سببها sandbox مقيّدة أكثر من اللازم، أو إعداد لم يعد موجودًا، أو خيار «لا تسأل مرة أخرى» لم يدم إلا طوال الجلسة.
الإجابة المختصرة
في الإصدار الحالي من Codex، تكون قيمة approval_policy إما on-request (الافتراضية: يسأل النموذج عندما يحتاج)، أو never، أو جدول granular؛ أُزيلت untrusted وأصبحت on-failure مجرد اسم آخر لـ on-request. ما يحدد عدد مرات سؤالك هو في الغالب الـ sandbox: مع sandbox_mode = "workspace-write" يعدّل Codex الملفات ويشغّل الأوامر داخل مشروعك دون أن يسأل. للأوامر التي تثق بها دائمًا، أضف prefix_rule مع decision = "allow" في ~/.codex/rules/default.rules. وفي هذا الملف أيضًا يُحفظ خيار «لا تسأل مرة أخرى عن الأوامر التي تبدأ بـ …».
أولًا: ما الذي تغيّر في Codex
كثير من الأدلة وإجابات المنتديات تصف إعدادات لم تعد تعمل. قبل ضبط أي شيء، قارن ملف ~/.codex/config.toml بهذه القائمة:
| الإعداد القديم | اليوم |
|---|---|
approval_policy = "untrusted" | أُزيل. يعرض Codex الرسالة «approval_policy = "untrusted" is no longer supported; remove this setting» (لم يعد مدعومًا؛ احذف هذا الإعداد). تقترح الوثائق بدلًا منه sandbox_mode = "read-only" مع on-request. |
approval_policy = "on-failure" | لا يزال مقبولًا، لكن فقط كاسم بديل لـ on-request. |
--full-auto | لم يعد موجودًا في مرجع CLI. أقرب خيار هو --approve-for-me (واسمه البديل --not-so-yolo): مراجعة تلقائية للموافقات مع on-request وبيئة الحماية workspace-write. |
[profiles.name] داخل config.toml | منذ Codex 0.134.0 يقرأ --profile name الملف $CODEX_HOME/name.config.toml بدلًا من ذلك. ويؤدي بقاء مفتاح profile = "x" قديم الآن إلى خطأ. |
/approvals | استخدم /permissions («Set what Codex can do without asking first.»، أي حدّد ما يمكن لـ Codex فعله دون أن يسأل أولًا) |
انتقلت وثائق Codex أيضًا: صفحات developers.openai.com/codex القديمة تعيد التوجيه الآن إلى learn.chatgpt.com.
كيف يقرر Codex أن يسأل
يعمل إعدادان معًا. الـ sandbox تحدّ مما يمكن للأمر الوصول إليه: الملفات خارج المشروع، والشبكة. وسياسة الموافقة تحدد ما يحدث عندما يحتاج أمر إلى أكثر مما تسمح به الـ sandbox.
| sandbox_mode | ما يمكن لـ Codex فعله دون أن يسأل |
|---|---|
read-only (الافتراضي) | قراءة الملفات وتشغيل الأوامر في sandbox للقراءة فقط |
workspace-write | القراءة والتعديل وتشغيل الأوامر في مجلد العمل تلقائيًا |
danger-full-access | كل شيء، دون sandbox. غير موصى به |
| approval_policy | السلوك |
|---|---|
on-request (الافتراضي) | يقرر النموذج متى يسأل. الأوامر التي تسمح بها الـ sandbox تعمل دون موافقة |
never | لا يسأل أبدًا. أي شيء يفشل يُعاد إلى النموذج، ولا يُصعَّد إليك |
{ granular = { … } } | إبقاء بعض فئات الطلبات تفاعلية ورفض البقية تلقائيًا (sandbox_approval وrules وskill_approval وrequest_permissions وmcp_elicitations) |
لذا إذا كنت في وضع read-only فكل تعديل يحتاج إلى موافقة. وهذا أكثر سبب شيوعًا لشكوى «Codex يسأل عن كل شيء». وحتى في workspace-write تبقى .git و.codex و.agents و.aws للقراءة فقط، ويبقى الوصول إلى الشبكة معطّلًا ما لم تفعّله.
هذا مثال التهيئة من وثائق OpenAI، مع شرح خيارات مساحة العمل:
توفر الإصدارات الأحدث أيضًا ملفات تعريف للأذونات (default_permissions مع الملفات المضمّنة :read-only و:workspace و:danger-full-access). استخدم إما ملفات التعريف أو sandbox_mode، وليس الاثنين معًا.
الإعدادات المسبقة في CLI وإضافة بيئة التطوير والتطبيق
لست مضطرًا إلى تعديل TOML. في CLI يفتح /permissions الإعدادات المسبقة؛ وفي التطبيق وإضافة بيئة التطوير يوجد عنصر تحكم بالأذونات أسفل مربع الكتابة. الإعدادات المسبقة في CLI هي:
- Read Only: يقرأ مساحة العمل؛ ويلزم الحصول على موافقة لتعديل الملفات أو الوصول إلى الإنترنت.
- Default: يعدّل داخل مساحة العمل؛ ويلزم الحصول على موافقة للوصول إلى الإنترنت أو تعديل ملفات أخرى.
- Full Access: يعدّل خارج مساحة العمل ويستخدم الإنترنت دون أن يسأل.
يصف التطبيق وإضافة بيئة التطوير الخيارات نفسها باسم Ask for approval وApprove for me وFull access. أما لقطات الشاشة الأقدم من بيئة التطوير فتسميها Chat وAgent وAgent (Full Access).
السماح بأوامر محددة عبر القواعد
عندما تريد أن يشغّل Codex أمرًا واحدًا خارج الـ sandbox دون أن يسأل (مثل gh pr view)، اكتب قاعدة. القواعد ميزة تجريبية، وتوجد في ملف .rules داخل مجلد rules/ بجوار طبقة تهيئة، مثل ~/.codex/rules/default.rules:
allow: يعمل خارج الـ sandbox دون طلب إذن.prompt: يسأل قبل كل أمر مطابق.forbidden: يحظر دون أن يسأل.
عندما تتطابق عدة قواعد، تُطبَّق الأكثر تقييدًا: forbidden تتقدم على prompt، التي تتقدم بدورها على allow. اختبر الأمر باستخدام codex execpolicy check قبل أن تعتمد على قاعدة.
ما الذي يحفظه خيار «لا تسأل مرة أخرى» فعلًا
يعرض طلب الموافقة في Codex CLI أنواعًا مختلفة من «نعم»، وتختلف مدة بقائها اختلافًا كبيرًا:
| الخيار | مدة بقائه |
|---|---|
| Yes, proceed (نعم، تابع) | هذا الأمر وحده |
Yes, and don’t ask again for commands that start with <prefix> (نعم، ولا تسأل مرة أخرى عن الأوامر التي تبدأ بهذه البادئة) | بشكل دائم (يُكتب كقاعدة في ~/.codex/rules/default.rules) |
| Yes, and don’t ask again for this command in this session (نعم، ولا تسأل مرة أخرى عن هذا الأمر في هذه الجلسة) | حتى نهاية الجلسة |
| Yes, and don’t ask again for these files (نعم، ولا تسأل مرة أخرى عن هذه الملفات) | تعديلات الملفات، لهذه الجلسة |
إذا ظللت تختار خيار الجلسة، فستُسأل مجددًا غدًا. اختر خيار البادئة، أو اكتب القاعدة بنفسك.
Codex على Windows
كان Windows هو المكان الذي بلغت فيه مشكلة «يسأل عن كل شيء» أسوأ حالاتها. في المشكلة #10187 شرح أحد أعضاء فريق OpenAI السبب: «Without a sandboxing mechanism, all tool calls need to be manually approved on Windows.» (دون آلية عزل، تحتاج كل استدعاءات الأدوات إلى موافقة يدوية على Windows). أصبح لدى Codex الآن sandbox أصلية على Windows ويستخدمها افتراضيًا:
mxc: الـ sandbox الموصى بها على أجهزة Windows المتوافقة.elevated: البديل المفضّل عندما لا تتوفر MXC.unelevated: بديل قديم.
شغّل /setup-default-sandbox في CLI لإعداد الـ sandbox ذات الصلاحيات المرتفعة (أو codex sandbox setup --elevated لفرق تقنية المعلومات). يوصى بـ Windows 11؛ أما Windows 10 1809 أو أحدث فالدعم فيه بأفضل جهد. إذا كنت تعمل في WSL فإن Codex يستخدم sandbox الخاصة بـ Linux هناك، ولم يعد WSL1 مدعومًا.
تهيئة المشروع لا تُحمَّل إلا في المشاريع الموثوقة
لا يُقرأ ملف .codex/config.toml داخل المستودع إلا عندما تثق بالمشروع. إذا بدت إعدادات مشروعك متجاهَلة، فهذا هو السبب. يبدو إدخال الثقة في تهيئة المستخدم هكذا:
الإعدادات متدرجة في طبقات، من الأعلى أولوية: خيارات سطر الأوامر وتجاوزات -c، ثم .codex/config.toml للمشروع الموثوق، ثم ملف --profile، ثم ~/.codex/config.toml الخاص بك، ثم الإعدادات الافتراضية للنظام.
عن --yolo
يشغّل --dangerously-bypass-approvals-and-sandbox (واسمه البديل --yolo) كل أمر دون موافقات أو عزل. تصفه الشيفرة المصدرية بأنه «EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed.» (خطير للغاية، ومخصص فقط للتشغيل في بيئات معزولة من الخارج). ويؤدي approval_policy = "never" مع danger-full-access الشيء نفسه من ملف التهيئة. إذا كنت تريد فقط طلبات أقل، فإن workspace-write مع بضع قواعد allow يوصلك إلى ذلك مع إبقاء الـ sandbox مفعّلة.
للطلبات التي تبقيها
بمجرد أن يصبح Codex لا يسأل إلا عن الأشياء المهمة (الشبكة، والملفات خارج المشروع، وعملية push)، تبقى مشكلة الانتباه إلى السؤال. يضع Pet Island طلبات موافقة Codex على الأوامر وتعديلات الملفات في جزيرة صغيرة أعلى الشاشة، مع الأمر أو الفروقات (diff)، لتسمح بها أو ترفضها دون البحث عن الطرفية الصحيحة. ويعرض متى يعمل Codex ومتى ينتهي، وتنقلك أسئلة Codex إلى النافذة الصحيحة بنقرة واحدة. يعمل مع Codex CLI وتطبيق Codex، وإذا كانت الجزيرة مغلقة يسأل Codex في نافذته كالمعتاد.
الأسئلة الشائعة
كيف أمنع Codex من طلب الموافقة طوال الوقت؟
استخدم sandbox_mode = "workspace-write" حتى يتمكن Codex من التعديل وتشغيل الأوامر داخل مشروعك، وأبقِ approval_policy = "on-request"، وأضف إدخالات prefix_rule مع decision = "allow" في ~/.codex/rules/default.rules للأوامر التي تثق بها دائمًا.
هل لا يزال approval_policy = "untrusted" مدعومًا؟
لا. يرفضه Codex الحالي بالرسالة «approval_policy = "untrusted" is no longer supported; remove this setting». استخدم بدلًا منه sandbox_mode = "read-only" مع approval_policy = "on-request".
ماذا حدث للخيار --full-auto؟
لم يعد موجودًا في مرجع Codex CLI. أقرب خيار هو --approve-for-me (واسمه البديل --not-so-yolo)، الذي يستخدم المراجعة التلقائية للموافقات مع on-request وبيئة الحماية workspace-write.
لماذا لا يستمر أثر «لا تسأل مرة أخرى»؟
خيار «Don’t ask again for this command in this session» لا يدوم إلا طوال الجلسة. اختر «don’t ask again for commands that start with …» الذي يحفظ قاعدة في ~/.codex/rules/default.rules.
لماذا يسأل Codex أكثر على Windows؟
دون sandbox يحتاج كل استدعاء أداة إلى موافقة. يستخدم Codex الآن sandbox أصلية على Windows افتراضيًا؛ شغّل /setup-default-sandbox إذا لم تكن مُعدّة.
لماذا يُتجاهَل ملف .codex/config.toml في مشروعي؟
لا يحمّل Codex تهيئة المشروع إلا للمشاريع الموثوقة.
المصادر
راجعنا كل إعداد وسلوك في هذه الصفحة مقابل هذه الصفحات بتاريخ 26 أكتوبر 2026. الوكلاء يتغيرون بسرعة؛ فإذا لم يعد شيء مطابقًا، فالمرجع هو الصفحة الرسمية.
- OpenAI: موافقات وكيل Codex والأمان
- OpenAI: أوضاع الأذونات في Codex
- OpenAI: أساسيات تهيئة Codex
- OpenAI: مثال تهيئة Codex
- OpenAI: قواعد Codex
- OpenAI: بيئة الحماية (sandbox) في Codex على Windows
- OpenAI: مرجع Codex CLI
- OpenAI: أوامر الشرطة المائلة في Codex
- الشيفرة المصدرية لـ openai/codex (طلب الموافقة، وأخطاء التهيئة)
- المشكلة #10187: يطلب Codex الموافقة على الأوامر بشكل متكرر
- المشكلة #5131: يجب الموافقة على تعديلات الملفات دائمًا
- المشكلة #29406: يستمر طلب الموافقة رغم اختيار «لا تسأل مرة أخرى»