التشغيل الآلي والتكامل المستمر (CI/CD): توظيف Codex للعمل في الخلفية

📚 التنقل في السلسلة: المقال السابق [26 · التكامل مع Git و GitHub] علمك كيفية استخدام Codex محلياً وسحابياً لإدارة الفروع، كتابة الرفع، وفتح PRs - وكانت كل هذه الخطوات تتم أثناء جلوسك أمام الشاشة وتوجيه المساعد خطوة بخطوة. ينقل هذا المقال العمل لمرحلة "التشغيل المستقل بالكامل دون إشراف": فبمجرد إعداد الخطوات، يتولى Codex مراجعة PRs تلقائياً فور فتحها، ويرسل مقترح إصلاح بمجرد فشل اختبارات CI، ويولد لك تقريراً دورياً بالتعديلات اليومية للمشروع، وكل ذلك دون تدخل منك. المقال التالي [28 · الوضع غير التفاعلي (codex exec)] سيتحدث عن تفاصيل الأمر البرمجي الأساسي المحرك لهذه العمليات.

يقول الكثيرون أن "الفائدة الكبرى لأدوات البرمجة بالذكاء الاصطناعي تكمن في العمل المشترك بجانبك أثناء كتابة الأكواد والتحاور المباشر" - ولكن لنكن صادقين، فهذا الشرح يمثل نصف الحقيقة فقط.

بعد استخدام Codex لأكثر من نصف عام، تيقنت من حقيقة هامة: تظهر الفائدة الحقيقية والإنتاجية الكبرى للمساعد في الأوقات التي تكون فيها غائباً عن جهازك. فالتطوير المشترك يتطلب وجودك المستمر، ومراجعتك للخطوات، وتوجيه العمل، ويمثل دور المساعد هنا دور المنفذ المتابع، ويتوقف العمل بمجرد إغلاقك للجهاز. ولكن العمل البرمجي يحتوي على مهام متكررة وروتينية - كفحص كل PR يتم فتحه، تتبع أسباب فشل اختبارات CI ليلاً، وإعداد تقرير الأسبوع لمدير المشروع - وهي مهام تكرارية وتتبع نفس القواعد والخطوات، ويمل المطورون من تكرارها.

وتمثل هذه المهام الروتينية بيئة العمل المثالية للتشغيل الآلي. فبمجرد ربط Codex بخطوات التكامل المستمر (CI) أو تهيئته كمهام مجدولة في الخلفية، يتحول من "مساعد محلي يحتاج توجيهاً مستمراً" إلى "حارس أمني ومطور إضافي يتابع مستودع كود الشركة أثناء نومك". يشرح هذا المقال أسلوب التهيئة بالكامل بالاعتماد على مسارين: الأول ربط Codex بخطوات البناء البرمجية (GitHub Actions) للتكامل المستمر (CI/CD)، والثاني كتابة مهام مجدولة (Automations) في تطبيق سطح المكتب لتعمل في الخلفية محلياً، لتؤسس حزمة أتمتة تعمل لصالحك على مدار الساعة.

بقراءة هذا المقال، ستحصل على:

• التمييز الواضح بين مساري الأتمتة - ميزة openai/codex-action للتكامل المستمر (CI/CD)، وميزة Automations في تطبيق سطح المكتب للمهام المجدولة، وتحديد التخصص لكل منهما
• نموذج جاهز لملف تكوين GitHub Action (ملف YAML) مع شرح وظيفة السطور لاستخدامه في مراجعة PRs مباشرة
• فهم خيارات مدخلات أداة codex-action الأساسية (مثل prompt-file و sandbox و safety-strategy و final-message وغيرها) بناءً على الوثائق الرسمية
• كيفية حفظ وتأمين مفتاح OpenAI في إعدادات GitHub Secrets، وفهم الحدود الأمنية لمتغيرات البيئة
• كيفية تهيئة المهام المجدولة (Automations) في تطبيق سطح المكتب، مراجعة تقارير التنفيذ، والتمييز بين وضع المجلد المحلي ومجلد العمل المستقل (Worktree)
• تدريب عملي بسيط قابل للتنفيذ: إعداد وتفعيل خطة "تقرير التعديلات اليومي" تلقائياً

⚠️ جميع الأوامر، ومدخلات الإجراءات (actions)، والخيارات المذكورة أدناه تستند للوثائق الرسمية لـ Codex (مستندات GitHub Action و Automations)؛ وتعتمد أرقام الإصدارات ومسميات النماذج على ما يتوفر لديك محلياً حالياً.

---

01 مسارا الأتمتة وتحديد مسارات العمل

نبدأ بالخلاصة ونوضح المسارين لتجنب الخلط بين الاستخدامات:

• المسار الأول: خطوات البناء البرمجية (GitHub Actions) عبر openai/codex-action. يتم تشغيله على خوادم الاستضافة لـ GitHub (GitHub-hosted runners)، ويفعل بناءً على أحداث المستودع (مثل فتح PR، رفع تعديل، أو فشل البناء)، ويختص بـ تنسيق التكامل المستمر (CI/CD). ويخدم مهام الفريق البرمجية المشتركة: مراجعة طلبات السحب، التأكد من جودة الأكواد قبل الدمج، ومحاولة إصلاح أعطال البناء تلقائياً.
• المسار الثاني: المهام المجدولة (Automations) في التطبيق. يتم تشغيله على جهازك المحلي الذي يعمل عليه تطبيق سطح المكتب لـ Codex، ويفعل بناءً على الوقت (مواعيد محددة أو فترات تكرارية cron)، ويختص بالمهام الشخصية وجلسات الخلفية. ويخدم دورتك اليومية: إعداد ملخص التعديلات اليومي، مراجعة دورية لملفات المشروع، وتتبع ومراقبة العمليات الطويلة.

