تشغيل OpenCode على خادم VPS

ما هو OpenCode، وما الذي تُعِدّه هنا

OpenCode وكيل برمجة مفتوح المصدر بالذكاء الاصطناعي مصمَّم للطرفية (terminal). تُشغّله داخل دليل مشروع، فيقرأ شيفرتك، ويقترح تغييرات، ويعدّل الملفات، وينفّذ الأوامر، كل ذلك من واجهة نصية تفاعلية (TUI). وهو مرخَّص بترخيص MIT، ويتصل بأكثر من 75 مزوّد نموذج، وبنحو 165,000 نجمة على GitHub بحلول منتصف 2026، فهو وكيل البرمجة مفتوح المصدر الأكثر نجومية على الإطلاق. لتشغيل OpenCode على خادم VPS، تثبّته بحساب مخصص محدود الصلاحيات، وتضع مفتاح API الخاص بنموذجك في ملف خاص، وتُشغّله داخل tmux حتى تصمد الجلسة عند انقطاع اتصالك. هذا الدليل يفعل ذلك تحديدًا، بهذا الترتيب.

ملاحظة واحدة بشأن التسمية تجنّبك اللبس. المستودع الرسمي هو anomalyco/opencode، الذي يصونه فريق Anomaly (المعروف سابقًا باسم SST)، وكان المشروع يقع من قبل في sst/opencode. ويوجد أيضًا على GitHub مستودع أقدم لا صلة له بالمشروع اسمه opencode-ai/opencode، فتأكد من أنك تقرأ وثائق المشروع الصحيح. الموقع الرسمي هو opencode.ai.

لماذا تُشغّل OpenCode على خادم VPS

جلسة وكيل البرمجة طويلة. قد يمضي OpenCode دقائق كثيرة في إعادة هيكلة (refactor) أو في تشغيل حزمة اختبارات، وإن كان يعمل على حاسوبك المحمول، فإن إغلاق الغطاء أو انقطاع اتصال Wi-Fi يقتل الجلسة في منتصف المهمة. أما على خادم VPS داخل tmux، فيواصل الوكيل العمل بعد انقطاع اتصالك، وتعود لاحقًا لتقرأ ما فعله. هذا هو النمط نفسه الذي يصفه تشغيل Claude Code على خادم VPS مع tmux، وهو أكبر مكسب في راحة الاستخدام من نقل الوكيل بعيدًا عن حاسوبك المحمول.

السبب الثاني هو الموقع. خادم VPS قريب من الشيفرة التي تنشرها: المستودع، وأدوات البناء، وقاعدة بيانات الاختبار، وغالبًا بيئة التجهيز (staging) توجد جميعها هناك بالفعل أو بجوارها. والوكيل الذي يعدّل الشيفرة وينفّذ الاختبارات يعمل على أفضل وجه على الجهاز الذي تُنفَّذ عليه تلك الاختبارات فعليًا. ولأن الجهاز خادم تتحكم فيه أنت، يمكنك أن تمنح الوكيل بيئة محصورة عن قصد، وهذا ما يفعله القسم التالي.

وإن كنت لا تزال تختار أداة، فإن تشغيل وكيل ذكاء اصطناعي للبرمجة على VPS يستعرض مجالًا أوسع من الأدوات، بما في ذلك Aider وGoose.

امنح OpenCode مستخدمه الخاص

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

بخلاف وكيل يعمل في الخلفية، OpenCode تفاعلي، لذا يحتاج مستخدمه إلى shell حقيقي ودليل منزلي:

sudo useradd --create-home --shell /bin/bash opencode
sudo -iu opencode

أبقِ المشاريع التي تريده أن يعمل عليها تحت /home/opencode، مستنسخة (cloned) بواسطة ذلك المستخدم. ولا تمنح الحساب أي صلاحيات sudo. فإن نفّذ الوكيل أمرًا هدّامًا، فلن يستطيع تدمير إلا ما يملكه هذا الحساب الواحد، وهذا هو المنطق نفسه وراء تشغيل الخدمات بمستخدم محدود الصلاحيات. اعمل أيضًا داخل مستودع git، لأن المستودع يحوّل أي تعديل سيئ إلى git revert بدلًا من خسارة.

ثبّت OpenCode

يوثّق المشروع طريقتين للتثبيت. سكربت التثبيت هو الأسرع، وتشغيله بحساب المستخدم opencode يُبقي كل شيء داخل الدليل المنزلي لذلك المستخدم:

curl -fsSL https://opencode.ai/install | bash

تنطبق هنا عادة curl | bash المعتادة كما تنطبق في كل مكان: على خادم يهمّك أمره، نزّل السكربت أولًا، واقرأه، ثم شغّله. بعد التثبيت، ابدأ shell جديدًا حتى يسري تغيير PATH الذي يجريه المثبِّت، ثم تحقق من أن الملف التنفيذي يستجيب:

opencode --version

