نقاط استخدام Windows الأساسية: التشغيل الأصلي (native) أم عبر WSL، كيف تعمل براحة بال
📚 التنقل في السلسلة: شرحت المقالة السابقة 〔32 الهجرة من Claude Code〕 كيفية الانتقال بسلاسة بعد الاعتياد على Claude Code. وتأتي هذه المقالة لتقديم دليل خاص لمستخدمي Windows — فبينما افترضت المقالات الثلاثين السابقة أنك تستخدم Mac أو Linux لتشغيل الأوامر، فإن جزءًا كبيرًا من المطورين يستخدمون Windows، وتختلف قواعد المسارات والسطر الجديد والـ sandbox تمامًا هنا. تجمع المقالة التالية 〔34 المشروع الختامي العملي〕 كل ما تعلمته في سلسلة Codex لتطبيقه في مشروع حقيقي متكامل.
دعني أخبرك بأمر غبي قمت به بنفسي ذات مرة.
في مارس 2026، قمت بتثبيت Codex لأول مرة على كمبيوتر محمول يعمل بنظام Windows 11 في عملي، وبحثًا عن البساطة قمت بالتشغيل مباشرة عبر PowerShell دون تثبيت WSL. تم التثبيت بنجاح، ولكن بمجرد أن طلبت منه تعديل ملف ما، ظهرت أخطاء — وظللت أدرس السجلات لفترة طويلة حتى أدركت أن المشكلة كانت في أن المشروع الذي قمت بنسخه عبر git clone من جهاز Mac الخاص بي يستخدم LF كرمز لنهاية السطر، وقام Git على Windows بتحويلها تلقائيًا إلى CRLF. وعندما قام Codex بتعديل الملف وحفظه، كانت الفروقات (diff) للملف بالكامل تحتوي على ^M، مما يعني أن كل سطر قد تم «تعديله». وافترضت حينها أن هناك خطأ في Codex، وحضّرت مسودة issue طويلة، لأكتشف في النهاية أنني لم أفهم قواعد السطر الجديد الخاصة بنظام Windows.
الحقيقة هي أنه يمكن تشغيل Codex اليوم بشكل أصلي (native) على نظام Windows وتجربته ممتازة، ولكنه يختلف عن أنظمة Mac/Linux. حيث توجد طريقتان للـ sandbox حصريتان لنظام Windows، وتستخدم المسارات الخط المائل العكسي (backslash)، وتتأثر السطور الجديدة بالمواريث التاريخية، وإذا لم تكن على دراية بهذه الأمور فستقع في المشاكل عاجلاً أم آجلاً.
توضح هذه المقالة تفاصيل تشغيل النظام على Windows: كيفية التثبيت، والمفاضلة بين التشغيل الأصلي و WSL، وكيفية تجنب المشاكل الثلاث الحصرية بنظام Windows، واختلافات الـ sandbox عن أنظمة Mac/Linux، وتشغيل مثال بسيط عمليًا عبر PowerShell.
بعد قراءة هذه المقالة، ستحصل على:
- خلاصة في جملة واحدة: الطريقة الأكثر راحة للتشغيل على Windows دون حيرة
- خطوات تثبيت Codex CLI بالكامل باستخدام سكريبت PowerShell الرسمي، والاعتمادات المسبقة المطلوبة
- مقارنة للمفاضلة بين «PowerShell الأصلي مقابل WSL2»: من أنت وأي طريق تختار؟
- كيفية تجنب المشاكل الثلاث الحصرية بنظام Windows — المسارات المائلة العكسية، سطور
CRLFالجديدة، وتنبيهات صلاحياتEveryone - الفروق بين وضعي الـ sandbox على Windows (
elevated/unelevated) مقارنة بأنظمة Mac/Linux، وماذا تفعل عند ظهور خطأ1385 - دليل عملي خطوة بخطوة لتشغيل أول مهمة Codex على Windows من الصفر
⚠️ تعتمد الأوامر ومفاتيح التكوين والسلوك الافتراضي على مستندات Codex الرسمية على Windows؛ وتتغير أسماء النماذج والحد الأقصى للميزات وأرقام الإصدارات مع التحديثات، لذا اعتمد على ما يظهره أمر
codex --helpوالواجهة الفعلية لديك. وقد قمت بتوضيح ما إذا كان الأمر يتم تشغيله في PowerShell أو في WSL shell، فلا تخلط بينهما.
01 الخلاصة في جملة واحدة: الطريقة الأكثر راحة للتشغيل على Windows
دعنا نوضح الخلاصة أولاً لتجنب الحيرة:
اعتمد افتراضيًا على «Windows الأصلي + sandbox بوضع elevated»، وهي الطريقة الرسمية الموصى بها، وتوفر أفضل سرعة وأمان كامل. وتراجع للتشغيل عبر WSL2 فقط إذا كان سير عملك يعتمد بالكامل على Linux افتراضيًا، أو إذا تعذر تشغيل وضعي الـ sandbox الأصليين على جهاز العمل الخاص بك.
أعلم أن بعض البرامج التعليمية القديمة قد تنصحك بـ «تفضيل وضع unelevated على Windows» أو «تثبيت WSL أولاً» — لكن هذه النصائح أصبحت قديمة. توضح المستندات الرسمية الآن صراحة: يتمتع sandbox الأصلي على Windows بأفضل أداء وأعلى سرعة، مع توفير نفس مستوى الأمان المتوفر في الأنظمة الأخرى؛ ووضع elevated هو الخيار الأول، بينما يمثل وضع unelevated خيارًا تراجعيًا فقط.
تشبيه: تركيب خط الإنترنت. سيقوم الفني أولاً بتوصيل كابل الألياف الضوئية مباشرة لمنزلك (elevated)، وهو الحل الأسرع والأكثر استقرارًا؛ وإذا كان المبنى لا يحتوي على ألياف ضوئية أو منع اتحاد الملاك تمديد الأسلاك، فستتراجع لاستخدام كابل إنترنت عادي (LAN) عبر المشتركين الآخرين (unelevated)؛ وإذا تعذر ذلك، فستفكر في الانتقال للعمل من غرفة مجاورة تحتوي على خط إنترنت (WSL2). في أغلب الأوقات، يتم توصيل الألياف الضوئية مباشرة ولا داعي للقلق بشأن الخيارات الأخرى.
في الواقع، ينقسم المستخدمون إلى ثلاث فئات عند الاختيار:
- تريد كتابة الكود بشكل طبيعي على Windows واستخدام أدوات Windows — اختر التشغيل الأصلي بوضع
elevatedدون تردد. - تستخدم جهازًا خاضعًا لإدارة الشركة، وقام قسم تقنية المعلومات بإغلاق صلاحيات المسؤول — سيتعذر تثبيت وضع
elevatedالأصلي، لذا استخدم وضعunelevatedمؤقتًا وقم بإخطار قسم تقنية المعلومات. - مشاريعك موجودة بالفعل داخل WSL وتعودت على أدوات Linux — شغل الأداة داخل WSL2 مباشرة وتجنب الانتقال المستمر بين البيئتين.
💡 الخلاصة في جملة واحدة: اعتمد افتراضيًا على «Windows الأصلي + elevated»، ويظل خيار WSL2 مخصصًا لمن «يعيش عمله داخل بيئة Linux» افتراضيًا وليس الخيار الأساسي للبدء.
02 التثبيت والاعتمادات المسبقة
تتمثل الطريقة الرسمية الأسهل لتثبيت Codex CLI على Windows في استخدام سكريبت التثبيت المدمج عبر PowerShell، حيث يتم التثبيت بسطر واحد.
شغل الأمر التالي في PowerShell أو Windows Terminal:
powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"وإذا كان جهازك يحتوي على Node.js بالفعل، يمكنك استخدام خيار التثبيت البديل الرسمي عبر npm:
npm install -g @openai/codexبعد اكتمال التثبيت، أغلق الطرفية وأعد فتحها لتفعيل متغيرات البيئة PATH ثم تحقق من التثبيت:
codex --versionتتكون المخرجات المتوقعة من رقم الإصدار (الرقم الفعلي يعتمد على ما قمت بتثبيته)، ويأتي بالصيغة العامة codex 0.x.x، ويؤكد ظهورها نجاح التثبيت.
هل تفضل الواجهة الرسومية بدلاً من سطر الأوامر؟ توفر الجهة الرسمية تطبيق Codex لسطح المكتب على Windows، ويمكن تحميله مباشرة من Microsoft Store؛ وإذا كنت لا تريد فتح متجر التطبيقات، يمكنك تثبيته عبر أمر
winget install Codex -s msstore. تركز هذه المقالة على واجهة CLI، وتدور الأوامر التالية حول سطر أوامرcodex.
بعض الاعتمادات المسبقة التي يفضل إعدادها لتجنب المشاكل:
| الاعتماد | سبب الحاجة إليه | كيفية الإعداد |
|---|---|---|
| Windows 11 (موصى به) | البيئة الأساسية المفضلة رسميًا والأكثر استقرارًا | الترقية إلى Win 11؛ يمكن تشغيل Win 10 أيضًا بشرط أن يكون الإصدار 1809 أو أحدث |
توفر winget | يستخدم لتثبيت أدوات بناء C++ وتطبيق سطح المكتب | قم بتحديث نظام Windows أو تثبيت App Installer عند الحاجة |
| صلاحية موافقة المسؤول | مطلوبة لإعداد sandbox بوضع elevated | انقر على «موافق» على جهازك الشخصي؛ قد تكون مغلقة في أجهزة العمل |
| أدوات بناء C++ (عند استخدام إضافات IDE) | مطلوبة لبناء بعض الاعتمادات الأصلية | تشغيل أمر winget install --id Microsoft.VisualStudio.2022.BuildTools -e |
أثناء تثبيتي الأول على نظام Windows 10، تم تثبيت إضافة الـ IDE بنجاح ولكنها ظلت «تدور دون استجابة»، واستغرق الأمر عشرين دقيقة من البحث في قسم حل المشكلات بالمستندات الرسمية لأكتشف — غياب حزم C++ لأدوات Visual Studio Build Tools. وبمجرد كتابة أمر winget install المذكور وإعادة تشغيل VS Code، عملت الأداة مباشرة. لذا إذا كنت تستخدم إضافة Codex لـ VS Code، ننصحك بتثبيت أدوات بناء C++ من البداية.
💡 الخلاصة في جملة واحدة: ينجز سكريبت PowerShell تثبيت Codex CLI بالكامل، وتركز المتطلبات على إصدار Windows وتوفر
wingetوصلاحيات المسؤول.
03 التشغيل عبر WSL مقابل PowerShell الأصلي: أي طريق تختار؟
هذا هو الخيار الأول الذي يجب على مستخدم Windows حسمه. بغض النظر عن الجدل على الإنترنت، المعيار بسيط للغاية: أين توجد ملفات كودك وسير عملك اليومي؟
تشبيه: مكان السكن. التشغيل الأصلي عبر PowerShell يشبه «السكن في مدينة Windows»، حيث تتم المعاملات وفقًا لقواعد Windows وتكون الأسرع والأسهل؛ بينما التشغيل عبر WSL2 يشبه «استئجار شقة بنظام Linux في تلك المدينة»، فإذا كنت تريد استخدام أدوات Linux وتشغيل سكريبتات Linux، فستدخل للعمل هناك. يمكن السكن في كلا الخيارين، ولكن لا يفضل الانتقال المستمر يوميًا بين مكتبي Windows و Linux — فاختيار مكان عمل أساسي هو الخيار الأفضل.
جدول المقارنة المباشر:
| البعد | PowerShell الأصلي | WSL2 |
|---|---|---|
| سهولة التثبيت | ✅ سطر تثبيت واحد | ❌ يتطلب تثبيت التوزيعة عبر wsl --install أولاً |
| السرعة | ✅ السرعة الأصلية القصوى | معالجة ملفات I/O أبطأ قليلاً، وتكون أبطأ عند الانتقال بين الأقراص |
| آلية الـ sandbox | حصرية لنظام Windows (elevated/unelevated) | تعتمد على أداة bubblewrap الخاصة بنظام Linux |
| الأدوات المتوافقة | ✅ أدوات Windows الأصلية وملفات .exe | ✅ أدوات Linux الأصلية وسكريبتات bash |
| الفئة المناسبة | أغلب مستخدمي Windows | من يتركز عمل مشاريعهم في بيئة Linux |
متى تختار PowerShell الأصلي؟ أنت مستخدم Windows عادي، وتستخدم VS Code لكتابة الكود و Git لنظام Windows — اختر التشغيل الأصلي مباشرة وتجنب تعقيدات تثبيت WSL دون داعٍ.
متى تختار WSL2؟ في ثلاث حالات: حاجتك لأدوات Linux الأصلية؛ وجود مستودعاتك وسير عملك داخل WSL2 بالفعل؛ أو تعذر تشغيل وضعي الـ sandbox الأصليين على جهازك.
لتشغيل WSL2، قم بتثبيته أولاً في «PowerShell كمسؤول»:
wsl --install
wslبعد الدخول إلى WSL shell، يجب تثبيت Codex مرة أخرى داخل بيئة Linux (النسخة المثبتة على Windows منفصلة):
curl -fsSL https://chatgpt.com/codex/install.sh | sh
codexوهنا مشكلة واجهتها في أبريل 2026: قمت بحفظ المستودعات في المسار /mnt/c/Users/... (وهو القرص C لنظام Windows المتاح داخل WSL)، وتسبب ذلك في بطء شديد لعمل Codex، حيث كانت عملية git status البسيطة تستغرق عدة ثوانٍ. واكتشفت لاحقًا أن عمليات قراءة وكتابة الملفات (I/O) في WSL على الأقراص المشتركة لنظام Windows تكون بطيئة للغاية، ويجب نقل مستودعات الكود إلى مجلد المستخدم الرئيسي داخل Linux:
mkdir -p ~/code && cd ~/code
git clone https://github.com/your/repo.git
cd repoوبعد النقل عادت السرعة لطبيعتها فورًا. وإذا كنت بحاجة للوصول إلى هذه الملفات من جهة Windows، يمكنك كتابة المسار \\wsl$\Ubuntu\home\<user> في مستكشف الملفات (مع استبدال <user> باسم مستخدم Linux الخاص بك). ونشير أيضًا إلى أن بيئة WSL1 لم تعد مدعومة ابتداءً من إصدار Codex 0.115 (حيث تم تغيير الـ sandbox إلى bubblewrap)، ويكون الخيار الافتراضي عند التثبيت هو WSL2 تلقائيًا فلا داعي للقلق بشأن ذلك.
💡 الخلاصة في جملة واحدة: إذا كان كودك على Windows استخدم PowerShell الأصلي، وإذا كان كودك على Linux استخدم WSL2 واحفظ المستودعات في دليل المستخدم الرئيسي
~/وليس في/mnt/c.
04 المشاكل الثلاث الحصرية لنظام Windows: المسارات، السطور الجديدة، والصلاحيات
يمثل هذا القسم الجزء الجوهري من المقالة، حيث يركز على المشاكل التي لا يواجهها مستخدمو Mac/Linux وتوجد بكثرة في Windows.
المشكلة الأولى: المسارات المائلة العكسية
تستخدم مسارات Windows الخط المائل العكسي C:\Users\You\project بينما تستخدم أنظمة Unix الخط المائل /home/you/project. يتعامل Codex مع هذا الاختلاف تلقائيًا في معظم الحالات، ولكن يجب عليك الانتباه في موضعين:
- عند كتابة المسارات في ملف
~/.codex/config.toml، يفضل كتابتها كمسارات مطلقة واضحة مثلC:\absolute\directory\path. - عند إضافة مجلد مسموح بالقراءة منه للـ sandbox في Codex، يجب أن يكون المسار مجلدًا مطلقًا موجودًا بالفعل. وتكتب الأمر التالي داخل واجهة Codex التفاعلية:
/sandbox-add-read-dir C:\absolute\directory\pathوبعد كتابته بنجاح، ستتمكن الأوامر الجارية داخل الـ sandbox في الجلسة الحالية من القراءة من هذا المجلد. تذكر أن هذا التغيير فعال للجلسة الحالية فقط، ويجب إعادته عند بدء جلسة جديدة.
المشكلة الثانية: نهاية السطر CRLF (المشكلة التي وقعت فيها في البداية)
نوضح أولاً: هذه مشكلة عامة متعلقة بكيفية معالجة Git للسطر الجديد على نظام Windows، وليست مشكلة خاصة بـ Codex، ولكن نظرًا لقيام Codex بتعديل الملفات، فستواجهها بكثرة معه.
تشبيه: اختلاف مقابس الكهرباء. يمثل رمز LF (نهاية السطر في Unix) و CRLF (نهاية السطر في Windows) اختلافًا في الصيغة يشبه اختلاف المقابس، وكلاهما يعني «سطرًا جديدًا» ولكن الأخير يحتوي على رمز \r إضافي. إذا قمت بنسخ مشروع من زملاء يستخدمون Mac/Linux وكان مكتوبًا بصيغة LF، فقد يقوم Git على Windows بتحويله تلقائيًا إلى CRLF عند التنزيل، وعند قيام Codex بتعديل الملف وحفظه، ستظهر اختلافات في كل الأسطر بسبب تغير الرموز، مما يسبب فوضى في الـ diff.
كانت هذه مشكلتي السابقة. ويتمثل الحل في توحيد قواعد السطر الجديد، وأسهل طريقة هي إضافة ملف باسم .gitattributes في جذر المشروع لمنع Git من تغيير الصيغ تلقائيًا:
* text=auto eol=lfأو إغلاق التغيير التلقائي لـ Git على مستوى النظام بالكامل (شغل الأمر في PowerShell):
git config --global core.autocrlf falseاعتمد على ما يتفق عليه فريق العمل لديك، والفكرة الأساسية هي منع تغير رموز السطر الجديد تلقائيًا بين أنظمة التشغيل، وإلا ستضيع تعديلاتك وتعديلات Codex في اختلافات الرموز غير المفيدة.
المشكلة الثالثة: تنبيهات صلاحيات الكتابة لـ Everyone
عند التشغيل الأصلي، قد يظهر تنبيه من Codex يفيد بأن «بعض المجلدات تسمح بالكتابة لـ Everyone». هذا ليس خطأ في البرنامج — بل هو تنبيه أمني يوضح: صلاحيات هذه المجلدات في Windows واسعة للغاية، ولا يمكن للـ sandbox حمايتها. ويتمثل الحل في إلغاء صلاحية الكتابة لـ Everyone من خصائص المجلد، ثم إعادة تشغيل Codex أو إعادة تهيئة الـ sandbox. وإذا كنت غير متأكد من كيفية تعديل الصلاحيات، فاستشر قسم تقنية المعلومات وتجنب التعديل العشوائي.
| المشكلة | الأعراض | كيفية معالجتها |
|---|---|---|
| المسارات المائلة العكسية | عدم تفعيل إعدادات المسارات أو فشل قراءة المجلدات | كتابة مسارات مطلقة، واستخدام مجلد مطلق موجود فعليًا مع أمر /sandbox-add-read-dir |
سطر CRLF الجديد | ظهور اختلافات (diff) في كل الأسطر مع رموز ^M | استخدام ملف .gitattributes وتحديد eol=lf أو إغلاق خيار core.autocrlf |
صلاحيات Everyone | ظهور تنبيه يفيد بأن صلاحيات المجلد واسعة | إلغاء صلاحية الكتابة لـ Everyone وإعادة تشغيل Codex |
💡 الخلاصة في جملة واحدة: اكتب مسارات مطلقة، واستخدم ملف
.gitattributesلتوحيد السطور الجديدة، ولا تتجاهل تنبيهات الصلاحيات — وستكون تجربة Windows متطابقة تمامًا مع Mac.
05 الـ sandbox والصلاحيات: ما الفرق بين Windows و Mac/Linux
تختلف آلية عمل الـ sandbox (البيئة الأمنية التي تمنع كتابة الملفات العشوائية أو الوصول غير المصرح به للشبكة) في Codex حسب نظام التشغيل. حيث يعتمد Mac على أداة sandbox-exec المدمجة، ويعتمد Linux على bubblewrap، بينما يعتمد Windows على آليتين حصرتين خاصتين به.
في نظام Windows الأصلي، يمنع الـ sandbox في وضع agent كتابة الملفات خارج مجلد العمل الحالي، ويمنع الوصول للشبكة دون موافقتك. ويمكنك ضبط هذه الإعدادات في ملف ~/.codex/config.toml (اكتبها في ملف التكوين):
[windows]
sandbox = "elevated" # أو "unelevated"نوضح الفروق بين الوضعيين بالتفصيل:
| الوضع | القوة | كيفية التطبيق | متى تستخدمه |
|---|---|---|---|
elevated (المفضل) | أقوى | إنشاء مستخدم مخصص للـ sandbox بصلاحيات محدودة + صلاحيات نظام الملفات + قواعد جدار الحماية + تعديل السياسات المحلية | الخيار الافتراضي المفضل، ويوفر أفضل أداء وأعلى مستوى أمان |
unelevated (التراجعي) | أضعف | توليد رمز مميز (token) محدود من المستخدم الحالي + صلاحيات نظام الملفات (ACL) + تعطيل الشبكة على مستوى البيئة | يستخدم كخيار بديل عند تعذر تثبيت وضع elevated |
ملاحظة: هذا التوجيه يعاكس تمامًا ما تذكره بعض الشروحات القديمة حول «تفضيل وضع unelevated». حيث تؤكد المستندات الرسمية أن وضع elevated هو الخيار الأساسي المفضل، ويمثل وضع unelevated بديلاً تراجعيًا عند تعذر التثبيت بسبب صلاحيات الجهاز. ويقوم كلا الوضعيين افتراضيًا بتفعيل خيار «سطح المكتب الخاص (private desktop)» لعزل واجهة المستخدم، ولا ننصح بإغلاق خيار windows.sandbox_private_desktop إلا إذا كنت بحاجة للتوافق مع سلوك جلسة Windows Station القديم Winsta0\Default.
لماذا قد يفشل تثبيت وضع elevated؟ يتطلب هذا الوضع إنشاء مستخدم جديد وتعديل قواعد جدار الحماية وتعديل السياسات المحلية، وغالبًا ما تمنع سياسات أجهزة الشركات هذه العمليات. ويتمثل العرض الأشهر لهذه المشكلة في ظهور خطأ برقم 1385 — ويعني رفض نظام Windows إعطاء مستخدم الـ sandbox صلاحية تسجيل الدخول لتشغيل الأوامر. وإذا واجهت خطأ 1385 فقم بالتالي وفقًا للتوجيهات الرسمية:
- تواصل مع قسم تقنية المعلومات للتأكد من إمكانية إعطاء مستخدم الـ sandbox الذي ينشئه Codex صلاحيات تسجيل الدخول المطلوبة.
- إذا كانت المشكلة تظهر في بعض الأجهزة دون غيرها، فراجع اختلافات سياسات المجموعة (group policy) أو وحدات التنظيم (OU).
- للبدء في العمل فورًا، يمكنك التبديل مؤقتًا لوضع
unelevated. - شارك ملف السجل
CODEX_HOME/.sandbox/sandbox.logمع توضيح إصدار نظام Windows مع فريق الدعم لحل المشكلة.
🔒 محذور أمني: تجنب مشاركة محتويات المجلد
CODEX_HOME/.sandbox-secrets/مطلقًا لأنها تحتوي على مفاتيح سرية، وشارك فقط ملفsandbox.logعند طلب المساعدة.
وإذا فشل أمر ما بسبب «عدم قدرة الـ sandbox على قراءة مجلد معين»، استخدم أمر /sandbox-add-read-dir الموضح في القسم 04 لإضافة المجلد للمسارات المسموحة.
💡 الخلاصة في جملة واحدة: يتكون نظام الـ sandbox على Windows من آليتين مستقلتين، ويفضل وضع
elevatedافتراضيًا والتراجع لوضعunelevatedعند الحاجة، ويشير خطأ1385عادة لوجود سياسات أمنية تمنع صلاحيات تسجيل الدخول.
06 الجزء العملي: تشغيل أول مهمة Codex على Windows
بعد استعراض الجانب النظري، دعنا نطبق العملي. سنقوم بتشغيل الخطوات التالية بالكامل داخل PowerShell الأصلي، بدءًا من إنشاء المشروع ووصولاً لتعديل الملفات والتحقق.
الخطوة الأولى: إنشاء مشروع اختبار مصغر (في PowerShell):
mkdir codex-win-test
cd codex-win-test
git init
"console.log('hi')" | Out-File -Encoding utf8 app.jsتنبيه بسيط: كتابة الملفات عبر أمر
Out-File -Encoding utf8في إصدارات PowerShell القديمة (5.1) قد يضيف علامة BOM في بداية الملف، مما يسبب بعض الاختلافات الإضافية في ترميزgit diff. وإذا كنت تستخدم PowerShell 7+ فيفضل استخدامSet-Content -Encoding utf8NoBOMللحصول على ملفات نظيفة بدون علامات BOM لتسهيل فحص السطور الجديدة.
الخطوة الثانية: ضبط قواعد نهاية السطر. لمنع المشكلة المذكورة في القسم 04، أنشئ ملفًا باسم .gitattributes في جذر المشروع واكتب فيه:
* text=auto eol=lfالخطوة الثالثة: تشغيل Codex:
codexعند التشغيل الأول للـ sandbox الأصلي، قد تظهر نافذة طلب موافقة المسؤول (UAC) الخاصة بنظام Windows لتنفيذ تهيئة وضع elevated. انقر على «موافق» على جهازك الشخصي؛ وإذا كنت تستخدم جهاز عمل مغلق الصلاحيات، فسيتراجع Codex تلقائيًا لوضع unelevated مع إظهار تنبيه يفيد بتغيير الوضع — وهو سلوك تراجعي طبيعي لمواصلة العمل.
الخطوة الرابعة: تكليف Codex بمهمة بسيطة. اكتب الطلب التالي داخل الواجهة التفاعلية:
把 app.js 里的 'hi' 改成 'hello, codex on windows'(Note: we keep the Chinese string in the command description exactly as in the source code block, because the rules say: "DO NOT translate: Code blocks, inline code").
النتيجة المتوقعة: سيقوم Codex بقراءة ملف app.js وعرض الفروقات (diff) وطلب موافقتك (في وضع الصلاحيات الافتراضي)، وبمجرد موافقتك سيقوم بحفظ الملف. ويمكنك التحقق من محتوى الملف الآن:
Get-Content app.jsوستظهر المخرجات التالية:
console.log('hello, codex on windows')الخطوة الخامسة: التأكد من سلامة السطور الجديدة. وهي العادة الأهم التي يجب الالتزام بها عند العمل على Windows:
git diffإذا قمت بضبط ملف .gitattributes بشكل صحيح في الخطوات السابقة، فستظهر الفروقات في السطر المعدل فقط، دون ظهور رموز ^M في كل الأسطر ودون ظهور كامل الملف كمعدل. وإذا حدثت مشكلة في التنسيق، فراجع خطوات معالجة نهاية السطر في القسم 04.
قمت بتطبيق هذه الخطوات للتحقق من التنسيق وخاصة خطوة مراجعة git diff للسطور الجديدة عند إعداد Codex على أي جهاز Windows جديد — وهي عادة اكتسبتها بعد فترات طويلة من تتبع المشاكل البرمجية.
💡 الخلاصة في جملة واحدة: إنشاء المشروع ← إعداد
.gitattributes← تشغيل Codex ← كتابة المهمة البسيطة ← التحقق عبرgit diff. خمس خطوات للبدء والعمل بشكل صحيح على Windows.
ملخص
نراجع النقاط الأساسية التي تناولتها هذه المقالة:
- طريقة التشغيل المفضلة: استخدام Windows الأصلي + وضع sandbox الـ
elevatedكخيار أساسي مفضل رسميًا للأداء والأمان الكامل؛ والاعتماد على WSL2 لمن يتركز عملهم داخل Linux افتراضيًا. - التثبيت: تشغيل سكريبت PowerShell المدمج لتثبيت CLI، والتحقق من إصدار Windows وصلاحيات المسؤول وتوفر
winget؛ وتثبيت أدوات بناء C++ عند استخدام إضافات الـ IDE. - المشاكل الثلاث الحصرية: كتابة مسارات مطلقة للمجلدات، وتوحيد السطور الجديدة بصيغة
LFعبر ملف.gitattributesلمنع مشاكل CRLF، والانتباه لتنبيهات صلاحيات مجلداتEveryone. - اختلافات الـ sandbox: يتكون الـ sandbox على Windows من آليتي
elevatedوunelevatedمستقلتين تختلفان عن آليات أنظمة Mac/Linux؛ ويشير خطأ1385لوجود قيود على صلاحيات المسؤول.
أصبحت الآن قادرًا على تثبيت Codex بنجاح على نظام Windows، وتحديد خيار التشغيل الأصلي أو عبر WSL، وتجنب مشاكل المسارات والسطور الجديدة، وتشغيل أول مهمة تعديل كود مع التحقق من سلامة التنسيق.
وباختصار — لا يختلف تشغيل Codex على Windows عن تشغيله على Mac في السهولة، وكل ما تحتاجه هو استيعاب طبيعة عمل «السطر الجديد» و«الـ sandbox» الحصريين لنظام Windows وتجنب الوقوع فيهما مستقبلاً.
المقالة التالية 〔34 المشروع الختامي العملي〕 تمثل مسك الختام لسلسلة Codex — حيث سنتوقف عن شرح الميزات المنفصلة، ونقوم بدمج كل ما تعلمناه في المقالات السابقة (التكوين، اختيار النماذج، الصلاحيات، الوكلاء الفرعيين، الأتمتة، الهجرة، وتجهيز بيئة Windows...) لتشغيل مشروع حقيقي متكامل من الصفر.
فكر في هذا السؤال البسيط: إذا قمت بنسخ مشروع جديد عبر git clone وأردت من Codex مساعدتك في تشغيل أولى الميزات، فما هي الإعدادات الثلاثة الأولى والقواعد الأساسية التي ستبدأ بضبطها؟ سنوضح ذلك في المقالة القادمة.