لماذا نؤكد على الفصل بينهما؟ لأن الخطأ الشائع للمبتدئين يكمن في محاولة توظيف مسار لخدمة متطلبات المسار الآخر - كإعداد خطة مراجعة PRs تلقائية للفريق داخل تطبيق سطح المكتب لجهازك (مما يعطل المراجعة عند إغلاق جهازك)؛ أو إعداد خطة مراجعة ملفات جهازك الشخصية في ملف GitHub Actions السحابي (الذي يعجز عن الوصول لملفات جهازك المحلية). واختيار المسار الخاطئ يعطل عمل الأتمتة بالكامل.

تشبيه: حارس مبنى الشركة مقابل سكرتيرك الشخصي. يمثل خيار GitHub Action حارس أمن المبنى - فهو لا يعيش في منزلك، بل يتواجد في غرفة التحكم بالمبنى الرئيسي (خوادم GitHub السحابية)، ويبدأ العمل فور رصد أي حركة بالمبنى (فتح PR أو إنذار حريق)، ويلتزم المطورون بالمرور عليه. ويمثل خيار Automations سكرتيرك الشخصي - الذي يعمل في منزلك (جهازك الشخصي) ويلتزم بجدول مواعيدك (مثل تنظيم البريد كل صباح)، وإذا كان المنزل مغلقاً (جهازك مطفأ) فلا يمكنه البدء. الأول يدير سلامة وتكامل العمل المشترك للفريق، والثاني ينظم مهامك الفردية المجدولة - وتجنب خلط المسؤوليات.

مقارنة شاملة بين المسارين:

وجه المقارنة	خطوات البناء (GitHub Action)	المهام المجدولة (Automations)
مكان التشغيل	خوادم GitHub السحابية (GitHub runners)	جهازك الشخصي المشغل لتطبيق Codex
مؤشر التفعيل	أحداث المستودع (فتح PR، push، انتهاء البناء)	مواعيد زمنية محددة (مواقيت يومية أو فترات cron)
التواجد البشري	لا يتطلب تشغيل جهازك وتعمل السحابة بشكل مستقل	يتطلب بقاء جهازك وتطبيق Codex نشطين
الاستخدام الأنسب	مراجعة PRs، فحص جودة الأكواد، وإصلاح البناء	إعداد تقرير يومي، مراجعة دورية، ومراقبة العمليات
نطاق التأثير	حماية وتأمين مستودع الفريق (CI/CD)	تنظيم وتسهيل المهام الفردية للمطور

يتناول المقال المسار الأول (GitHub Action) في الأقسام 02 إلى 05، ويليه المسار الثاني (Automations) في القسم 06، ثم التطبيق العملي في القسم 07.

💡 ملخص في جملة واحدة: تنقسم أتمتة Codex لمسارين - سحابي عبر GitHub Action يعمل بناءً على أحداث المستودع لحماية كود الفريق، ومحلي عبر ميزة Automations في تطبيق سطح المكتب يعمل بناءً على الوقت لتنظيم مهامك؛ واحرص على اختيار المسار الأنسب للمهمة.

---

02 ما هي ميزة GitHub Action لـ Codex؟

نبدأ بالمسار الأول. الخلاصة الفنية: يمثل الإجراء openai/codex-action حزمة معدة بواسطة OpenAI لتثبيت واجهة CLI لـ Codex وتهيئة قنوات الاتصال والترخيص في خوادم GitHub، لتشغيل أمر codex exec البرمجي بنجاح. وتوفر عليك الحزمة عناء كتابة سطور التثبيت والترخيص اليدوية في كل ملف workflow.

ونشير لمصطلح تقني هام: codex exec. وهو عبارة عن الوضع غير التفاعلي (non-interactive mode) لـ Codex - حيث ترسل له سطر الطلب مباشرة من الطرفية، ليقوم بمعالجته وإرجاع النتائج ثم الإغلاق فوراً ودون فتح واجهة المحادثة التفاعلية الكلية. وهو الوضع المصمم لخدمة السكربتات وعمليات CI. وتذكر أن خيار GitHub Action يعتمد في الخلفية على تشغيل أمر codex exec (وسنشرح تفاصيل هذا الأمر في المقال 28).

تصف الوثائق الرسمية وظيفته كالتالي:

يتيح استخدام إجراء Codex GitHub Action (openai/codex-action@v1) تشغيل Codex محاكاة التعديل وإجراء المراجعات وإعادة توجيه النتائج مباشرة من خطوات البناء. وتتولى الحزمة تثبيت CLI وتنشيط الترخيص وتشغيل أمر codex exec بالصلاحيات المحددة.

تشبيه: صندوق الأدوات المجهز لرحلات العمل الخارجية. عند سفرك لمقر العميل (خوادم GitHub السحابية)، يمكنك اختيار نقل معداتك الثقيلة وتركيبها وتعديل أسلاكها يدوياً هناك (تثبيت CLI يدويًا وتعديل التراخيص لمتغيرات البيئة) - أو يمكنك ببساطة جلب صندوق أدوات مجهز للعمل المباشر (codex-action) بمجرد فتحه تجد التوصيلات مجهزة والتراخيص مؤمنة، ويكفي كتابة وجهة العمل (نص الطلب prompt) للبدء. وتكمن قيمة الصندوق في اختصار وقت التركيب وتأمين التراخيص أمنياً في البيئة الخارجية كما سنبين في القسم 05.

أهم استخدامات GitHub Action وفقاً للوثائق:

• إرسال تعليقات وملاحظات Codex التلقائية لطلبات السحب أو الإصدارات دون حاجة لإدارة CLI يدوياً.
• إدراج مراجعة Codex كبوابة فحص إلزامية للبناء لمنع دمج الكود البرمجي عند رصد مشاكل.
• تشغيل مهام دورية ومؤتمتة للمستودع (مراجعة الأكواد، تهيئة ملفات الإصدار، وتعديل الهياكل البرمجية) بتنسيق ملفات workflow.

