الهجرة من Claude Code: استخدام أداة جديدة بخريطة قديمة، وستصل إلى بيتك بأمان
📚 التنقل في السلسلة: شرحت المقالة السابقة 〔31 المهارات المتقدمة وتسريع العمليات〕 كيفية جعل سير العمل بأكمله أسرع وأكثر توفيرًا وأقل حاجة لإعادة العمل. وتأتي هذه المقالة لتغيير الزاوية — وهي مكتوبة خصيصًا لك كشخص ينتقل من Claude Code: ما هي المفاهيم التي يمكنك نقلها مباشرة من النموذج الذهني الذي استخدمته لنحو نصف عام، وما الذي يجب تغيير اسمه، وما هي الميزات الجديدة الحصرية في Codex. تتحدث المقالة التالية 〔33 نقاط استخدام Windows الأساسية〕 عن المشاكل الحصرية وكيفية معالجتها في نظام تشغيل Windows.
دعنا نستعيد محادثة حقيقية أولاً. في الشهر الماضي، قام صديق لي اعتاد على استخدام Claude Code بتثبيت Codex، وكانت أولى كلماته سلسلة من علامات الاستفهام:
هو: «أين أضع ملف CLAUDE.md في Codex؟ لماذا لا يقرأ النسخة الموجودة في دليل المشروع الرئيسي؟» أنا: «لا يتعرف Codex على اسم CLAUDE.md، بل يقرأ ملف AGENTS.md، ويمكنك نقل المحتوى إليه كما هو تقريبًا.» هو: «وماذا عن قواعد الصلاحيات allow / deny المحددة في settings.json لدي؟» أنا: «يجب تغييرها أيضًا — يستخدم Codex ملف ~/.codex/config.toml بصيغة TOML، وفكرة الصلاحيات تعتمد على "sandbox (البيئة المعزولة) + الموافقة"، وليس allowedTools.» هو: «وماذا عن تشغيل السكريبتات عبر claude -p؟ وهل أوامر مثل /compact و /clear موجودة؟» أنا: «يقابل claude -p أمر codex exec، وأغلب أوامر الخط المائل موجودة وبنفس الأسماء تقريبًا. ببساطة، 90% من ذاكرتك العضلية صالحة للاستخدام المباشر.»
شعر بارتياح كبير بعد سماع ذلك — فالأمر لا يتطلب تعلم أداة جديدة بالكامل من الصفر، بل هو استخدام نفس الخريطة بمسميات جديدة فقط. توضح هذه المقالة الإجابات عن الأسئلة التي طرحها، والأسئلة التي لم يتسنى له طرحها بعد، لتكون دليلاً شاملاً لك: ما هي المفاهيم المتطابقة، وما هي الاختلافات التي قد تسبب مشاكل إذا تم نقلها دون تعديل، وسنقوم في النهاية بتحويل ملف CLAUDE.md حقيقي إلى AGENTS.md عمليًا.
بعد قراءة هذه المقالة، ستحصل على:
- طمأنة كاملة: 90% من النموذج الذهني لـ Claude Code قابل للنقل مباشرة إلى Codex، وتكلفة الانتقال أقل بكثير مما تتصور
- جدول مقارنة شامل يوضح «مفاهيم Claude Code ← وما يقابلها في Codex» لشرح الفروقات الجوهرية
- تفاصيل حول ملف توجيهات المشروع، وملف التكوين، ونموذج الصلاحيات، وهي ثلاثة مواضع تتشابه أسماؤها وتختلف طبيعتها وقد تسبب مشاكل عند النقل المباشر
- توضيح للميزات الموجودة في Claude Code والتي لا توجد أو تختلف في Codex لئلا تفترض البديهيات
- دليل عملي خطوة بخطوة لتحويل ملف CLAUDE.md إلى AGENTS.md
⚠️ تعتمد الأوامر ومفاتيح التكوين والسلوك الافتراضي المذكورة لاحقًا على مستندات Codex الرسمية؛ وتعتمد أسماء النماذج وأرقام الإصدارات المتغيرة على ما تعرضه لوحة
/modelالمحلية لديك وأمرcodex --helpفعليًا، ولا تحفظ الأسماء. يتم تحديث الأداتين بسرعة، ويركز جدول المقارنة على «تطابق المفاهيم» وليس مطابقة الكلمات حرفيًا.
01 طمئنة أولاً: 90% من نموذجك الذهني قابل للنقل المباشر
دعنا نقطع الشك باليقين في البداية: عند الانتقال من Claude Code إلى Codex، أنت لا تتعلم أداة جديدة من الصفر، بل تستخدم نفس المنطق الأساسي بغطاء خارجي مختلف.
لماذا نثق في ذلك؟ لأن الأداتين في الجوهر هما نفس النوع من البرمجيات — كلاهما واجهة سطر أوامر (CLI) للبرمجة بالذكاء الاصطناعي تعمل داخل الطرفية، وتشغلان «حلقة الوكيل (agentic loop)»، ويمكنهما قراءة وكتابة مستودع الكود الحقيقي لديك مباشرة. هذه النقاط الثلاث التي تعودت عليها في Claude Code لا تتطلب أي تعديل هنا.
تشبيه: الانتقال من هاتف أندرويد إلى هاتف أندرويد آخر من علامة تجارية مختلفة. لا يشبه الأمر الانتقال من أندرويد إلى آيفون حيث تضطر للبدء من الصفر — فذاكرتك العضلية في الاتصال وإرسال الرسائل وتثبيت التطبيقات وإيماءات الرجوع تظل صالحة، وكل ما في الأمر هو تغير مواقع الأيقونات وترتيب قائمة الإعدادات ومسميات بعض التطبيقات. أنت لا تحتاج لإعادة تعلم «كيفية استخدام الهاتف»، بل تحتاج فقط لعشر دقائق لتحديد «أين توجد الأشياء في الجهاز الجديد». هذه هي العلاقة بين Codex و Claude Code.
ما هي الأمور التي يمكن نقلها مباشرة؟ عند انتقالي الشخصي من Claude Code، لم أواجه أي مشكلة في الممارسات التالية:
- حلقة الوكيل «فكر ← نفذ ← راجع»: حيث تقوم بوصف الطلب، ويضع الوكيل خطة عمل، ثم يقوم بالتنفيذ، ثم يراجع النتائج، وتعمل هذه الحلقة بنفس الطريقة تمامًا.
- عادة «دعه يقرأ ويفهم الخطة أولاً قبل التنفيذ»: قراءة وفهم المشروع أولاً لوضع الخطة ثم تأكيدها قبل تعديل أي كود في مشروع غير مألوف، وهو إجراء مفضل في كلتا الأداتين.
- فكرة «كتابة قواعد المشروع في ملف واحد ليقرأه تلقائيًا عند بدء العمل»: يختلف فقط اسم الملف وتفاصيل تحميله (سنوضح ذلك في القسم التالي).
- أوامر الخط المائل كـ «لوحة تحكم الجلسة»: التبديل بين النماذج، ومسح السياق، ومراجعة الحالة، كلها تتم عبر كتابة
/.
في أول مهمة عمل فعلية لي باستخدام Codex، قمت بنقل مشروع FastAPI من Claude Code. قمت بالعمل معتمدًا بالكامل على عاداتي القديمة — استخدام /status لمراجعة الإعدادات، واستخدام /model للتبديل بين النماذج، ومطالبته بتقديم الخطة قبل التعديل — وكانت النتيجة نجاح 80% من العمليات مباشرة، وتطلبت الـ 20% المتبقية فقط تعديل اسم الملف وإعداد الصلاحيات، وهو ما تم محاذاته بعد مراجعة المستندات الرسمية لمدة عشر دقائق. كان الشعور بالألفة مريحًا ومفاجئًا لي.
💡 الخلاصة في جملة واحدة: يعتبر Codex و Claude Code من نفس فئة الأدوات (سطر أوامر في الطرفية + حلقة وكيل + قراءة وكتابة المستودع الحقيقي)، ويمكنك نقل 90% من نموذجك الذهني مباشرة، وكل ما تحتاجه هو التعرف على «أماكن وجود الأشياء ومسمياتها الجديدة».
02 جدول مقارنة شامل: المسميات القديمة ← المسميات الجديدة
يعتبر هذا القسم هو الهيكل الأساسي لهذه المقالة — حيث يربط بين كل مفهوم جوهري تعلمته في Claude Code مع المقابل له في Codex. راجع الجدول أولاً لتكوين فكرة عامة، ثم سنقوم بشرح الفروقات الكبرى لاحقًا بالتفصيل.
| Claude Code | Codex | العلاقة | الفرق باختصار |
|---|---|---|---|
ملف توجيهات المشروع CLAUDE.md | AGENTS.md | تغيير الاسم | الفكرة واحدة، وتختلف طريقة الاكتشاف وقواعد التجاوز (انظر 03) |
ملف التكوين ~/.claude/settings.json (JSON) | ~/.codex/config.toml (TOML) | تغيير الصيغة | تحول من JSON إلى TOML، وتختلف أسماء المفاتيح والهيكل تمامًا (انظر 04) |
وضع الصلاحيات وقواعد allow/ask/deny | sandbox (البيئة المعزولة) + الموافقة (approval) | تغيير المبدأ | تحول من «تحديد القائمة البيضاء لكل أداة» إلى «تحديد مساحة العمل وطلب الإذن عند الخروج» (انظر 05) |
الوضع غير التفاعلي claude -p | أمر التشغيل غير التفاعلي codex exec | تغيير الاسم | كلاهما لتشغيل أمر معين والخروج مباشرة دون دخول الواجهة التفاعلية |
مستويات CLAUDE.md (مستخدم / مشروع / دليل فرعي) | مستويات AGENTS.md (عام / مشروع تدريجي) | تطابق | الفكرة واحدة، ويضيف Codex ملف AGENTS.override.md |
| أدوات MCP الخارجية | MCP | توافق شبه كامل | يعتمدان على نفس البروتوكول، وتختلف طريقة كتابة الإعدادات لكل منهما |
| الوكلاء الفرعيون Subagents | الوكلاء الفرعيين Subagents | تطابق | الميزة متوفرة في كلاهما، وتختلف مواقع إعدادها |
| المهارات Skills | المهارات Skills | تطابق | متوفرة في كلاهما، وتختلف طريقة تنظيم المجلدات المحلية قليلاً |
أوامر الخط المائل (/model، /compact...) | أوامر الخط المائل (/model، /compact...) | تطابق في الأغلب | الأوامر متشابهة تمامًا، وتوجد اختلافات طفيفة في بعضها (انظر 06) |
| الذاكرة التلقائية memory (مفعلة افتراضيًا) | Memories / Chronicle | تطابق مع اختلاف الطبيعة | الذاكرة في Codex مغلقة افتراضيًا، وتخضع لقيود جغرافية وتنشأ بشكل غير متزامن |
| النماذج Opus / Sonnet / Haiku | سلسلة GPT-5.x | تغيير الموديلات | النموذج الرائد gpt-5.5، والنموذج الخفيف gpt-5.4-mini وغيرهما |
لا داعي لحفظ هذا الجدول، وتذكر القاعدة العامة التالية فقط:
جميع الأمور المتعلقة بـ «المفاهيم» (ملف توجيهات المشروع، الصلاحيات، الذاكرة، الوكلاء الفرعيين، المهارات، MCP) متوفرة في كلاهما، ويتطلب الانتقال فقط «تغيير الاسم وتعديل طريقة الكتابة»؛ أما ما قد يسبب مشاكل فعلية فهو المفاهيم «ذات الأسماء المتشابهة والطبيعة المختلفة» — ملف توجيهات المشروع، ملف التكوين، ونموذج الصلاحيات. وسنقوم بشرحها بالتفصيل في الأقسام الثلاثة التالية.
أما بالنسبة لمقارنة النماذج: إذا كنت تختار في Claude Code بناءً على «Opus للمهام الصعبة، وSonnet للعمل اليومي، وHaiku للمهام الجانبية»، فستستخدم في Codex «gpt-5.5 للمهام الصعبة، وgpt-5.4-mini للمهام الجانبية»، ومنطق الاختيار متطابق تمامًا (مطابقة صعوبة المهمة مع القوة الحسابية)، لمزيد من التفاصيل راجع 〔30 كيفية اختيار النموذج〕. لاحظ أن gpt-5.4 ليس النموذج الرائد — فالرائد هو gpt-5.5 بينما gpt-5.4-mini هو النسخة الخفيفة منه.
💡 الخلاصة في جملة واحدة: تتطابق المفاهيم في الأغلب بين الأداتين، ويقتصر الانتقال على «تغيير الاسم وتعديل طريقة الكتابة»؛ بينما تكمن العقبات في ملف توجيهات المشروع، ملف التكوين، ونموذج الصلاحيات، وسنفصلها لاحقًا.
03 ملف توجيهات المشروع: CLAUDE.md ← AGENTS.md
هذا هو أول سؤال ستواجهه عند الهجرة، وهو ما سأل عنه صديقي: لا يقرأ Codex ملف CLAUDE.md. سيتجاهل تمامًا النسخة الموجودة في دليل المشروع الرئيسي لأنه يبحث عن ملف باسم AGENTS.md.
الخبر السار هو: يمكنك نقل المحتوى كما هو تقريبًا. فكرة ملف توجيهات المشروع، وبيان التقنيات المستخدمة، والأوامر الشائعة، واتفاقيات الكود، وقائمة الممنوعات — كلها تخدم نفس الهدف وبنفس طريقة الكتابة في كلتا الأداتين. القواعد التي تعلمتها في Claude Code [18] مثل «كتابة الحقائق التي يجب تذكرها في كل جولة، وحذف كل ما يمكن للكود إثباته بنفسه» تظل صالحة تمامًا لملف AGENTS.md.
تشبيه: إعادة كتابة وثيقة تسليم المهام عند الانتقال لشركة جديدة. عند انتقالك لشركة جديدة، تظل المعلومات الأساسية في وثيقة «شرح المشروع» — مثل التقنيات المستخدمة وكيفية تشغيل الاختبارات والمحاذير — صالحة للنقل إلى نموذج الشركة الجديدة. ولكن هيكل المجلدات وقواعد التسمية تختلف، وعليك الالتزام بقواعد الشركة الجديدة. ملف AGENTS.md هو حالة من نوع «المحتوى صالح للنقل مع ضرورة تغيير قواعد التسمية والحفظ».
تفاصيل الاختلافات في «قواعد الحفظ والاكتشاف» نلخصها في الجدول التالي:
| البعد | Claude Code (CLAUDE.md) | Codex (AGENTS.md) |
|---|---|---|
| الحفظ على مستوى المستخدم | ~/.claude/CLAUDE.md | ~/.codex/AGENTS.md |
| الحفظ على مستوى المشروع | ./CLAUDE.md أو ./.claude/CLAUDE.md | ./AGENTS.md (في جذر المشروع) |
| على مستوى المجلدات الفرعية | يقرأ ملف CLAUDE.md في أي مجلد فرعي عند الوصول إليه | يقرأ من جذر Git صعودًا للمجلد الحالي، ويختار ملفًا واحدًا لكل مجلد |
| التجاوز المؤقت | النسخة المحلية CLAUDE.local.md (لا تضاف إلى git) | AGENTS.override.md (تتجاوز ملف AGENTS.md في نفس المستوى بالكامل) |
| الحجم الأقصى | يوصى بعدد الأسطر (أقل من 200 سطر) | بالـ بايت (الحد الأقصى بعد الدمج 32 KiB افتراضيًا، يحدده project_doc_max_bytes) |
أهم ثلاثة اختلافات يجب تذكرها:
أولاً: اختلاف آلية التجاوز المؤقت. يستخدم Claude Code ملف CLAUDE.local.md لإضافة التفضيلات الشخصية التي لا تضاف إلى git. بينما يستخدم Codex ملف AGENTS.override.md — وفي حال وجوده في مستوى معين، يتم تجاهل ملف AGENTS.md في نفس المستوى بالكامل. العمليتان مختلفتان: الأولى تعني «إضافة محتوى شخصي»، بينما الثانية تعني «استخدام هذا الملف بدلاً من الملف الآخر في هذا المستوى». انظر التفاصيل في [11].
ثانياً: تحول الحد الأقصى للحجم من «عدد الأسطر» إلى «البايت». ينصحك Claude Code بألا يتجاوز ملف CLAUDE.md 200 سطر؛ بينما يضع Codex حدًا رقميًا صارمًا — حيث يتم قص الملف أو تجاهله بالكامل إذا تجاوز الحجم الكلي بعد الدمج 32 KiB افتراضيًا. وقد واجهت هذه المشكلة عند نقل ملف توجيهات مشروع FastAPI الخاص بي، حيث كان ملف CLAUDE.md ضخمًا، ولم ألاحظ ذلك عند نقله في البداية، ثم اكتشفت لاحقًا أن التعليمات في المجلدات الفرعية لم تكن فعالة، وعرفت بعد البحث أن الحجم تجاوز الحد الأقصى. لذا احرص على تنظيف الملف وحذف الأجزاء الزائدة التي يمكن لـ Codex استنتاجها من الكود نفسه قبل نقله.
ثالثاً: آلية الاكتشاف هي «الدمج والتسلسل» وليست «التغطية». يتم تفعيل الملف العام والملف الخاص بالمشروع في نفس الوقت، وتكون للملف الأقرب للمجلد الحالي الأولوية عند حدوث تعارض. يتوافق هذا مع آلية التحميل في Claude Code، ولكن يتم دمجها في Codex بترتيب تسلسلي واضح (من الجذر إلى المجلد الحالي، ويتم دمج الأقرب لاحقًا وتكون له الأولوية)، كما هو موضح في [11].
💡 الخلاصة في جملة واحدة: يمكن نقل محتوى
CLAUDE.mdكما هو تقريبًا إلىAGENTS.md، ولكن يجب مراعاة اسم الملف، وآلية التجاوز المؤقت (CLAUDE.local.md←AGENTS.override.md)، والحد الأقصى للحجم (الأسطر ← البايت)، واحرص على تنظيف الملف وحذف الأجزاء غير الضرورية قبل نقله.
04 ملف التكوين: settings.json (JSON) ← config.toml (TOML)
العقبة الثانية: لا يمكنك نسخ إعدادات ملف ~/.claude/settings.json مباشرة إلى Codex. حيث تختلف صيغة الملفين تمامًا بين الأداتين.
- Claude Code: يستخدم
~/.claude/settings.jsonبصيغة JSON، ويتم وضع الصلاحيات ومتغيرات البيئة والخطافات (Hooks) والنموذج الافتراضي في هذا الملف الواحد. - Codex: يستخدم
~/.codex/config.tomlبصيغة TOML، ويتم وضع خيارات التحكم في النماذج والـ sandbox والموافقة و MCP وغيرها في هذا الملف.
تشبيه: رسم مخطط الكهرباء، حيث يستخدم أحدهما النظام المتري والآخر النظام الإمبراطوري. الفكرة المطلوب التعبير عنها واحدة (أي خط يتحكم في أي مفتاح)، ولكن وحدات القياس والرموز المستخدمة تختلف تمامًا. لا يمكنك تطبيق مخطط بالنظام الإمبراطوري مباشرة مع عمال يتبعون النظام المتري — بل يجب تحويل القيم أولاً. التحويل من إعدادات JSON إلى TOML هو حالة مشابهة من نوع «نفس الهدف مع ضرورة إعادة الكتابة بالصيغة الجديدة».
الفروق الأساسية في الصيغة نوضحها في الجدول التالي:
| الإعداد المطلوب | Claude Code (settings.json - JSON) | Codex (config.toml - TOML) |
|---|---|---|
| النموذج الافتراضي | "model": "claude-..." | model = "gpt-5.5" |
| الصلاحيات / الأمان | "permissions": { "deny": [...] } | sandbox_mode = "..." + approval_policy = "..." |
| الهيكل المتداخل | الأقواس المتعرجة { } والفاصلة | ترويسة القسم [section] وعلامة اليساوي |
| علامات التنصيص للنصوص | إلزامية | إلزامية |
مثال بسيط للمقارنة. تعيين النموذج الافتراضي في Claude Code (بصيغة JSON):
{
"model": "claude-sonnet-4"
}تعيين النموذج الافتراضي وقوة الاستدلال في Codex (بصيغة TOML):
# ~/.codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "medium"تذكر بعض القواعد في صيغة TOML والتي يسهل الخطأ فيها عند الانتقال من JSON: تستخدم علامة = للربط وليس :؛ ولا يتم استخدام الأقواس المتعرجة لتغليف الكائنات بل يتم الاعتماد على ترويسة الأقسام [section] للتقسيم؛ ولا توضع فاصلة في نهاية الأسطر. عندما بدأت العمل مع Codex، قمت بإضافة فاصلة في نهاية كل سطر في ملف config.toml بحكم العادة من JSON، وتسبب ذلك في خطأ تحليل الإعدادات مباشرة — وهي واحدة من أشهر الأخطاء البسيطة عند التحول من JSON إلى TOML، لذا نوضحها لتتجنبها.
توضيح جميع خيارات التحكم في ملف config.toml (النماذج، الـ sandbox، الموافقة، قوة الاستدلال، مستوى الخدمة، MCP...) موجود في 〔18 تفاصيل تكوين config.toml〕، والمهم هنا هو بناء فكرة أساسية: لا تحاول «ترجمة» ملف settings.json بالكامل، بل راجع الخيارات التي تستخدمها فعليًا وأعد كتابتها بناءً على جدول المفاتيح في [18]. حيث يقتصر تعديل أغلب المستخدمين على النموذج والـ sandbox والموافقة فقط.
💡 الخلاصة في جملة واحدة: التحول من
settings.json(JSON) إلىconfig.toml(TOML) يتطلب إعادة كتابة الصيغة وليس النسخ واللصق؛ وتذكر استخدام=وترويسات الأقسام[section]وعدم وضع فاصلة في نهاية الأسطر، وأعد كتابة الخيارات التي تحتاجها فقط بناءً على [18].
05 نموذج الصلاحيات: وضع الصلاحيات ← sandbox + الموافقة
هذا هو الاختلاف الذهني الأكبر عند الهجرة، وهو الموضع الأكثر أهمية لبناء مفهوم جديد. محاولة تطبيق فكرة «القائمة البيضاء» المستخدمة في Claude Code ستجعلك تشعر بالحيرة.
يتكون نموذج الصلاحيات في Claude Code من أمرين أساسيين:
- وضع الصلاحيات (permission mode): ستة مستويات، تبدأ من
default(طلب الإذن لكل خطوة) وصولاً إلىbypassPermissions(تجاوز الصلاحيات بالكامل)، ويتم التبديل بينها باستخدام الاختصارShift+Tab. - قواعد القائمة البيضاء: كتابة خيارات
allow/ask/denyفي ملفsettings.jsonللتحكم الدقيق في الأدوات والأوامر (مثل منع أمرrm -rf).
لا يتبع Codex هذا الأسلوب. بل يقوم بتقسيم التحكم في «ما يمكن القيام به» و«متى يتم طلب الإذن» إلى مفتاحين منفصلين:
- sandbox (البيئة المعزولة): للتحكم في «ما يمكن القيام به» — ويتكون من ثلاثة مستويات:
read-only/workspace-write/danger-full-access. - الموافقة (approval): للتحكم في «متى يتم طلب الإذن» — ويتكون من ثلاثة مستويات:
untrusted/on-request/never.
تشبيه: التحول من «نظام إقرار المصروفات لكل بند بالتفصيل» إلى «تحديد الميزانية الكلية + طلب الموافقة عند تجاوزها فقط». يشبه نظام Claude Code الطريقة القديمة — حيث تحدد مسبقًا لكل بند (أداة أو أمر) ما إذا كان مسموحًا به أم يتطلب طلب إذن بالتفصيل. بينما يشبه نظام Codex نظام الميزانية الحديث — حيث يتم تحديد «نطاق الميزانية الكلية» (الـ sandbox) أولاً، ويمكنه العمل بحرية داخل هذا النطاق دون إزعاجك (لا تطلب موافقة)، ويتم إيقاف العمل لطلب الموافقة فقط عند محاولة تجاوز هذا النطاق. يتحكم الأول على مستوى «البند»، بينما يتحكم الثاني على مستوى «النطاق الكلي»، وهذا هو الاختلاف الجوهري في التفكير.
قمنا بتلخيص العلاقة بين النظامين في جدول المقارنة التالي لتسهيل الانتقال:
| النتيجة المطلوبة | كيف تفعلها في Claude Code | كيف تفعلها في Codex |
|---|---|---|
| السماح بالقراءة فقط ومنع أي تعديل | وضع default / القراءة فقط | sandbox على read-only |
| السماح بالتعديل في المشروع، وطلب الإذن عند الخروج | وضع acceptEdits وما شابه | sandbox على workspace-write + الموافقة على on-request (المزيج الذهبي اليومي) |
| تشغيل تلقائي بالكامل دون أي أسئلة | وضع bypassPermissions | sandbox على danger-full-access + الموافقة على never (أو استخدام خيار --yolo للتجاوز الكامل للـ sandbox) |
| منع تشغيل أمر خطر محدد | تحديده في قواعد permissions.deny | استخدام خيار القواعد (تجريبي) مثل prefix_rule() لمطابقة بادئة الأمر وتعيين decision = "forbidden" |
| تبديل مستويات الأمان | استخدام الاختصار Shift+Tab | استخدام أمر /permissions في الجلسة أو خيارات -s / -a عند البدء |
بعض النقاط الجوهرية التي يجب استيعابها بعد الانتقال:
أولاً: «عدم السؤال» لا يعني «إطلاق الصلاحيات». في Claude Code، يؤدي خفض مستويات الأسئلة إلى زيادة الصلاحيات تلقائيًا؛ بينما في Codex، المفتاحان منفصلان تمامًا — يمكنك اختيار «القراءة فقط + عدم السؤال» (read-only + never)، ويعني هذا «السماح بالقراءة الكاملة، مع عدم مقاطعة العمل بأي أسئلة أثناء القراءة». خيار never يعني «منع ظهور نوافذ الموافقة» وليس «فتح الصلاحيات بالكامل».
ثانياً: يرتبط المستوى الافتراضي بـ «وجود مستودع Git من عدمه». يقوم Codex باختيار المستوى تلقائيًا عند البدء: إذا كان المجلد يحتوي على Git، فسيختار workspace-write + on-request (الوضع التلقائي Auto)، وإذا لم يكن يحتوي على Git فسيختار read-only افتراضيًا. هذا التصميم الذكي غير متوفر في Claude Code، ويمثل شبكة أمان هامة — لمنع فتح الصلاحيات الكاملة بالخطأ في مجلدات مؤقتة لا تحتوي على Git (تحدثنا بالتفصيل في [15] عن كيفية حماية العمل باستخدام هذا الإعداد).
ثالثاً: عند اختيار workspace-write يتم إغلاق الوصول للشبكة وحماية مجلد .git كقراءة فقط افتراضيًا. قد تبدو هذه الإعدادات الافتراضية معاكسة للبديهة، والاعتماد بالكامل على تجربة Claude Code قد يسبب مشاكل هنا. إذا كنت بحاجة للوصول للشبكة، يجب تفعيل خيار network_access يدويًا.
شرح تفاصيل نموذج الصلاحيات (كيفية دمج المستويات الثلاثة، وطريقة كتابة القواعد rules، ومحاذير --yolo) موجود في 〔15 الصلاحيات والـ sandbox والموافقة〕، والمهم عند الانتقال هو بناء المفهوم الجديد القائم على «مفتاحين منفصلين» وتجنب محاولة تطبيق فكرة «القائمة البيضاء» القديمة.
💡 الخلاصة في جملة واحدة: تحول مفهوم «وضع الصلاحيات وقائمة allow/deny» في Claude Code إلى «sandbox (ما يمكن عمله) + الموافقة (متى يتم السؤال) كمفتاحين منفصلين»؛ وتذكر أن «عدم السؤال لا يعني فتح الصلاحيات»، ويرتبط المستوى الافتراضي بوجود Git، ويتم إغلاق الشبكة افتراضيًا في وضع
workspace-write.
06 عادات التفاعل: أوجه التشابه والاختلاف في أوامر الخط المائل وإدارة الجلسات
الخبر السار هنا: بمجرد دخول الجلسة، ستجد أن أغلب ذاكرتك العضلية صالحة للاستخدام المباشر. حيث تتشابه أوامر الخط المائل إلى حد كبير بين الأداتين، وتتطابق أسماء الأوامر الأكثر استخدامًا.
| المهمة المطلوبة | في Claude Code | في Codex | هل الاسم متطابق؟ |
|---|---|---|---|
| التبديل بين النماذج | /model | /model | ✅ |
| ضغط السياق | /compact | /compact | ✅ |
| مسح الشاشة وبدء جلسة جديدة | /clear | /clear | ✅ |
| عرض الحالة / الإعدادات | /status (أو /config) | /status | تطابق شبه كامل |
| إنشاء ملف توجيهات المشروع | /init | /init | ✅ (أحدهما ينشئ CLAUDE.md والآخر ينشئ AGENTS.md) |
| عرض فروق التعديلات | /diff | /diff | ✅ |
| مراجعة وتدقيق التعديلات | /review | /review | ✅ |
| ضبط مستويات الأمان والصلاحيات | الاختصار Shift+Tab | /permissions | ❌ يختلف موضع الضبط |
تتركز الاختلافات في نقطتين أساسيتين:
أولاً: اختلاف موضع ضبط الصلاحيات. يعتمد Claude Code على الاختصار Shift+Tab للتنقل الدائري بين أوضاع الصلاحيات؛ بينما يعتمد Codex على كتابة أمر الخط المائل /permissions لفتح قائمة الاختيار وتحديد المستوى المطلوب. الوظيفة متطابقة، ولكن أسلوب العمل يختلف — من اختصار لوحة المفاتيح إلى قائمة الاختيار.
ثانياً: تقسيم وظائف /clear و /new بشكل أكثر دقة في Codex. يمثل أمر /clear في Codex «مسح الشاشة وبدء جلسة جديدة»، بينما يمثل أمر /new «بدء جلسة جديدة مع الاحتفاظ بمحتوى الشاشة». في المقابل، يعتمد Claude Code بشكل أساسي على أمر /clear لمسح المهمة وبدء جلسة جديدة (مع إمكانية استعادة الجلسة القديمة عبر /resume). وهو اختلاف بسيط يكفي معرفة وجوده.
تجربتي الشخصية في الأسبوع الأول بعد الانتقال: لم أحتج للبحث عن الأوامر تقريبًا — حيث استخدمت /model للتبديل و /status لمراجعة الحالة و /compact لضغط السياق بشكل تلقائي. الموضع الوحيد الذي واجهت فيه صعوبة هو محاولة ضبط الصلاحيات، حيث ضغطت على Shift+Tab كالعادة دون استجابة، وتذكرت حينها أن Codex يتطلب كتابة /permissions. قائمة أوامر الخط المائل الكاملة متوفرة في 〔12 أوامر الخط المائل واختصارات لوحة المفاتيح〕، ولكن يمكنك البدء بالاعتماد على عاداتك القديمة ومراجعة القائمة عند الحاجة فقط.
💡 الخلاصة في جملة واحدة: تتطابق أغلب أوامر الخط المائل بين الأداتين (
/model،/compact،/clear،/diff،/reviewبنفس الأسماء)، واستخدم عاداتك القديمة مباشرة؛ والاختلاف الأبرز هو ضبط الصلاحيات — استخدام/permissionsفي Codex بدلاً منShift+Tabفي Claude Code.
07 لا تفترض البديهيات: هذه الميزات غير موجودة أو مختلفة في Codex
أكبر محاذير الهجرة ليس في «عدم معرفة كيفية الاستخدام»، بل في «افتراض أن الميزات تعمل بنفس الطريقة بينما هي مختلفة في الواقع». نوضح في هذا القسم بعض النقاط التي يسهل الخلط فيها.
أولاً: اختلاف الحالة الافتراضية لنظام الذاكرة. يعمل نظام الذاكرة التلقائية في Claude Code بشكل مفعل افتراضيًا، ويتم تقسيم الذكريات حسب مستودع git وقراءتها تلقائيًا عند بدء العمل. بينما يعمل نظام Memories في Codex بشكل مغلق افتراضيًا، ويخضع لقيود جغرافية، وينشأ بشكل غير متزامن في الخلفية، ويختلف مسار حفظه وطريقة التحكم فيه تمامًا. عندما انتقل صديقي للعمل مع Codex، افترض أن «الذكاء الاصطناعي يتذكر كل ما أقوله تلقائيًا» — وتسبب ذلك في استخدام مدير حزم خاطئ لاحقًا، لأنه افترض توفر الذاكرة الافتراضية كما في Claude Code. تذكر كتابة القواعد الصارمة التي يجب الالتزام بها في ملف توجيهات المشروع (AGENTS.md) مباشرة في كلتا الأداتين، وتجنب الاعتماد على الذاكرة التلقائية، لمزيد من التفاصيل راجع [19].
ثانياً: ميزات حصرية في Codex وغير متوفرة في Claude Code. لا تفترض أن الميزات تم تغيير أسمائها فقط، فبعضها مضاف حديثًا:
AGENTS.override.md: ملف التجاوز المؤقت في نفس المستوى، ولا يوجد ما يقابله في Claude Code (انظر [11]).- Chronicle: إمكانية تغذية الذاكرة بناءً على محتوى الشاشة، وهي نسخة تجريبية للبحث (research preview) تتطلب تفعيلها يدويًا وتخضع لقيود جغرافية، وهي حصرية لـ Codex (انظر [19]).
- تحديد الصلاحيات التلقائي بناءً على Git: تحديد وضع الـ sandbox تلقائيًا عند البدء بناءً على وجود Git في المجلد (انظر [15]).
ثالثاً: اختلاف شكل بعض الميزات المقابلة. على سبيل المثال، يقابل ملف التجاوز الشخصي CLAUDE.local.md في Claude Code ملف AGENTS.override.md في Codex ولكن بطبيعة عمل مختلفة؛ وتقابل القائمة البيضاء للتحكم في الأوامر قواعد rules تجريبية في Codex (تكتب بلغة Starlark وليس كصفوف JSON).
قائمة «لا تفترض البديهيات» لمراجعتها قبل البدء:
| ما قد تفترضه | الواقع في Codex |
|---|---|
❌ يقرأ Codex ملف CLAUDE.md تلقائيًا | ✅ يقرأ فقط ملف AGENTS.md (إلا إذا قمت بتحديد project_doc_fallback_filenames) |
| ❌ الذاكرة تعمل افتراضيًا وتسجل كل شيء | ✅ ميزة Memories مغلقة افتراضيًا وتنشأ بشكل غير متزامن وتخضع لقيود جغرافية |
❌ يمكن نسخ ملف settings.json مباشرة | ✅ يجب إعادة كتابة الإعدادات بصيغة TOML في ملف config.toml |
| ❌ يتم تحديد الصلاحيات كقائمة بيضاء للأدوات | ✅ يتم التحكم عبر مفتاحي sandbox والموافقة بشكل منفصل |
❌ استخدام الاختصار Shift+Tab لتبديل الصلاحيات | ✅ كتابة أمر /permissions في Codex |
💡 الخلاصة في جملة واحدة: أكبر محاذير الهجرة هو افتراض تطابق الميزات — فالذاكرة مغلقة افتراضيًا، ويحتوي Codex على ميزات حصرية مثل
AGENTS.override.mdو Chronicle والتحديد التلقائي للصلاحيات بناءً على Git، ويتم التحكم في الصلاحيات عبر مفاتيح منفصلة وليس كقوائم بيضاء. راجع هذه القائمة قبل البدء.
08 الجزء العملي: تحويل ملف CLAUDE.md إلى AGENTS.md
القراءة دون تطبيق غير مفيدة لتثبيت المعلومات. سنقوم في هذا الجزء بتحويل ملف CLAUDE.md حقيقي إلى AGENTS.md عمليًا، والتأكد من قراءته في Codex. اتبع الخطوات، ولن يستغرق الأمر أكثر من خمس دقائق.
ملاحظة بشأن نظام التشغيل: يمكن تشغيل أوامر mkdir و git init التالية مباشرة في أنظمة Mac / Linux؛ بينما يفضل تشغيلها في Windows باستخدام Git Bash أو WSL، أو إنشاء المجلدات يدويًا عبر مستكشف الملفات. يرمز الرمز ~ إلى دليل المستخدم الرئيسي (يقابل في Windows المسار C:\Users\username\).
الخطوة الأولى: إعداد ملف CLAUDE.md تجريبي.
أنشئ مجلد مشروع تجريبي، وضع فيه ملف CLAUDE.md نموذجيًا (كما لو كنت قد نقلته من مشروع Claude Code القديم):
mkdir migrate-demo && cd migrate-demo
git initأنشئ ملفًا باسم CLAUDE.md في جذر المشروع، واكتب فيه المحتوى التالي (يحتوي عمدًا على فقرة زائدة لتوضيح عملية التنظيف):
# migrate-demo 项目说明
这是一个基于 FastAPI 的订单管理后端。本项目由订单团队在 2023 年立项，
最初用 Flask，后来为了异步性能迁到 FastAPI，技术选型经过三轮评审……（一大段背景）
## 技术栈
- Python 3.11 / PostgreSQL / pytest
## 常用命令
- `pytest` —— 运行测试
- `ruff check .` —— 跑 lint
## 编程约定
- 所有函数必须有类型注解
- 字符串统一用双引号
## 禁区
- 不要改动 migrations/ 里已有的迁移文件
- 新增生产依赖前先问我النتيجة المتوقعة: ظهور ملف CLAUDE.md في جذر المشروع. تذكر أن الفقرة الخاصة بخلفية المشروع — غير ضرورية لعمل Codex، وهي ما يجب حذفه عند تحويل الملف.
الخطوة الثانية: كتابة ملف AGENTS.md.
أنشئ ملفًا جديدًا باسم AGENTS.md في جذر المشروع، وانقل المحتوى إليه مع حذف فقرة خلفية المشروع (واحتفظ بباقي التعليمات كما هي):
# migrate-demo — 基于 FastAPI 的订单管理后端
## 技术栈
- Python 3.11 / PostgreSQL / pytest
## 常用命令
- `pytest` —— 运行测试
- `ruff check .` —— 跑 lint
## 编程约定
- 所有函数必须有类型注解
- 字符串统一用双引号
## 禁区
- 不要改动 migrations/ 里已有的迁移文件
- 新增生产依赖前先问我النتيجة المتوقعة: ظهور ملف AGENTS.md في جذر المشروع، بحجم أصغر من ملف CLAUDE.md الأصلي — حيث تم حذف الفقرات التي يمكن لـ Codex استنتاجها من الكود أو غير الضرورية لعمله. ويمثل هذا مثالاً عمليًا لـ «نقل المحتوى مع تنظيفه».
الخطوة الثالثة: التحقق من قراءة الملف في Codex.
قم بتشغيل الأمر التالي في مجلد المشروع (يقوم هذا الأمر بقراءة ملخص التعليمات، ونضيف خيار --ask-for-approval never لمنع ظهور نوافذ طلب الموافقة والحصول على مخرجات نظيفة — وهي الطريقة القياسية الموصى بها في المستندات الرسمية للتحقق من قراءة ملف AGENTS.md):
codex --ask-for-approval never "Summarize the current instructions."النتيجة المتوقعة: سيقوم Codex بعرض القواعد التي كتبتها للتو — بيان التقنيات، وأوامر pytest / ruff، وقواعد كتابة التوقيعات وعلامات التنصيص المزدوجة، ومحاذير مجلد migrations وإضافة الاعتمادات. ويؤكد هذا أن ملف AGENTS.md قد تم تحميله في سياق الجلسة الحالية بنجاح، وأن عملية التحويل تمت بنجاح.
الخطوة الرابعة: التعامل مع ملف CLAUDE.md القديم (اختياري).
بعد التأكد من نجاح التحويل، لا يؤثر وجود ملف CLAUDE.md القديم على عمل Codex (حيث سيتجاهله تلقائيًا)، ولكن قد يسبب خلطًا لباقي أعضاء الفريق. ويمكنك حذفه يدويًا إذا أردت — وهي عملية تتطلب تعديل الملفات لذا يفضل القيام بها يدويًا وتجنب ترك الأداة تقوم بها تلقائيًا. وإذا كنت تريد من Codex قراءة ملف CLAUDE.md أيضًا (كفترة انتقالية لتشغيل الملفين معًا)، يمكنك إضافة الإعداد التالي في ملف ~/.codex/config.toml:
# ~/.codex/config.toml
project_doc_fallback_filenames = ["CLAUDE.md"]عند إضافة هذا الإعداد، سيقوم Codex بالبحث في كل مجلد بالترتيب التالي: AGENTS.override.md ← AGENTS.md ← CLAUDE.md، ويختار أول ملف متوفر وغير فارغ — وهي الطريقة الأسهل للسماح بقراءة ملفات CLAUDE.md القديمة خلال الفترة الانتقالية (يتطلب إعادة تشغيل Codex لتفعيل التغيير).
💡 الخلاصة في جملة واحدة: تتلخص الهجرة في نقل محتوى
CLAUDE.mdإلىAGENTS.mdمع تنظيف الفقرات غير الضرورية، والتحقق عبر أمر «Summarize the current instructions»؛ ويمكن تفعيل خيارproject_doc_fallback_filenamesللسماح بقراءة ملفاتCLAUDE.mdالقديمة مؤقتًا.
ملخص
قمنا في هذه المقالة بمراجعة متطلبات الانتقال من Claude Code إلى Codex من الجانب الذهني والعملي:
| البعد | الخلاصة الأساسية |
|---|---|
| التقييم العام | 90% من النموذج الذهني قابل للنقل مباشرة، وينحصر التعلم في مسميات وأماكن الميزات الجديدة |
| توجيهات المشروع | الانتقال من CLAUDE.md ← AGENTS.md مع إمكانية نقل المحتوى، ومراعاة اختلاف آلية التجاوز وحجم الملف (الأسطر ← البايت) |
| ملف التكوين | الانتقال من settings.json (JSON) ← config.toml (TOML) كـ إعادة كتابة للصيغة، وتجنب استخدام الفاصلة كما في JSON |
| نموذج الصلاحيات | تحول قواعد allow/deny والوضع العام إلى مفتاحي sandbox والموافقة كخيارين منفصلين، وتذكر أن «عدم السؤال لا يعني فتح الصلاحيات» |
| عادات التفاعل | تتشابه أغلب أوامر الخط المائل، والاختلاف الأبرز هو طريقة ضبط الصلاحيات (Shift+Tab ← /permissions) |
| لا تفترض البديهيات | ميزة Memories مغلقة افتراضيًا، ويحتوي Codex على ميزات حصرية مثل AGENTS.override.md و Chronicle |
ينبغي عليك الآن أن تكون قادرًا على: تحويل ملف CLAUDE.md إلى AGENTS.md بشكل نظيف؛ ومعرفة كيفية إعادة كتابة خيارات settings.json في ملف config.toml؛ واستبدال نموذج وضع الصلاحيات والقوائم البيضاء بنموذج مفتاحي الـ sandbox والموافقة؛ وتجنب الأخطاء الشائعة الناتجة عن افتراض تطابق الميزات. وباختصار — خبرتك في استخدام Claude Code تظل صالحة ومفيدة، وكل ما تحتاجه هو استخدامها مع الأداة الجديدة لتصل إلى بيتك بأمان.
المقالة التالية 〔33 نقاط استخدام Windows الأساسية〕 — ذكرنا في الخطوات العملية السابقة نصائح لمستخدمي نظام Windows لتشغيل الأوامر عبر «Git Bash أو WSL»، فلماذا نحتاج لذلك؟ وما هي المشاكل الحصرية لـ Codex عند تشغيله على نظام تشغيل Windows فيما يتعلق بالـ sandbox والمسارات والطرفية؟ فكر في هذا السؤال البسيط: كيف يمكن لـ Codex التحكم في الصلاحيات في نظام تشغيل لا يحتوي افتراضيًا على آليات العزل المتوفرة في أنظمة Linux؟ سنوضح ذلك بالتفصيل في المقالة القادمة.