إن كنت تفضّل مدير حزم وكان Node.js موجودًا بالفعل على الجهاز، فإن طريق npm يثبّت الأداة نفسها على مستوى النظام كله، ما يضع الملف التنفيذي opencode على PATH لكل مستخدم:

sudo npm install -g opencode-ai

في الحالتين، الفحص واحد: يطبع opencode --version رقم إصدار. أما رسالة command not found بعد التثبيت بالسكربت فتعني أن الـ shell الحالي لم يقرأ بعد PATH المحدَّث، فسجّل الخروج ثم أعد تسجيل الدخول بحساب المستخدم opencode.

ضع مفتاح API في ملف خاص

يحتاج OpenCode إلى مفتاح لأي مزوّد نموذج تستخدمه، وذلك المفتاح قادر على إنفاق مالك، فعامله معاملة كلمة المرور. أنشئ ملفًا لا يستطيع قراءته سوى المستخدم opencode، بصلاحيات mode 600، واحفظ المفتاح فيه بدلًا من كتابته داخل أوامر ينتهي بها المطاف في سجل الـ shell لديك:

install -m 600 /dev/null ~/opencode.env
nano ~/opencode.env

ضع فيه متغيّر مزوّدك، على سبيل المثال ANTHROPIC_API_KEY=... أو ما يعادله لدى مزوّدك، لأن OpenCode يلتقط متغيرات البيئة القياسية الخاصة بالمزوّدين. حمّل الملف إلى الـ shell قبل أن تُشغّل الوكيل:

set -a; source ~/opencode.env; set +a

لدى OpenCode أيضًا بديل تفاعلي: يرشدك أمر /connect داخل الـ TUI خطوة بخطوة لإضافة مزوّد، ويحفظ بيانات الاعتماد في ~/.local/share/opencode/auth.json داخل الدليل المنزلي للمستخدم. إن استخدمت هذا الطريق، فتأكد من خصوصية الملف بالأمر chmod 600 ~/.local/share/opencode/auth.json. كلا الطريقين يُبقي المفتاح بعيدًا عن أسطر أوامرك؛ اختر واحدًا منهما والتزم به.

شغّل OpenCode داخل tmux

tmux هو ما يجعل إعداد الـ VPS يستحق العناء، لأن جلسة tmux تواصل العمل حين تنتهي جلسة SSH لديك. ابدأ جلسة، وانتقل إلى مشروعك، وأطلق الوكيل:

tmux new -s opencode
cd ~/my-project
opencode

ينبغي أن ترى الـ TUI يفتح بمُوجِّه (prompt) في الأسفل واسم مشروعك في الواجهة. أعطه مهمة بلغة عادية، فيبدأ بقراءة الملفات واقتراح التغييرات. وحين تريد المغادرة، افصل الجلسة (detach) بالضغط على Ctrl-b ثم d، ويواصل الوكيل العمل وحاسوبك المحمول مغلق. أعد الاتصال لاحقًا بالأمر:

tmux attach -t opencode

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

وجّهه إلى نموذج

OpenCode محايد تجاه المزوّد. يستخدم AI SDK وكتالوج Models.dev لدعم أكثر من 75 مزوّدًا، فتعمل الأداة نفسها مع Anthropic وOpenAI وGoogle وعشرات غيرها، بما في ذلك الخوادم المحلية. الطريق السريع هو أمر /connect داخل الـ TUI، الذي يسرد المزوّدين ويتولى بيانات الاعتماد. أما لإعداد يمكنك إيداعه (commit) في المستودع وإعادة إنتاجه، فضع ملف opencode.json في جذر المشروع واضبط النموذج بالصيغة provider/model-id:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "anthropic/claude-sonnet-4-20250514"
}

يعمل نموذج محلي عبر الملف نفسه، لأن أي خادم متوافق مع OpenAI يمكن أن يُعلَن مزوّدًا. وإن كنت تقدّم نموذجًا بواسطة Ollama على خادم VPS نفسه، فإن الإعداد يشير إلى واجهة API المحلية الخاصة به، واسم النموذج هو ما يعرضه ollama list على جهازك:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://127.0.0.1:11434/v1" },
      "models": { "your-model-name": { "name": "Local coding model" } }
    }
  }
}

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

نطاق الضرر، بصراحة

وكيل البرمجة ليس سلبيًا، فقل بوضوح ما يحتويه هذا الإعداد وما لا يحتويه. إنه يحتوي فعلًا على أضرار الملفات: فالمستخدم opencode يملك دليله المنزلي وحده ولا شيء غيره، فتتوقف التعديلات والمحذوفات عند تلك الحدود. ويحتوي فعلًا على تسرّب بيانات الاعتماد: فالمفتاح يقع في ملف واحد بصلاحيات mode 600، في حساب واحد. لكنه لا يحتوي على ما يستطيع الحساب فعله بصورة مشروعة، فإن كان دليل المشروع يحمل بيانات اعتماد النشر الإنتاجي، يستطيع الوكيل استخدامها؛ فأبقِ تلك البيانات كليًا خارج حساب الوكيل.