وننبه لنقطة تقنية هامة: لا يتم تفعيل هذا المسار بكتابة التعليقات في الويب. بل هو جزء من خطوات GitHub Actions المعتادة - والتي تفعل بناءً على أحداث ملف التكوين المحددة في قسم on: (مثل فتح PR أو دفع التغييرات). وتختلف هذه الأتمتة عن أسلوب استدعاء المساعد بكتابة تعليق.

💡 ملخص في جملة واحدة: يمثل الإجراء openai/codex-action حزمة مجهزة لتثبيت CLI وإعداد تراخيص الاتصال في خوادم GitHub لتشغيل أمر codex exec في الخلفية؛ ويفعل تلقائياً بناءً على أحداث المستودع في قسم on: لمراجعة الكود وتأمين الجودة.

يوضح المخطط التالي مسار عمل الأتمتة السحابية بالكامل:

يوضح المخطط خط سير العمل: عند وقوع حدث في المستودع (مثل push أو Pull Request أو مواقيت cron)، يتم تشغيل ملف workflow سحابياً، ويقوم المساعد في خادم GitHub (runner) بتشغيل أمر codex exec غير التفاعلي مستعيناً بالنصوص البرمجية المرفقة، ليعيد النتائج (تعليقات مراجعة في PR، تعديلات على الملفات، أو تقارير فنية) دون تدخل بشري.

---

03 نموذج ملف التكوين (Workflow YAML) لمراجعة PRs

نعرض هنا ملف التكوين المقترح رسمياً لمراجعة طلبات السحب تلقائياً ونشرح سطوره لمساعدتك في تخصيصه لمشروعك.

تشبيه: خطة توزيع المهام للحراسة والأمن. يتكون ملف YAML من خطوتين رئيسيتين تعملان بالتتابع: الخطوة الأولى (مهمة codex) تمثل حارس الفحص، الذي يعمل فور فتح PR لقراءة الملفات وتسجيل ملاحظات الأخطاء في ورقة خارجية (حقل final-message)؛ الخطوة الثانية (مهمة post_feedback) تمثل المراسل، الذي يتسلم الورقة من حارس الفحص ويقوم بلصقها في تعليقات PR على الويب في حال وجود ملاحظات مسجلة. ونعتمد هذا الفصل لـ أسباب أمنية صارمة سنبينها في القسم 05 (منع منح صلاحية الكتابة لخطوة المراجعة الأولى).

إليك كود ملف التكوين (تم تبسيطه وتحديث الحزم البرمجية لتناسب الاستخدام المباشر):

# مسار الملف في مستودعك: .github/workflows/codex-review.yml
name: Codex pull request review
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  codex:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    outputs:
      final_message: ${{ steps.run_codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
          persist-credentials: false

      - name: Run Codex
        id: run_codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/review.md
          output-file: codex-output.md

  post_feedback:
    runs-on: ubuntu-latest
    needs: codex
    if: needs.codex.outputs.final_message != ''
    permissions:
      issues: write
      pull-requests: write
    steps:
      - name: Post Codex feedback
        uses: actions/github-script@v7
        with:
          github-token: ${{ github.token }}
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: process.env.CODEX_FINAL_MESSAGE,
            });
        env:
          CODEX_FINAL_MESSAGE: ${{ needs.codex.outputs.final_message }}

نشرح سطور الملف وأقسامه كالتالي:

القسم الأول on (شروط التفعيل): يحدد تفعيل خطة العمل عند فتح طلب السحب opened أو إضافة تعديلات جديدة للفرع synchronize أو إعادة فتحه reopened. أي أن أي تعديل أو فتح لـ PR سيفعل خطة المراجعة تلقائياً.

القسم الثاني checkout (جلب ملفات المشروع): تؤكد الإرشادات على ضرورة جلب ملفات المشروع أولاً لتتمكن أداة Codex من فحصها. ونستخدم خيار persist-credentials: false (لمنع تخزين بيانات اعتماد Git في مجلد العمل) ونحدد سحب نسخة الكود بعد الدمج التجريبي ref: .../merge لضمان دقة المراجعة. (وتقترح الوثائق خطوة إضافية تسمى Pre-fetch base and head refs لجلب الفروع البرمجية وتسهيل مقارنتها؛ قمنا باختصارها هنا لتسهيل قراءة الكود الأساسي للملف، ويمكنك جلبها لمزيد من الاستقرار).

القسم الثالث Run Codex (خطوة الاستدعاء الأساسية لـ Codex):

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    prompt-file: .github/codex/prompts/review.md
    output-file: codex-output.md

وتمرر فيها ثلاثة مدخلات: openai-api-key لتمرير مفتاح الترخيص الآمن (سنبينه في القسم 05)؛ و prompt-file ويشير لـ مسار ملف الإرشادات المكتوب في مستودعك (توصي الوثائق بحفظه في المجلد .github/codex/prompts/) ويضم خطوات المراجعة المطلوبة؛ و output-file لحفظ الملاحظات النهائية كملف مخرج على القرص لمراجعته لاحقاً.

القسم الرابع outputs و مهمة post_feedback (نشر تعليق المراجعة): تقوم مهمة codex بإخراج رسالة الملاحظات النهائية عبر الحقل final-message؛ وتتلقاها مهمة post_feedback المعتمدة عليها needs: codex وتفحص وجود ملاحظات مسجلة if: needs.codex.outputs.final_message != '' ثم تستعين بسكربت GitHub الرسمي لنشر المخرجات كتعليق مراجعة في صفحة طلب السحب.

ونوضح الحقل المخرج الأهم للأداة: final-message. تنص الوثائق على:

