إضافات الذكاء الاصطناعي، 8 نوفمبر: متى يمكن مشاركة اتصال MCP بين المشاريع؟
يضيف OpenCode 2.2.6 مشاركة MCP اختيارية. تطابق الحساب والبروتوكول وغياب roots والانتظار غير المحدود تحدد حدودها.

فتح خادم MCP نفسه في مشاريع متعددة قد يبقي عدة اتصالات عاملة. يضيف OpenCode 2.2.6 مشاركة اختيارية، لكن الاسم المتطابق وحده لا يكفي. وتوضح الوثائق أن الاتصال المشترك ليس له roots، أي جذور أدلة المشاريع.
مراجعة مصادر اليوم
نشر OpenCode v2.2.6 في 6 نوفمبر. يعلن الإصدار تقليل العمليات وتسريع البدء عبر مشاركة اتصالات MCP، ويضيف خيارات للتشغيل بالبرامج النصية. تسمح رخصة MIT بإعادة الاستخدام وفق شروطها. حداثة الإصدار إشارة إلى الصيانة، وليست دليلا على الأمان أو الملاءمة. لم أثبت هذا الإصدار أو أقس زمن البدء أو أختبر معه خادم MCP.
يبدأ الإعداد بتثبيت OpenCode موجود وتهيئة MCP، ثم مصادقة الخادم نفسه عند الحاجة. وفق وثائق MCP، تكون pool معطلة افتراضيا.
ما الذي يمكن مشاركته فعليا؟
تحصر الوثائق المشاركة في أدلة ضمن خادم OpenCode واحد، وفي اتصالات تستخدم مراجعة البروتوكول 2026-07-28. عند تفعيل pool وترك protocol غير محدد، تستخدم auto. الخادم الذي يجيب بمراجعة أقدم، أو الاتصال المضبوط على legacy، يحتفظ باتصال منفصل لكل دليل.
يجب أن تتطابق في الاتصال البعيد عناوين URL والترويسات وإعدادات OAuth والحساب المسجل، إلى جانب البروتوكول والمهل الزمنية. لا يلزم عادة تطابق أسماء الخوادم، لكن تسجيل الدخول يحفظ بحسب الاسم؛ لذلك يجب تطابق الاسم أيضا لخادم OAuth. وفي الاتصال المحلي يجب كذلك تطابق الأمر وبيئة التشغيل ودليل العمل.
يمكن مشاركة خادم محلي بين أدلة على الجهاز نفسه، لا الأدلة داخل workspace. تحتاج المشاركة بين المشاريع إلى cwd ثابت. من دونه يعمل الخادم في مجلد كل مشروع ويصدر OpenCode تحذيرا. تغيير دليل العمل للحصول على المشاركة قد يوسع ما يراه خادم كان يفترض أن يرى مشروعا واحدا فقط.
الجذور والصلاحيات تحتاج مراجعة منفصلة
الاتصال المشترك ليس له roots. طلب الإدخال من أداة يظهر في الدليل الذي استدعاها. لا يعد أي من الأمرين بأن الخادم نفسه يفرض فصل الوصول بين المشاريع. أوصي بمراجعة وصوله للملفات ونطاق الحساب قبل المشاركة.
قد يحقق مشروعان يستخدمان حسابا واسع الصلاحيات شروط التطابق، مع اختلاف توقعات الأشخاص بشأن البيانات المسموح بها. المشاركة لا تمنح إذنا مفقودا. أوصي بفصل حسابات الاختبار والإنتاج، وإبقاء pool معطلة للخادم المعتمد على roots أو حالة متغيرة خاصة بالمشروع حتى يفحص سلوكه. هذه توصيات نشر، وليست ادعاء باكتشاف ثغرة في OpenCode.
JSON التالي سجل مراجعة غير قابل للتشغيل عمدا، وليس تهيئة صالحة لـ OpenCode. يحفظ القرارات بلا أسرار ولا يفرض عزلا.
- دليلان يطلبان خادما
- مقارنة الإعدادات والبروتوكول المتفاوض عليه
- مشاركة عند الأهلية فقط؛ الاتصال المشترك بلا roots
{
"server_role": "public-documentation-search",
"pool_requested": true,
"same_account_scope": "review-required",
"requires_project_roots": "review-required",
"fixed_local_cwd": "not-applicable-to-remote",
"protocol_seen": null,
"approved": false
}
لتجربة مأذون بها، استخدم خادما مؤقتا وبيانات اصطناعية. قارن تعطيل pool وتفعيلها في دليلين، ثم غير شرط تطابق واحدا. سجل البروتوكول المتفاوض عليه وعدد العمليات أو الاتصالات والدليل الذي يستقبل طلب الإدخال. اختبر خادما يحتاج roots. نجاح استدعاء الأداة لا يثبت العزل. هذه خطة مقترحة ولم تنفذ للمقالة.

التشغيل النصي قد ينتظر بلا نهاية
يقول الإصدار نفسه إن opencode run ينتظر أوامر shell والوكلاء الفرعيين ومهام الصور الخلفية التي بدأها طلبه، ثم يتيح للنموذج الرد على نتائجها قبل الخروج. لا يوجد حد زمني مدمج لهذا الانتظار. خادم تطوير أو مراقب ملفات قد يبقي التشغيل مفتوحا حتى المقاطعة. وتذكر الملاحظات أن SIGTERM يلغي الجلسة ومهامها الخلفية وينهي العملية بالرمز 143.
في CI سأحدد مهلة خارجية والناتج المتوقع قبل البدء. اكتمال الإجابة الأمامية لا يكفي إذا كان الملف المطلوب يعتمد على مهمة خلفية. أضيف run -w لإنشاء worktree جديد في git، ولا يجتمع مع --continue أو --session. يخفي --archived الجلسات النصية من القوائم وصندوق الوارد المعتاد، فتزداد أهمية سجلات المهمة.
نقطة بداية معقولة
خادم وثائق للقراءة فقط بنطاق حساب واحد بين المشاريع مناسب لتجربة صغيرة. الخادم المعتمد على roots يحتاج اختبارا منفصلا. وسأراجع تغيير الانتظار في CI حتى من دون مشاركة الاتصالات. ملاحظات الإصدار وأرقام الشعبية لا تصدق على السلوك الفعلي لخادم بعينه.