بخلاف وكيل بوابة مثل OpenClaw، OpenCode برنامج طرفية تفاعلي، لا برنامج خفي (daemon). فهو لا يفتح أي منفذ استماع ولا يشغّل أي خدمة طويلة الأمد، فلا توجد وحدة systemd تكتبها ولا منفذ تحميه بجدار الحماية من أجل الوكيل نفسه. الاحتواء هنا هو حساب المستخدم ودليل المشروع، ولهذا كان القسم الأول من هذا الدليل هو الأهم على الإطلاق.

لكن الجهاز المحيط بذلك كله ما زال يحتاج إلى العناية المعتادة، لأن خادم VPS المخصص للبرمجة يظل خادمًا عامًا: SSH بالمفاتيح فقط مع تعطيل دخول root، كما في تحصين SSH على خادم VPS، وجدار حماية يرفض كل شيء افتراضيًا، وتحديثات منتظمة. وراجع أيضًا ما ينتجه الوكيل. اقرأ الفروق (diffs) الخاصة به قبل أن تدفعها، بالطريقة نفسها التي تقرأ بها طلب دمج (pull request) من مساهم جديد، لأنك أنت من ينشر النتيجة.

وأخيرًا، أبقِ الأداة نفسها محدَّثة. يصدر OpenCode إصدارات جديدة كثيرًا، وتحمل التحديثات إصلاحات مهمة لبرنامج ينفّذ أوامر على خادمك. التحديث يسلك الطريق نفسه الذي ثبّتّ به: أعد تشغيل سكربت التثبيت بحساب المستخدم opencode، أو نفّذ sudo npm update -g opencode-ai إن كنت قد ثبّتّ عبر npm، ثم تأكد من الإصدار الجديد بالأمر opencode --version. دقيقة واحدة من الصيانة بين الحين والآخر أرخص كثيرًا من تصحيح خلل أصلحه بالفعل إصدار عمره أشهر.

FAQ

هل يمكن لـ OpenCode استخدام نموذج محلي بدلًا من واجهة API مدفوعة؟

نعم. يعامل OpenCode أي خادم متوافق مع OpenAI بوصفه مزوّدًا، فنموذج تقدّمه Ollama على خادم VPS نفسه يعمل: أعلن المزوّد في opencode.json مع baseURL المحلي واسم النموذج الذي تعرضه Ollama. أما المشكلة فهي العتاد، لأن نموذجًا جيدًا بما يكفي لعمل برمجي حقيقي يحتاج إلى ذاكرة كبيرة، فحدّد حجم الخادم بما يناسب النموذج قبل أن تنزّله.

كيف أُبقي OpenCode يعمل بعد إغلاق حاسوبي المحمول؟

شغّله داخل tmux على الـ VPS. ابدأ الوكيل في جلسة مسمّاة بالأمر tmux new -s opencode، وافصلها (detach) بالضغط على Ctrl-b ثم d، وتواصل الجلسة العمل على الخادم بعد انتهاء اتصال SSH لديك. أعد الاتصال في أي وقت بالأمر tmux attach -t opencode وستجد المحادثة وأي مهمة قيد التنفيذ ما زالت موجودة. تنهي إعادة تشغيل الخادم الجلسة، فابدأ جلسة جديدة بعد كل إعادة تشغيل.

هل من الآمن أن أدع OpenCode ينفّذ أوامر على خادم VPS الخاص بي؟

الأمر قابل للإدارة إن احتويته. امنح OpenCode مستخدمًا مخصصًا محدود الصلاحيات بلا sudo، وأبقِ مشاريعه في git حتى يكون كل تعديل قابلًا للتراجع، واحفظ مفتاح API في ملف بصلاحيات mode 600، واستخدم وكيله Plan لتمريرة أولى للقراءة فقط قبل أن تدع وكيل Build يغيّر أي شيء. عندها لا يستطيع الوكيل الإضرار إلا بما يملكه حسابه الخاص، ويبقى بقية الخادم بعيدًا عن متناوله.

ما الفرق بين OpenCode وClaude Code؟

OpenCode مفتوح المصدر (MIT) ومحايد تجاه المزوّد، ويتصل بأكثر من 75 مزوّد نموذج، من بينها مزوّدون محليون، عبر واجهة واحدة. أما Claude Code فهو وكيل الطرفية الخاص بـ Anthropic، المبني حول نماذج Anthropic نفسها. إن أردت أداة واحدة تعمل مع مزوّدين كثيرين، أو كومة (stack) مستضافة ذاتيًا بالكامل مع نموذج محلي، فـ OpenCode هو الخيار المناسب؛ وكلاهما يعمل جيدًا على خادم VPS داخل tmux بإعداد المستخدم محدود الصلاحيات نفسه.