يقوم الإجراء بإعادة الملاحظات والرسائل النهائية لـ Codex عبر الحقل المخرج final-message لتسهيل إرسالها للخطوات التالية.

ويمثل final-message المخرج النصي النهائي لعمل المساعد - ويمكنك توجيهه للمنشورات البرمجية أو إرساله كرسالة لتطبيق Slack أو استخدامه كشرط لإتمام عمليات البناء. وتسير البيانات كالتالي: اكتمال فحص Codex ← إخراج النتائج في final-message ← تلقي المهمة التالية للمخرج ← ونشره كتعليق في PR.

توضح الرسمة مسارات التنفيذ للملف: وقوع حدث طلب السحب ← جلب الكود ← تشغيل Codex لقراءة التعديلات ومراجعتها بناءً على ملف الإرشادات ← إخراج الملاحظات عبر final-message ← والتحقق ونشرها كتعليق في PR.

ولكتابة طلبات المراجعة، توفر الأداة خيارين للمدخلات: إما prompt-file (للإشارة لملف نصي مكتوب في المشروع) أو prompt (لكتابة نص الطلب مباشرة في ملف workflow). ويجب استخدام أحدهما فقط وكتابتهما معاً يسبب فشل تشغيل الأداة. ويفضل استخدام prompt-file لتسهيل كتابة الإرشادات الطويلة ومراجعة تعديلاتها في Git.

💡 ملخص في جملة واحدة: يتكون ملف YAML من خطوتين: تشغيل Codex لفحص الكود وإخراج الملاحظات عبر final-message (بصلاحيات القراءة فقط)، ونشر الملاحظات كتعليق في PR (بصلاحيات الكتابة)؛ ويجب جلب الكود أولاً، ويحظر دمج مدخلي prompt و prompt-file معاً.

---

04 خيارات مدخلات الإجراء codex-action

تمثل خيارات الإجراء في ملف workflow معادلات للخيارات المستخدمة مع أمر codex exec في الطرفية. وتنص الوثائق على إمكانية ضبط هذه المدخلات لتخصيص عمليات التشغيل الفني للمساعد.

أهم المدخلات المعتمدة في الوثائق وقيمها:

المدخل (Input)	وظيفته	ملاحظات هامة
prompt / prompt-file	نص الطلب أو مسار ملف الإرشادات	يجب استخدام أحدهما فقط وتجنب كتابتهما معاً
sandbox	تحديد وضع صلاحيات بيئة المعزل	الخيارات: workspace-write / read-only / danger-full-access
model و effort	تحديد اسم النموذج وقوة الاستدلال	يفضل تركها فارغة ليعتمد المساعد النموذج التلقائي المحدث
output-file	مسار حفظ الرسالة النهائية كملف	يساعد في مراجعة النتائج وحفظ ملفات التقارير
codex-args	تمرير خيارات ومعاملات إضافية لـ CLI	تكتب كمصفوفة JSON (مثل ["--ephemeral"]) أو نصوص برمجية
codex-version	تحديد إصدار معين لـ CLI	عند إغفاله يعتمد النسخة المستقرة الأخيرة تلقائياً
codex-home	تحديد مسار مجلد الإعدادات المشترك لـ Codex	يستخدم لمشاركة إعدادات وخوادم MCP بين خطوات البناء

نوضح الحقول الحساسة بالتفصيل:

أهمية خيار sandbox الأمني. ناقشنا في المقال 15 بيئة المعزل وخياراتها الثلاثة (read-only للقراءة فقط، workspace-write للتعديل المحدود، و danger-full-access للصلاحيات الكاملة). وتوصي الوثائق بـ: اختيار وضع الصلاحيات الأضيق الذي يفي بمتطلبات المهمة لضمان الأمان: فإذا اقتصرت المهمة على مراجعة الكود فاختر read-only؛ وعند الرغبة في تمكينه من إصلاح الكود وتعديل الملفات فاختر workspace-write.

وننبه للقاعدة الأمنية الهامة التالية والمعلقة بالوضع التلقائي لـ CLI:

يعمل أمر codex exec افتراضياً في وضع القراءة فقط لبيئة المعزل (read-only) لحمايتك.

ويعني ذلك - أنه في حال رغبتك في تشغيل المساعد لـ تعديل الملفات وكتابة الأكواد في خوادم GitHub، فيجب كتابة سطر sandbox: workspace-write صراحة في ملف workflow، وبدون ذلك سيفشل المساعد في إجراء التعديلات ويلتزم بالقراءة فقط.

استخدام حقل codex-args لتمرير المعاملات المتقدمة. يتيح لك هذا الحقل كتابة أي خيارات برمجية يدعمها أمر codex exec محلياً. وتوصي الوثائق باستخدام الخيار --output-schema عبر هذا الحقل عند الحاجة لـ جلب مخرجات مهيكلة بصيغة JSON محددة (لإلزام Codex بالاستجابة وفق هيكل JSON محدد يسهل قراءته ومعالجته برمجياً في الخطوات التالية للـ workflow).

تجنب تحديد النماذج يدوياً. تنصح الإرشادات بترك حقلي model و effort فارغين للاعتماد على الخيارات التلقائية المحدثة للبرنامج وتجنب مشاكل توقف النماذج القديمة.

ونوضح فائدة خيار حفظ الملفات: عند تهيئة خيار output-file: codex-output.md وحفظ النتائج على القرص، يوصى بتمكين خطوة رفع الملفات كـ artifact في GitHub Actions لتسهيل تنزيل الملفات ومراجعة ملاحظات المساعد بوضوح بدلاً من البحث عنها في سجلات البناء الطويلة للمنصة.

وتتولى الحزمة البرمجية codex-action تشغيل خادم ترخيص آمن (Responses API Proxy) لتمرير مفتاح الترخيص أمنياً لخوادم OpenAI في حال إدخال المفتاح. وتساهم هذه البنية في حظر تسريب المفاتيح وحمايتها من السرقة على خوادم الاستضافة، لذا يوصى بالاعتماد على الحزمة الرسمية وتجنب التثبيت اليدوي المفرد لـ CLI في خوادم البناء.

