[مراجعة كاملة] تتبّع عطل Codex Desktop أوقعني فيه pwsh.cmd: من تضليل WSL إلى السبب الحقيقي على Windows Native (batch file arguments are invalid)

AIDO تصحيح الأخطاء
, , , , ,
1

كانت هذه الجولة من استكشاف الأخطاء وإصلاحها تستحق جدًا أن تُوثَّق كمقال كامل، لأنها تقريبًا داسَت على أكثر فئات “الحُفر” شيوعًا التي قد تقع فيها أدوات الـ AI المكتبية على Windows: API مخصّص، WSL، Windows native، PowerShell، PATH، shim، ثنائيات مدمجة في نسخة المتجر، وكذلك حالة “يبدو أنه ظهر فجأة، لكنه في الحقيقة عيب قديم أُعيد تفعيله”.

في النهاية دعني أبدأ بالخلاصة:

السبب الحقيقي الذي جعل Codex Desktop على Windows native غير قادر تمامًا على تشغيل أي أمر ليس WSL، ولا PowerShell profile، ولا عدم تطابق الإصدارات بين نسخة سطح المكتب ونسخة npm؛ بل هو shim دفين داخل C:\\Users\\1\\AppData\\Local\\Programs\\Python\\Python313\\Scripts\\pwsh.cmd. مُنفِّذ الأوامر في Codex على Windows عند تشغيل هذا الغلاف .cmd مع معاملات، يفشل مباشرة بالخطأ: batch file arguments are invalid، فتموت كل الأوامر قبل أن تُنفَّذ فعليًا.

1. نقطة انطلاق الحادثة: يبدو وكأنه “تعطّل بعد التحويل إلى WSL”

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

  1. بعد تحويل كلٍّ من Agent و Integrated terminal داخل إعدادات Codex إلى WSL، بدأ تطبيق سطح المكتب يعيد الاتصال باستمرار ويعطي خطأ:
Reconnecting... 1/5
...
stream disconnected before completion: error sending request for url (https://wuju.de5.net/v1/responses)
  1. لكن المستخدم قال بوضوح: لا تصلح WSL الآن، بل أصلح مشكلة Windows native الأصلية أولًا، لأن سبب التحويل إلى WSL أساسًا هو أن الـ native كان فيه مشكلة.

هذه الخطوة مهمة جدًا لأنها تفصل مشكلتين:

  • مسار WSL يشبه أكثر مشكلة شبكة/وكيل/وصول بيئة WSL إلى واجهة مخصّصة.
  • مسار Windows native هو أن مُنفّذ الأوامر المحلي نفسه كان مكسورًا أصلًا.

إن لم نفصل بينهما أولًا فسنظل نتنقّل في سوء تقدير بين عطلين مستقلين.

2. أول إعادة إنتاج بالحد الأدنى: ليست مشكلة أمر بعينه، بل “كل الأوامر تموت قبل التنفيذ”

للتأكد هل المشكلة في Git أو PowerShell أو Codex نفسه، أجرينا اختبار أوامر بالحد الأدنى:

  • Write-Output hi
  • Get-Location
  • git status -sb
  • cmd.exe /c echo hi

النتيجة كانت متناسقة جدًا: جميعها تُرجع الخطأ نفسه:

execution error: Io(Error { kind: InvalidInput, message: "batch file arguments are invalid" })

قيمة هذه النقطة كبيرة جدًا لأنها تُثبت مباشرة:

  • ليست مشكلة خاصة بـ Git.
  • ليست مشكلة دليل عمل معيّن.
  • ليست لأن سكربتًا داخل PowerShell profile أفسد أمرًا بعينه.
  • وحتى مسار cmd.exe /c الذي “يتجاوز PowerShell” لم ينجُ.

أي إن نقطة العطل في “طبقة إطلاق الأوامر” وليس في الأوامر نفسها.

3. نقطة تضليل ثانية: الطرفية المدمجة تعمل طبيعيًا، فلماذا يقول Codex إنه لا يستطيع؟

في ذلك الوقت كانت لقطة الطرفية المدمجة في الخيط تعمل طبيعيًا، يظهر الـ prompt ويمكن رؤية:

PowerShell 7.5.4
PS C:\\Users\\1\\0.0.90_0\u003e

وهذا يسهل أن يضلل الناس للاعتقاد:

  • طالما الطرفية تفتح، فـ PowerShell نفسه لا مشكلة فيه.
  • إذن المتبقي غالبًا bug في runner المدمج داخل Codex.

هذا الاستنتاج صحيح نصفه فقط.

PowerShell نفسه لم يكن معطّلًا فعلاً، لكن “ظهور الطرفية” داخل Codex Desktop لا يعني “أن مُنفِّذ أوامر الـ agent يستطيع تشغيل shell بنجاح وتمرير معاملات وتشغيل أمر”. هذان مساران مختلفان.

وهذه أول فائدة كبيرة من جلسة الاستكشاف هذه:

كون الطرفية التفاعلية المدمجة تعمل، لا يثبت أن مسار shell_command الخاص بالـ agent يعمل.

4. سوء تقدير ثالث: الاشتباه مؤقتًا بأن نسخة المتجر تدمج backend قديمًا

بعد ذلك اكتشفنا شيئًا مريبًا جدًا:

  • نسخة سطح المكتب من متجر Microsoft تحتوي موارد bundled فيها إصدار CLI/runner هو 0.112.0-alpha.3
  • بينما النسخة المثبتة عالميًا عبر npm لـ @openai/codex هي بالفعل 0.113.0

يبدو هذا جدًا كجذر المشكلة، لأن “غلاف سطح المكتب جديد، والـ runtime المدمج قديم” قد يسبب فعلًا سلوكيات غريبة.

لذلك قمنا بتحقق “قاسٍ” لكنه عالي القيمة:

  • نسخنا من نسخة المتجر نسخة قابلة للكتابة من برنامج سطح المكتب.
  • استبدلنا داخلها ثنائيات 0.113.0 المثبتة عبر npm مكان codex.exe وcodex-command-runner.exe وغيرها.
  • شغلنا نسخة سطح المكتب patched ثم أعدنا إنتاج المشكلة في خيط جديد.

لو كان السبب عدم تطابق الإصدارات فعلاً، لكان من المفترض أن تتعافى النسخة patched.

النتيجة: لم تتعافَ إطلاقًا.

أبسط git status -sb في الخيط الجديد ما زال يعطي نفس الخطأ:

batch file arguments are invalid

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

أصبح الاستنتاج:

  • عدم التطابق بين 0.112.0-alpha.3 و0.113.0 قد يكون مجرد ضجيج، أو مشكلة أخرى جديرة بالمتابعة.
  • لكنه ليس جذر انهيار native shell في هذه الحالة.

وهذه ثاني فائدة كبيرة:

هناك كثير من “النقاط المشبوهة” التي تفسّر الظاهرة، لكن طالما تجربة patch لا تزيل الظاهرة فهي ليست جذر المشكلة.

5. متابعة الاستبعاد: PowerShell profile مزعج، لكنه ليس نقطة القتل هنا

في منتصف الطريق ظهرت أيضًا أخطاء PowerShell profile، مثل قراءة .wt_proxy_config.json كـ null ثم انفجار منطق مثل Add-Member/$cfg.enabled داخل الـ profile.

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

لكن يوجد هنا حكم مهم:

لو كان جذر المشكلة هو الـ profile، لكانت بعض مسارات الأوامر تستطيع الالتفاف حوله على الأقل، أو لكان شكل الخطأ أقرب لاستثناءات سكربت PowerShell، لا أن تفشل كل الأوامر بشكل موحّد على طبقة الإقلاع برسالة batch file arguments are invalid.

لاحقًا أثبتت الوقائع أن الـ profile ليس السبب الرئيسي لتعطّل native executor بالكامل.

6. الاختراق الحقيقي: اكتشاف pwsh.cmd غريب جدًا

الذي “سمّر” المشكلة في النهاية هو العثور على هذا الملف على الجهاز:

C:\\Users\\1\\AppData\\Local\\Programs\\Python\\Python313\\Scripts\\pwsh.cmd

ومحتواه سطران فقط:

@echo off
"C:\\Program Files\\PowerShell\\7\\pwsh.exe" %*

هذا يبدو كـ “shim لطيف” هدفه تغليف pwsh وتمريره إلى PowerShell 7 الحقيقي.

لكنه بالنسبة لمُنفّذ Codex Desktop على Windows هو سمّ:

  • ليس pwsh.exe بل غلاف batch من نوع .cmd.
  • مُنفّذ الأوامر في Codex على أحد المسارات عندما يستدعيه مع معاملات، يُطلق مباشرة:
batch file arguments are invalid

بعبارة أخرى: قبل أن تصل الأوامر إلى pwsh.exe تكون قد ماتت عند طبقة .cmd.

وهذا يفسّر تمامًا لماذا:

  • Write-Output hi يموت
  • Get-Location يموت
  • git status -sb يموت
  • cmd.exe /c echo hi يموت أيضًا

لأن الذي يتعطل هو bootstrap الخارجي للـ shell، لا الأمر المستهدف.

7. سلسلة الأدلة الحاسمة: هذه الحفرة لم تُنشأ اليوم

الجزء الأكثر إثارة للاهتمام والأكثر عكسًا للحدس هنا.

إحساس المستخدم كان: “يبدو أنه ظهر فجأة منذ حوالي ثلاث ساعات، قبل ذلك لم تكن هناك مشكلة.”

لكن السجلات تشير إلى أن تاريخ هذه الحفرة أقدم من “ظهورها اليوم”:

الدليل 1: shim pwsh.cmd كُتب في 2026-02-02 18:52:53 (بالتوقيت المحلي)

في codex-tui.log يمكن رؤية فعل كتابة واضح حينها، كُتب pwsh.cmd مباشرة داخل مجلد Scripts الخاص بـ Python.

الدليل 2: نفس نوع الخطأ ظهر لأول مرة في 2026-02-03 15:02:40 (بالتوقيت المحلي)

من 3 فبراير ظهرت بالفعل بكثرة رسائل:

exec error: batch file arguments are invalid

وحتى توجد سجلات تحاول استدعاء هذا الـ shim صراحة.

الدليل 3: العطل الحالي انكشف مجددًا حوالي 2026-03-11 04:11، وتجربة إعادة الإنتاج عند 04:33 أصابته بثبات

أي إن اليوم ليس “اليوم الذي أُنشئ فيه هذا الإعداد السيئ”، بل “اليوم الذي أُعيد فيه تفعيل خطر قديم، وصادف أنه أصاب مسار الاستخدام الحالي”.

8. لماذا شعر المستخدم أنه “تعطّل فجأة منذ ثلاث ساعات”؟

هذه أهم نقطة تستحق توضيحًا.

الوصف الأدق هو:

ليس أن الإعداد السيئ تكوّن قبل ثلاث ساعات، بل أن Codex Desktop قبل ثلاث ساعات تقريبًا عاد ليسلك مسار تنفيذ يصطدم بـ pwsh.cmd.

وفق الأدلة المتاحة، التفسير الأكثر معقولية هو هذا المزيج، لا “أن البرنامج تحدّث سرًا للتو”:

  1. لغم pwsh.cmd مدفون منذ مدة.
  2. في أوائل فبراير تسبب بالفعل بأخطاء من نفس النوع، لكنه لا ينكشف بالطريقة نفسها في كل استخدام.
  3. هذه المرة المستخدم أثناء الاستكشاف عاد إلى مسارات Windows native + PowerShell.
  4. وفي نفس الوقت أعاد تطبيق سطح المكتب/عملية الخلفية التقاط بيئة ثابتة مرة أخرى، وأعاد تحليل pwsh حسب PATH.
  5. هذه المرة التحليل أصاب shim من نوع .cmd، فانفجرت المشكلة بشكل شامل.

بعبارة أخرى، هذا النوع من الأعطال لا يحتاج لتحديث برمجي كي “يظهر فجأة”.

يكفي أن يحدث أي مما يلي ليعيد تفعيل الخطر القديم:

  • إعادة تشغيل تطبيق سطح المكتب
  • إعادة تشغيل عملية agent في الخلفية
  • التحويل من WSL إلى Windows native
  • تغيير إعدادات يعيد تهيئة الـ shell
  • أن خيطًا جديدًا لا يعيد استخدام بيئة قديمة بل يقرأ PATH الثابت مجددًا

وهنا يجب أن أكون صريحًا:

أستطيع تأكيد بنية “خطر قديم + مُحفّز جديد”، لكن لا أستطيع من السجلات الحالية وحدها إثبات 100% أي لحظة/إجراء بالضبط كان المُحفّز.

لكن يمكن التأكد جدًا: ليس “إعداد سيئ جديد غامض تَولّد اليوم فجأة”.

9. إجراءات الإصلاح النهائية

الإجراء الذي أعاد Windows native للعمل بسيط، لكنه يجب أن يكون دقيقًا:

الإجراء 1: نقل ذلك الـ shim

قمنا بإعادة تسمية:

C:\\Users\\1\\AppData\\Local\\Programs\\Python\\Python313\\Scripts\\pwsh.cmd

إلى:

C:\\Users\\1\\AppData\\Local\\Programs\\Python\\Python313\\Scripts\\pwsh.cmd.disabled-by-codex

الإجراء 2: تقديم PowerShell 7 إلى مقدمة PATH الخاص بالمستخدم

وضعنا صراحة:

C:\\Program Files\\PowerShell\\7\\

في مقدمة Path للمستخدم، لتجنب أن يصطدم التحليل لاحقًا بـ shim آخر أولًا.

الإجراء 3: بث تغييرات متغيرات البيئة

لم نكتف بتعديل السجل، بل أرسلنا أيضًا WM_SETTINGCHANGE / Environment كي تحصل العمليات الجديدة على البيئة المحدّثة بأسرع ما يمكن.

الإجراء 4: سكربت الإقلاع patched يقوم أيضًا بعمل prepend لـ PowerShell 7

بحيث حتى لو تغيّر PATH لاحقًا في مكان آخر، يبقى هذا المسار أقل عرضة للتلوث.

بعد الإصلاح أكد المستخدم: عاد كل شيء للعمل أخيرًا.

10. ما المنعطفات الخاطئة التي سلكناها؟ ولماذا كانت مفيدة رغم ذلك؟

يبدو أننا التففنا كثيرًا، لكن كل “التفاف” كان يضيّق مساحة البحث:

التفاف 1: الانحراف أولًا بسبب خطأ شبكة WSL

المعنى: التأكد أن مشكلة WSL ومشكلة native ليستا عطلًا واحدًا.

التفاف 2: الاشتباه في PowerShell profile

المعنى: فصل “ضجيج تهيئة الطرفية” عن “العطل القاتل في مُنفّذ الأوامر”.

التفاف 3: الاشتباه في أن bundled backend في نسخة سطح المكتب متأخر

المعنى: عبر تجربة patched app تم استبعاد “مشكلة إصدار فقط” مباشرة.

التفاف 4: تجربة مداخل أوامر مختلفة

مثل تشغيل:

  • Write-Output hi
  • cmd.exe /c echo hi
  • powershell -NoProfile -Command ...
  • & git.exe status -sb

المعنى: إثبات أن كل الطرق تفشل في نفس الطبقة المسبقة، وليس bug خاص بـ shell معيّن.

لذلك هذه “المنعطفات” لم تذهب سدى، بل كانت تُقلّص المشكلة خطوة خطوة من “قد تكون أي شيء” إلى “لا بد أنها مشكلة منخفضة جدًا في Windows shell bootstrap / PATH / shim”.

11. أكثر الدروس العملية فائدة

الدرس 1: في أدوات الـ AI المكتبية، “ظهور الطرفية طبيعيًا” لا يعني أن مُنفّذ الـ agent يعمل

طرفية UI ومسار تنفيذ الأوامر في الخلفية شيئان مختلفان.

الدرس 2: اختبارات الأوامر الأقصر ثمينة جدًا

اختبارات مثل Write-Output hi وGet-Location وcmd.exe /c echo hi أكثر فاعلية بكثير من البدء بأوامر معقدة.

الدرس 3: اختلاف الإصدارات لا يساوي جذر المشكلة

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

الدرس 4: الـ shim على Windows خبيث جدًا

خصوصًا أشياء مثل .cmd و.bat ومجلد Python Scripts وWindowsApps proxy stub ومشغّلات مخصصة؛ تبدو طبيعيًا في العادة، لكن حالما يستخدم برنامج ما طريقة تحليل ليست كما تتخيل، تنفجر بشكل غير معقول.

الدرس 5: إحساس المستخدم “تعطّل اليوم فجأة” لا يعني بالضرورة “جذر المشكلة ظهر اليوم”

البنية الحقيقية لكثير من مشاكل مستوى النظام هي:

  • خطر موجود منذ وقت طويل
  • لم يُصَب لفترة طويلة
  • ثم مع إعادة تشغيل عملية/تبديل نمط/إعادة قراءة بيئة، ينفجر فجأة على نطاق واسع

الدرس 6: خط الزمن في السجلات مهم جدًا

إن نظرت للحاضر فقط، ستُخطئ بسهولة بين “تم تفعيله اليوم” و“تم إنشاؤه اليوم”.

12. الخلاصة الجوهرية في جملة واحدة

ليست هذه حالة “Codex تعطّل” ببساطة، بل هي حالة نموذجية من تلوث طبقة بيئة Windows: shim باسم pwsh.cmd كان مدفونًا منذ زمن، أُعيدت إصابته عند سلوك مسار Windows native shell مرة أخرى، ففجّر مُنفّذ أوامر Codex Desktop بالكامل.

إذا واجهت لاحقًا شيئًا مشابهًا مثل:

  • كل الأوامر تفشل بشكل موحّد
  • الخطأ قصير وغير متعلق بمحتوى الأمر
  • الطرفية المدمجة تفتح لكن الـ agent لا يستطيع التشغيل
  • مداخل الأوامر المختلفة كلها تعطي نفس الخطأ

فلا تُحدّق في Git أو المستودع أو الـ profile أو حتى إصدار التطبيق نفسه؛ بل ابدأ بالتحقق من:

  • where.exe pwsh
  • ترتيب PATH
  • هل يوجد shim باسم مطابق من نوع .cmd/.bat
  • هل يوجد غلاف مخفي داخل WindowsApps / Python Scripts / مجلدات launcher مخصصة

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

2

TL;DR: هذه المرة ليست WSL ولا المستودع المحلي ولا PowerShell profile ولا عدم تطابق إصدار تطبيق سطح المكتب هي التي عطّلت Codex؛ السبب الجذري الحقيقي هو أن pwsh في PATH كان يُطابِق أولاً مُغلِّفًا من نوع .cmd بدلًا من ملف pwsh.exe نفسه.

بالتحديد، على هذا الجهاز يوجد:

C:\Users\1\AppData\Local\Programs\Python\Python313\Scripts\pwsh.cmd

عندما يستدعي مُنفِّذ أوامر Windows في Codex هذا الـ shim مع معاملات، يظهر فورًا الخطأ:

batch file arguments are invalid

لذلك يبدو ظاهريًا أن “كل الأوامر تعطّلت”، لكن جوهر المشكلة هو أن bootstrap الخاص بالـ shell الخارجي انهار قبل أن يبدأ تنفيذ الأوامر فعليًا.

الإصلاح مباشر أيضًا:

  • انقل/أعد تسمية pwsh.cmd هذا
  • قدّم C:\Program Files\PowerShell\7\ إلى مقدمة PATH
  • أعد تشغيل Codex لتطبيق البيئة الجديدة

نقطة خبرة مهمة أيضًا: شعور المستخدم بأنها “تعطّلت فجأة اليوم” لا يعني أن السبب الجذري ظهر اليوم فقط. تُظهر السجلات أن هذا الـ shim وأخطاء مشابهة كانت موجودة منذ وقت أبكر؛ ما حدث هذه المرة هو مجرد إعادة مطابقته بعد إعادة تشغيل/تبديل مسار.