💡 ملخص في جملة واحدة: تماثل خيارات الإجراء خيارات أمر codex exec؛ ويعمل المعزل افتراضياً في وضع القراءة فقط ويجب تمكين sandbox: workspace-write صراحة للتعديل؛ ويمكن تمرير معاملات متقدمة مثل --output-schema عبر codex-args؛ ويفضل ترك النماذج للوضع التلقائي.

---

05 حماية مفاتيح الترخيص وصلاحيات بيئة البناء أمنياً

يمثل ملف workflow كوداً برمجياً يتم قراءته وتمريره لخوادم البناء، وتتطلب معالجة مفاتيح الترخيص والصلاحيات حذراً شديداً لمنع تسريب البيانات الحساسة.

ونلتزم بالقواعد الأمنية الثلاث التالية لحماية المستودع:

أولاً: حفظ المفاتيح في GitHub Secrets وتجنب كتابتها صراحة

تنص الإرشادات البرمجية بوضوح على:

احرص على حفظ مفتاح OpenAI في إعدادات التراخيص الآمنة للمستودع (GitHub secrets) باسم مثل OPENAI_API_KEY واستدعائه في ملف workflow كمتغير محمي.

وكتابة المفتاح الفعلي صراحة في ملف workflow (الذي يتم رفعه للمستودع) يعرضه للسرقة الفورية من قبل زواحف الويب ومكتشفي الثغرات بمجرد رفع الكود، مما يترتب عليه استهلاك حسابك المالي والتعرض لإغلاق الخدمة.

تشبيه: وضع القفل الحقيقي للشركة داخل صندوق أمانات، ومشاركة رمز الاستدعاء فقط. تمثل إعدادات GitHub Secrets صندوق أمانات مشفر - حيث تحفظ فيه المفتاح الفعلي بشكل مخفي تماماً؛ وكتابة الجملة ${{ secrets.OPENAI_API_KEY }} في ملف workflow تمثل رمز استدعاء القفل للاستخدام المؤقت دون الكشف عن تفاصيله. وبذلك يظل مستودعك آمناً وقابلاً للمشاركة البرمجية بسلام.

لحفظ المفتاح: توجه لإعدادات المستودع على موقع GitHub ← اختر تبويب Settings ← ثم Secrets and variables ← Actions ← انقر على زر New repository secret واكتب الاسم OPENAI_API_KEY واكتب قيمة المفتاح الفعلي الذي جلبته من حساب OpenAI وسجل الحفظ.

ثانياً: منع كتابة المفاتيح كمتغيرات بيئة عامة للمهمة (job-level env)

تحذر الوثائق الرسمية لأمر codex exec من خطأ أمني شائع يرتكبه الكثيرون:

تجنب كتابة متغيرات المفاتيح الحساسة OPENAI_API_KEY أو CODEX_API_KEY في قسم متغيرات البيئة العامة للمهمة (job-level env) للمستودعات التي تشغل أكواداً خارجية أو تفحص كود المطورين. فقد تتمكن السكربتات الخارجية، اختبارات التبعيات، أو الخطافات البرمجية للمكتبات المثبتة من قراءة متغيرات البيئة وتسريب المفتاح.

بمعنى بسيط: حتى مع حفظ المفتاح في Secrets، فإن كتابته في أعلى المهمة كمتغير بيئة عام يجعل المفتاح متاحاً لأي عملية برمجية تعمل داخل هذه المهمة (بما في ذلك أكواد npm install للمكتبات الخارجية واختبارات الفحص). والبديل الآمن والموصى به هو تمرير المفتاح صراحة للخطوة الخاصة بـ codex-action فقط (تحت وسم with: للخطوة) لمنع بقية العمليات من قراءته.

ثالثاً: تقييد صلاحيات تشغيل Codex على خوادم البناء

تنبه الوثائق لخطورة الصلاحيات الافتراضية كالتالي: "تتوفر لـ Codex صلاحيات واسعة للوصول لملفات خادم البناء ما لم تقم بتقييدها يدوياً". وتوفر الأداة الخيارات التالية للتحكم في الصلاحيات:

خيار الأمان	وظيفة الحماية	ملاحظات هامة
safety-strategy	إجبار المساعد على التخلي عن صلاحيات sudo قبل بدء العمل لحماية مفاتيح الترخيص في الذاكرة	يفعل تلقائياً كـ drop-sudo؛ ويشترط تعديله لـ unsafe لأنظمة Windows فقط
unprivileged-user	تشغيل عمليات Codex تحت حساب مستخدم محدود الصلاحيات codex-user	يشترط منح هذا الحساب صلاحيات قراءة مجلد المستودع للعمل
read-only	حظر تعديل الملفات أو الاتصال بالإنترنت	يقتصر على تقييد عمليات Codex المباشرة، ولا يحمي مفاتيح الذاكرة بمفرده
sandbox	حظر الوصول لملفات النظام العامة خارج مجلد العمل	يفضل تحديده بأضيق نطاق يفي بالمهمة
allow-users / allow-bots	حصر صلاحية تفعيل تشغيل ملف workflow على حسابات موثوقة محددة	يقتصر تفعيل التشغيل افتراضياً على أصحاب صلاحيات الكتابة للمستودع

ونشدد على القواعد التالية:

• إبقاء خيار safety-strategy الفعال تلقائياً كـ drop-sudo دون إلغاء لحماية التراخيص في الذاكرة. ويستثنى من ذلك تشغيل خوادم البناء بنظام Windows حيث يتطلب تعديله لـ unsafe؛ وتحذر الوثائق من تشغيل وضع unsafe في خوادم البناء المشتركة لعدة مستخدمين.
• تفعيل خياري allow-users و allow-bots للمستودعات العامة المفتوحة، لمنع أي شخص مجهول من فتح PR يحتوي على أكواد خبيثة تجبر المساعد على تشغيل عمليات ضارة أو استهلاك حصص الحساب المالي دون علمك.
• تطبيق الفحص والتنظيف لنصوص الطلبات الخارجية (clean inputs) قبل تمريرها لـ Codex (مثل نصوص تعليقات PRs أو عناوين التعديلات) لمنع هجمات حقن التعليمات المكتوبة بشكل مخفي في تعليقات HTML.
• إدراج خطوة تشغيل Codex كآخر خطوة في مهام workflow لتجنب تأثير أي تعديلات برمجية قد يجريها المساعد على الخطوات الفنية التالية للبناء.

💡 ملخص في جملة واحدة: لتأمين بيئة البناء: احفظ المفتاح في Secrets ومرره صراحة لخطوة Codex فقط وتجنب تعريفه كمتغير بيئة عام للمهمة؛ وأبقِ حماية drop-sudo مفعلة، وقيد الحسابات المسموح لها بالتفعيل، ونظف النصوص الخارجية لمنع حقن التعليمات.

---

06 المسار الثاني: المهام المجدولة (Automations) في تطبيق سطح المكتب

شرحنا خطوات التكامل السحابي. وننتقل الآن للمسار الثاني - المهام المجدولة (Automations) المدارة داخل تطبيق سطح المكتب لـ Codex، والتي تفعل بناءً على مواقيت زمنية وتعمل في خلفية جهازك لتسهيل مهامك اليومية.

الخلاصة الفنية للميزة وفقاً للوثائق:

تتيح ميزة Automations تشغيل مهام Codex الدورية في خلفية جهازك؛ حيث يعرض المساعد الملاحظات والتقارير في قائمة الوارد (inbox) الخاصة بك، ويقوم بأرشفة المهام التي لم تسفر عن ملاحظات تلقائياً لتجنب إزعاجك.

تشبيه: إعداد منبه الهاتف لتذكيرك بالمهام، مع ميزة الفحص التلقائي. يماثل المنبه التقليدي تشغيل المهمة تلقائياً في وقت محدد (مثل تنبيهك لمراجعة التقارير المالية كل صباح)؛ وتضيف ميزة Automations ذكاءً إضافياً: فهي لا تكتفي بالرنين، بل تقوم بفتح التقارير وفحصها في الخلفية أولاً، فإذا رصدت خللاً أو نقصاً تقوم بتنبيهك وعرض المشكلة في صندوق الوارد، وإذا كانت التقارير سليمة وخالية من الأخطاء تقوم بأرشفة التنبيه بهدوء ودون إزعاجك. تشغيل دوري ذكي ومراعاة لتركيز المطور.

أهم حالات استخدام المهام المجدولة:

• إعداد تقرير التغيرات اليومي للمشروع: جلب التعديلات التي تمت في الفروع الرئيسية للمشروع خلال الـ 24 ساعة الماضية، وتصنيف التعديلات وتلخيصها في تقرير مبسط جاهز للإرسال للإدارة كل صباح.
• فحص سلامة الأكواد المرفوعة: تشغيل فحص أمني دوري للتعديلات الأخيرة للتأكد من خلوها من الأخطاء ومحاولة إصلاحها تلقائياً.
• مراقبة العمليات الطويلة: فحص خوادم الفحص أو متابعة حالة طلبات سحب معينة بشكل دوري وتحديث حالتها في المحادثة.

التمييز بين المهمة المستقلة والمهمة المتصلة بالجلسة

توفر المنصة خيارين لربط وتسيير المهام المجدولة يختلفان في حفظ سياق العمل:

وجه المقارنة	المهمة المجدولة المستقلة (Standalone)	المهمة المجدولة المتصلة بالجلسة (Thread automation)
مسار التنفيذ	بناء جلسة ومحادثة جديدة ونظيفة عند كل موعد تشغيل	العودة لـ نفس جلسة المحادثة السابقة ومتابعة الكتابة فيها
حفظ تاريخ العمل	لا تحفظ سياق العمليات السابقة وتبدأ الفحص من الصفر	تحفظ سياق المحادثة وتاريخ العمل السابق وتستكمل عليه
وجهة عرض المخرجات	تظهر كتقرير منفصل في قائمة الوارد (Triage)	تضاف كمشاركة جديدة داخل نفس نافذة المحادثة المحددة
الاستخدام الأنسب	المهام الدورية المنفصلة مثل التقارير اليومية للأكواد	المهام المترابطة مثل متابعة حالة بناء طويل أو فحص متكرر

وتنبه الإرشادات لكتابة نصوص توجيهية محددة للمهام المتصلة بالجلسة لتحديد خطوات العمل عند الاستيقاظ في كل دورة تشغيل وتوضيح متى يجب التوقف أو طلب إذن المطور.

التشغيل في المجلد المحلي مقابل مجلد العمل المستقل (Worktree)

عند ربط المهمة المجدولة بمستودع Git، يمكنك تحديد بيئة التشغيل كالتالي:

• وضع مجلد العمل المستقل (worktree mode): يقوم المساعد باشتقاق مجلد عمل فرعي مؤقت ومعزول لتشغيل المهمة البرمجية بداخله، وتجنب التأثير على ملفاتك المحلية غير المرفوعة لحمايتها من التداخل. وهو الخيار الموصى به لمعظم المهام.
• الوضع المحلي (local mode): يقوم المساعد بتشغيل المهمة في مجلد مشروعك الرئيسي مباشرة، مما قد يؤدي لتعديل الملفات التي تعمل عليها حالياً بالخطأ. وتجنب استخدامه إلا للضرورة.
• وفي حال غياب نظام Git للمجلد، يتم تشغيل المهمة داخل مجلد المشروع المفتوح مباشرة.

وتذكر أن كثرة المهام المجدولة في وضع worktree قد تستهلك مساحة التخزين، لذا احرص على أرشفة وحذف المهام القديمة غير المستخدمة لتطهير القرص.

خطوات التهيئة والصلاحيات الأمنية للمهام المجدولة

تعد الطريقة الأسهل لإنشاء مهمة مجدولة هي طلب ذلك من المساعد في المحادثة مباشرة - كقولك "قم بتهيئة هذه المهمة لتعمل تلقائياً كل صباح في الخلفية"، ليتولى Codex إعداد السكربت وجدولة المواعيد وتأكيد تهيئتها في لوحة المهام المجدولة (Automations). ويمكنك الاستعانة بالمهارات (skills الموضحة في المقال 22) لتنفيذ المهام المجدولة.

ونلخص القواعد الأمنية للمهام المجدولة في نقطتين:

• تعمل المهام المجدولة بصلاحيات بيئة المعزل الافتراضية للجلسة. فإذا كانت صلاحياتك الافتراضية هي للقراءة فقط read-only فستفشل مهام التعديل، ويتطلب نجاحها فتح صلاحيات الكتابة workspace-write للمشروع.
• تنفذ المهام المجدولة دون طلب تراخيص أو موافقة بشرية (approval_policy = "never") لتتمكن من العمل في الخلفية أثناء غيابك. وتفرض هذه الحرية حذراً مضاعفاً وتأكيد قيود بيئة المعزل لحماية جهازك من تشغيل عمليات ضارة في الخلفية دون علمك. لذا احرص على اختبار نصوص المهام وتأكيد سلامتها في محادثة عادية أولاً قبل جدولتها للعمل التلقائي.

⚠️ تذكر متطلبات تشغيل المهام المجدولة للمشاريع: يشترط بقاء جهازك الشخصي نشطاً، وتطبيق سطح المكتب لـ Codex مشغلاً، والمجلد مفتوحاً في التطبيق لتتمكن المهام من العمل في مواعيدها المحددة. فالسكرتير لا يعمل في غيابك عن المنزل.

💡 ملخص في جملة واحدة: تفعل المهام المجدولة (Automations) محلياً بناءً على مواقيت زمنية وتعرض تقاريرها في الوارد (Triage) عند رصد ملاحظات؛ وينصح بـ تشغيلها في وضع worktree لحماية الكود المحلي، واختبار سلامة نصوص المهام يدوياً قبل جدولتها للتنفيذ التلقائي الخالي من الموافقات.

---

07 تدريب عملي: إعداد وتفعيل مهمة مجدولة لتقرير التعديلات اليومي

نطبق معاً تدريباً عملياً متكاملاً لتهيئة وتفعيل خطة عمل مجدولة في تطبيق سطح المكتب لـ Codex لإنشاء تقرير يومي بالتعديلات البرمجية للمشروع، ومراجعة النتائج في قائمة الوارد.

الخطوة الأولى: اختبار وفحص نص المهمة يدوياً (خطوة وقائية موصى بها)

افتح مشروعك البرمجي في تطبيق Codex، وافتح محادثة عادية وأرسل الطلب التالي للتحقق من سلامة المخرجات:

قم بقراءة سجل التعديلات (Git commits) للمشروع خلال الـ 24 ساعة الماضية، واعرض لي تقريراً ملخصاً باللغة العربية يوضح:
- الميزات الجديدة المضافة (مجمعة بحسب طبيعة العمل وتجنب سرد رسائل commits يدوياً).
- الإصلاحات والتحسينات البرمجية التي تمت.
وإذا خلت الـ 24 ساعة الماضية من أي تعديل، فاكتفِ بعرض رسالة 'لا توجد تعديلات جديدة للمشروع خلال الـ 24 ساعة الماضية'.

المتوقع: سيقوم Codex بقراءة سجلات Git وعرض تقرير ملخص بالتعديلات الحالية أو إرجاع رسالة خلو التعديلات بنجاح. ويساعدك هذا الفحص في تعديل صياغة الطلب للوصول للشكل الأنسب قبل الجدولة.

الخطوة الثانية: الطلب من Codex جدولة المهمة

اكتب طلباً للمساعد لجدولة المهمة بناءً على الفحص المكتمل:

قم بجدولة مهمة التقرير اليومي السابقة لتعمل تلقائياً كل صباح في تمام الساعة 9:00 صباحاً كمهمة مجدولة مستقلة (standalone automation)، مع ضبط تشغيلها في وضع worktree لحماية الكود المحلي، وأرشفة المهمة تلقائياً ودون إزعاجي في حال عدم وجود تعديلات جديدة للمشروع.

المتوقع: سيقوم Codex بتهيئة إعدادات الجدولة وتحديد الموعد وضبط الخيارات وعرض تأكيد التهيئة في المحادثة. ويمكنك تعديل الخيارات يدوياً من قائمة المهام المجدولة لاحقاً.

ويدعم النظام كتابة مواقيت مخصصة بالاستعانة بـ صيغ cron (مثل تحديد التشغيل كل يوم اثنين صباحاً) لإدارة الجدولة بدقة.

الخطوة الثالثة: التحقق من تسجيل المهمة في لوحة التحكم

توجه للوحة التحكم الجانبية في تطبيق Codex وافتح تبويب Automations.

المتوقع: ظهور المهمة الجديدة في القائمة وتوضح موعد التشغيل (كل صباح الساعة 9:00)، ونوعها (مستقلة standalone)، وبيئة التشغيل (worktree معزول). مما يثبت نجاح جدولة العملية.

الخطوة الرابعة: تشغيل المهمة يدوياً للتحقق الفوري

لتفادي الانتظار للموعد المحدد، حدد المهمة في قائمة التبويب وانقر على زر التشغيل الفوري (Run now) لمراجعة المخرجات.

المتوقع:

• يبدأ المساعد في معالجة المهمة في الخلفية (وتشاهد مؤشر المعالجة في اللوحة).
• وعند الاكتمال: في حال وجود تعديلات للمشروع، يظهر التقرير الناتج في قائمة الوارد Triage؛ وفي حال خلو المشروع من التعديلات، يتم أرشفة المهمة تلقائياً ودون إظهار تنبيهات بناءً على شروط الطلب.
• وظهور التقرير أو الأرشفة التلقائية بنجاح يعني اكتمال دورة عمل الأتمتة.

الخطوة الخامسة: مراجعة المخرجات وإلغاء المهمة بعد انتهاء التدريب

افتح التقرير الناتج في قائمة الوارد واقرأ ملاحظاته للتحقق من سلامتها وتعديل صياغة الطلبات عند الحاجة. ولإزالة إعدادات التدريب وتوفير مساحة القرص، حدد المهمة في تبويب Automations وانقر على خيار حذف (Delete) لإزالتها وتطهير مجلدات العمل التابعة لها.

بإتمام هذه الخطوات الخمس، تكون قد تحققت عملياً من دورة تشغيل الأتمتة المحلية: اختبار الطلب ← الجدولة ← التحقق من القائمة ← التشغيل الفوري ← ومراجعة وحذف المهمة.

💡 ملخص في جملة واحدة: خطوات التدريب هي: فحص طلب التقرير يدوياً ← جدولة الطلب للعمل كل صباح بأمر worktree ← التحقق من المهمة في قائمة Automations ← تشغيلها فوراً للتحقق ← ومراجعة مخرجات الوارد وحذف المهمة بعد الانتهاء.

---

08 ملخص

شرحنا في هذا المقال خيارات التشغيل الآلي في Codex - وكيفية ربطه بخطوات البناء البرمجية (GitHub Actions) لحماية كود الفريق، وإعداد المهام المجدولة (Automations) محلياً لتسهيل مهامك اليومية وتأمين التراخيص والصلاحيات.

دعنا نلخص النقاط الأساسية معاً بشكل سريع:

الجانب	خطوات البناء (GitHub Action)	المهام المجدولة (Automations)
مكان التشغيل	خوادم GitHub السحابية (GitHub runners)	جهازك الشخصي وتطبيق Codex نشطين
مؤشر التفعيل	أحداث المستودع (فتح PR، push، انتهاء البناء)	مواقيت زمنية محددة أو فترات cron التكرارية
تكامل CLI	تعتمد على حزمة openai/codex-action لتشغيل codex exec	تدار وتجدول من واجهة التطبيق يدوياً أو بمخاطبة المساعد
خيارات الأمان	حفظ المفتاح في Secrets، واستدعائه صراحة للخطوة، وتفعيل drop-sudo	تعمل بصلاحيات المعزل الافتراضية ودون موافقة بشرية، لذا تتطلب اختباراً مسبقاً
بيئة التشغيل	تتطلب جلب الكود أولاً (checkout) وتعمل بالقراءة فقط افتراضياً	يوصى بتمكين وضع worktree المعزول لحماية الملفات المحلية
المخرجات والنتائج	تعيد النتائج عبر حقل final-message لنشره كتعليق في PR	تعرض تقاريرها في قائمة الوارد (Triage) وتؤرشف تلقائياً عند خلو الملاحظات

يجب أن تكون الآن قادراً على: التمييز بين خطوات البناء البرمجية والمهام المجدولة واختيار المسار الأنسب للمهمة؛ وقراءة وتعديل ملف YAML لربط Codex بخطوات GitHub Actions ومراجعة PRs تلقائياً؛ وضبط خيارات الإجراء وبيئة المعزل للتعديل أو القراءة؛ وحفظ مفاتيح الترخيص وتأمين الصلاحيات أمنياً؛ وتهيئة مهام مجدولة محلية في تطبيق سطح المكتب وتشغيلها في بيئة worktree معزولة؛ ومراقبة مخرجات الوارد. هذا التوظيف لخيارات الأتمتة يتيح لك تحويل Codex لحارس ومطور إضافي يتابع وينسق ويحمي مشاريعك البرمجية على مدار الساعة.

وتذكر دائماً التنبيهات الفنية - واحفظ قواعد "حفظ المفاتيح في Secrets وتمريرها صراحة للخطوة، وتمكين sandbox: workspace-write للتعديل، والتشغيل في وضع worktree للمهام المجدولة، واختبار سلامة النصوص يدوياً قبل الجدولة" لتأمين وتسريع العمل.

---

المقال التالي [28 · الوضع غير التفاعلي (codex exec)] - ساعدتنا خطوات البناء والمهام المجدولة على تشغيل Codex تلقائياً في السحاب ومحلياً. وتعتمد كل هذه العمليات في الخلفية على تشغيل الأمر البرمجي الأساسي codex exec غير التفاعلي. سنتحدث في المقال القادم بالتفصيل عن تفاصيل هذا الأمر: وكيفية صياغة الطلبات البرمجية المباشرة، وقراءة قنوات المخرجات (stdout للنتائج و stderr لتقدم العمل)، وتمرير متغيرات التنسيق لتسجيل مخرجات برمجية متكاملة تمكنك من كتابة سكربتات خاصة بك للتحكم في Codex مباشرة.

---

قراءات مقترحة

• نظام الذاكرة (Memories و Chronicle): تمكين المساعد من التعرف على سياق عملك عبر الجلسات
• أساليب صياغة الطلبات (Prompts): كيف تخاطب Codex للحصول على أفضل النتائج
• دليل البدء مع إضافات محررات الأكواد (VS Code وغيرها)