تشغيل Claude Code بأمان على خادم

ما يعنيه تشغيل Claude Code بأمان على خادم

لتشغيل Claude Code بأمان على خادم، أبقِ طلبات الإذن فيه مفعّلة، وشغّله بحساب مستخدم مخصص محدود الصلاحيات، وامنح المهام غير المراقبة حدًّا حقيقيًا بدلًا من الثقة: الـsandbox المدمج، أو حاوية، أو خادم VPS قابل للتخلص منه لا يحمل شيئًا يهمّك. خيار --dangerously-skip-permissions يزيل خطوة الموافقة بين النموذج والـshell الخاص بك. هذه المقايضة قد تكون معقولة في العمل غير المراقب، لكن فقط داخل حدّ يقيّد ما يمكن أن يبلغه أمر واحد سيئ. يشرح هذا الدليل ما الذي يغيّره الخيار فعليًا، وكيف تبني ذلك الحدّ عبر درجات من العزل المتصاعد.

ما الذي يستطيع Claude Code فعله على جهازك

Claude Code وكيل برمجي (coding agent) يعمل داخل الطرفية (terminal) لديك. يقرأ الملفات، ويكتب الملفات، وينفّذ أوامر shell بصفة المستخدم الذي شغّله. هذه هي القيمة الكاملة للأداة: يمكنه استنساخ مستودع، وتعديل الشيفرة، وتشغيل الاختبارات، وقراءة الفشل، وإصلاح الشيفرة في حلقة متكررة، دون أن تكتب كل أمر بنفسك. إذا لم تكن قد أعددته بعد على خادم، فإن تشغيل Claude Code على VPS باستخدام tmux يغطي التثبيت وإدارة الجلسات. أما هذه الصفحة فتتناول القدرة التي تمنحها له بمجرد أن يصبح جاهزًا هناك.

الخطر هو الوجه الآخر لما سبق ذكره: أي عملية تنفّذ أوامر shell بصفة مستخدمك تستطيع فعل كل ما يستطيعه مستخدمك. تستطيع قراءة ~/.ssh/id_ed25519، و~/.aws/credentials، وكل ملف .env يستطيع مستخدمك فتحه. تستطيع تنفيذ curl وإرسال بيانات إلى أي مضيف يستطيع الخادم الوصول إليه. تستطيع تنفيذ git push --force. الوكيل ليس له دافع ذاتي. الخطر هو أن مهمة ما تسير بشكل خاطئ، أو أن نصًا قرأه أثناء عمله يحمل تعليمات كتبها شخص آخر: صفحة ويب جلبها، أو تعليق في تذكرة (issue) طُلب منه إصلاحها. تُعرف هذه الحالة الثانية باسم حقن التعليمات (prompt injection)، ولهذا فإن «النموذج عادة ما يكون حصيفًا» ليست خطة أمنية. أنت تخطط للتشغيلة السيئة، لا للتشغيلة المتوسطة.

نظام الأذونات بلغة بسيطة

افتراضيًا، يطلب Claude Code إذنًا قبل أن يتصرف. قراءة الملفات داخل المشروع تحدث بصمت، أما تعديل ملف أو تنفيذ أمر shell فيعرض عليك أولًا التعديل أو الأمر بدقة وينتظر موافقتك. يمكنك الموافقة على إجراء واحد، أو الموافقة على ذلك النوع من الإجراءات لبقية الجلسة. هذه الموافقات محصورة في نطاق الجلسة: أغلق الـCLI، وتبدأ الجلسة التالية حذرة من جديد. أما القواعد التي تريد الاحتفاظ بها، فيحتفظ بها ملف الإعدادات في قوائم allow وask وdeny دائمة. على سبيل المثال: السماح بـ git status، والسؤال عند git push، ورفض قراءة .env. الأولوية دائمًا لقواعد deny.

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

ما الذي يغيّره --dangerously-skip-permissions

claude --dangerously-skip-permissions يعطّل خطوة الموافقة. تحدث التعديلات دون طلب إذن. تُنفَّذ أوامر shell دون طلب إذن. وتُتخطّى أيضًا فحوصات المسارات المحمية التي تحرس عادة المواقع الحساسة. قواعد deny الصريحة التي وضعتها تبقى سارية، وبعض الإجراءات الشديدة الخطورة ما زالت تتوقف لتطلب الإذن، لكن الخلاصة العملية بسيطة: كل ما يقرر النموذج تنفيذه، يُنفَّذ.

حقيقتان عن هذا الخيار تهمّان على الخادم. أولًا، يُحظر هذا الخيار حين يعمل Claude Code بصفة root أو تحت sudo على Linux وmacOS، لأن root من دون أي طلبات إذن يستطيع تغيير أي ملف أو خدمة على الجهاز. والوكيل يحتاج على أي حال إلى حساب خاص به محدود الصلاحيات، والخيار يفرض ذلك. ثانيًا، لا يغيّر هذا الخيار سلوك النموذج بأي شكل. إنه يُخرج الإنسان من الحلقة ولا يغيّر شيئًا آخر، بحيث ينفَّذ الآن كل خطأ كان طلب الإذن سيمنعه.

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

الـsandbox المدمج في Claude Code

قبل الحديث عن الدرجات، اعلم أن Claude Code بات يقدّم الآن sandbox على مستوى نظام التشغيل للأوامر التي ينفّذها، وهو يزيل معظم الأسباب التي كانت تدفع الناس إلى اللجوء إلى خيار تخطي الأذونات. على Linux يستخدم bubblewrap لعزل نظام الملفات، إضافة إلى socat لتوجيه حركة الشبكة عبر بروكسي. داخل الـsandbox، لا يستطيع الأمر الكتابة إلا في دليل المشروع ودليل مؤقت خاص بالجلسة، ولا يستطيع الوصول إلى الشبكة إلا عبر بروكسي يتحقق من كل نطاق مقابل قائمة السماح. وفي أول مرة يطلب فيها أمر نطاقًا جديدًا، يسألك Claude Code.

فعّله بأمر /sandbox داخل الجلسة. على Ubuntu وDebian، ثبّت أولًا الحزمتين اللتين يحتاج إليهما:

sudo apt install bubblewrap socat

على Ubuntu 24.04 وما بعده، تمنع سياسة AppArmor الافتراضية bubblewrap من إنشاء مساحات أسماء المستخدم (user namespaces) التي يحتاج إليها. تخبرك لوحة الـsandbox حين ينقص شيء، ويتضمّن توثيق Claude Code الخاص بالـsandbox ملف AppArmor القصير الذي يصلح ذلك.

للـsandbox وضع سماح تلقائي (auto-allow): تُنفَّذ الأوامر التي تعمل داخله دون أي طلب إذن، لأن الحدّ المفروض يؤدي الآن العمل الذي كان يؤديه طلب الإذن. أما الأوامر التي لا يمكنها العمل داخل الـsandbox فتعود إلى تدفق الأذونات العادي، بحيث ما زالت الإجراءات غير المألوفة حقًا تطلب الإذن. بالنسبة لمعظم أعباء العمل على الخوادم، هذا هو البديل الصحيح لخيار تخطي الأذونات، لأنك تحصل على أسئلة أقل بكثير مع حدّ يفرضه نظام التشغيل بدلًا من عدم وجود أي حدّ.

كن صادقًا بشأن حدوده. افتراضيًا، ما زال بإمكان أمر يعمل داخل الـsandbox قراءة معظم نظام الملفات، بما في ذلك ملفات بيانات الاعتماد، ما لم ترفض تلك المسارات؛ وإعداد sandbox.credentials موجود لهذا الغرض بالضبط. بروكسي الشبكة يفحص أسماء النطاقات ولا يفحص حركة المرور نفسها، لذا فإن سماحًا واسعًا مثل github.com ما زال يترك مجالًا لنقل البيانات إلى الخارج. Docker لا يعمل داخله. الـsandbox يرفع الحدّ الأدنى كثيرًا. إنه ليس حدّ عزل كاملًا، ولهذا ما زالت الدرجات أدناه مهمة.

سلّم الاحتواء

ثلاث درجات، بترتيب تصاعدي من العزل. اختر أدناها التي تناسب ما يعيش أيضًا على الجهاز.

الدرجة 1: مستخدم مخصص محدود الصلاحيات. يحصل الوكيل على حسابه الخاص، ودليله المنزلي الخاص، ودليل مشروعه الخاص، ودون sudo:

sudo adduser --disabled-password --gecos "" agent

حدّ الحساب يبقي الوكيل بعيدًا عن ملفاتك: مفاتيح SSH الخاصة بك، وكل مشروع آخر على الجهاز. كما أنه يجعل خيار تخطي الأذونات قابلًا للاستخدام أصلًا، بما أن الخيار يرفض العمل بصفة root. هذا هو المبدأ نفسه الذي يقوم عليه تشغيل كل خدمة بمستخدم محدود الصلاحيات، مطبَّقًا على وكيل. ما لا تحدّه الدرجة 1: الشبكة، وأي شيء على الجهاز قابل للقراءة من الجميع (world-readable).

الدرجة 2: حاوية. تنشر Anthropic devcontainer مرجعيًا يشغّل Claude Code بمستخدم غير root، مع قواعد جدار حماية تحدّ من المضيفات التي يستطيع الوكيل الوصول إليها، وحاوية تبنيها بنفسك تؤدي المهمة نفسها. ينكمش نظام الملفات إلى وحدات التخزين (volumes) التي تُركِّبها، وتنكمش حركة المرور الصادرة إلى ما تسمح به قواعد الحاوية. هذه هي الدرجة الوسطى الصحيحة حين يستضيف الخادم خدمات أخرى تهمّك. حدّها أن الحاويات تشترك في نواة (kernel) المضيف، وأن تركيبًا (mount) واحدًا غير حذر يُبطل الحدّ؛ أعطِ الحاوية /var/run/docker.sock وستتمكن من الوصول إلى المضيف كله.

الدرجة 3: خادم VPS مخصص. أقوى درجة هي أكثرها خشونة: امنح الوكيل جهازًا كاملًا لا يحتوي على شيء يهمّك. VPS صغير يكلّف بضعة دولارات في الشهر. أعدّه باستخدام دليل أول عشر دقائق على خادم VPS جديد، وخذ لقطة (snapshot) للحالة النظيفة، ودع الوكيل يعمل. لا شيء آخر يعيش هناك. لا مفتاح SSH شخصي، بل مفتاح نشر (deploy key) مقتصر على مستودع واحد بعينه. لا بيانات اعتماد سحابية، ولا بيانات إنتاج. حين تسير تشغيلة ما بشكل خاطئ، أو حين تريد ببساطة صفحة نظيفة من جديد، استعد اللقطة أو دمّر الجهاز وأعد بناءه في دقائق. نطاق الضرر هو الإيجار. هذا هو الإعداد الذي يتوقف فيه --dangerously-skip-permissions عن أن يكون مخيفًا، لأن أسوأ نتيجة واقعية هي خادم مُعاد بناؤه ورمز واحد مُلغى.

الدرجات تتراكم فوق بعضها. وكيل يعمل داخل sandbox، بصفة مستخدم محدود الصلاحيات، على VPS قابل للتخلص منه، يكلّف زيادة تكاد لا تُذكر ويجعل قصص الفشل مملة. المَلل هو الهدف.

احمِ بيانات الاعتماد

القاعدة التي تسدد ثمن كل شيء آخر: يجب ألا يستطيع مستخدم الوكيل قراءة أسرار تخص أي شيء آخر.

أعطِ مفتاح API للوكيل ولا شيء آخر. ضعه في ملف مملوك لمستخدم الوكيل بصلاحيات (mode) 600، وحمّله عند بدء shell:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

بعد ذلك أغلق الاتجاه الآخر. على Debian وUbuntu، غالبًا ما تُنشأ الأدلة المنزلية قابلة للقراءة من كل مستخدم على الجهاز، فشدّد دليلك أنت: chmod 750 /home/youruser. تحقق بالأمر ls -ld /home/* وأصلح أي شيء يستطيع حساب الوكيل عرضه.

حدّد نطاق كل رمز (token). رمز GitHub دقيق الصلاحيات مقتصر على مستودع واحد، أو مفتاح نشر خاص بكل مستودع، يعني أن بيانات اعتماد مسرَّبة تُفقِدك مشروعًا واحدًا لا حسابك كله. إذا كنت تستخدم الـsandbox، أضِف إعدادات بيانات الاعتماد الخاصة به بحيث يُرفض ~/.ssh و~/.aws حتى للقراءة. وأبقِ بيانات اعتماد الإنتاج بعيدة عن الجهاز كليًا، لأن الوكيل لا يستطيع تسريب سرّ لم يكن موجودًا فيه أصلًا.

Git هو شبكة الأمان

كل تغيير يجريه الوكيل ينبغي أن يكون قابلًا للمراجعة والتراجع، وgit يمنحك الاثنين مجانًا إذا عمل الوكيل على فرع:

git switch -c agent/refactor-auth

راجع التشغيلة بعد ذلك بالأمر git diff main...agent/refactor-auth، وادمج ما هو جيد، واحذف الفرع إذا لم تصل التشغيلة إلى شيء. احمِ الفرع الرئيسي main من جهة منصة الاستضافة (forge)، بحيث لا يستطيع رمز الوكيل الدفع (push) إليه ولا فرض الدفع (force-push) إلى أي مكان. تاريخ الـcommits يعمل أيضًا كسجل تدقيق لما حدث أثناء نومك، ويفوق ذلك قيمة أي قدر من تمرير الطرفية (scrollback).

الشبكة جزء من نطاق الضرر

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

لا تحاول حل مشكلة حركة المرور الصادرة بـ ufw وحده. يسمح ufw بكل حركة المرور الصادرة افتراضيًا، وكتابة قواعد صادرة ما زالت تسمح بـ apt وnpm وgit وواجهة Claude API عمل شاق يتعطل بصمت. اختر الحدّ بدلًا من ذلك على مستوى الـsandbox أو الحاوية أو الجهاز، حيث تؤدي قائمة سماح للنطاقات أو جهاز عارٍ (bare machine) العمل نفسه بنظافة.

إذا كنت تبني وكيلك الخاص مقابل الـAPI بدلًا من تشغيل Claude Code، فالتفكير نفسه ينطبق دون تغيير. بناء وكيل ذكاء اصطناعي بواسطة Claude على VPS يغطي هذا المسار، ووكيله يستحق المستخدم المخصص نفسه، والرموز المحدودة النطاق نفسها، والجهاز القابل للتخلص منه نفسه.

حصّن الجهاز أولًا

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

FAQ

هل يُعَدّ --dangerously-skip-permissions آمنًا للاستخدام على خادم؟

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

هل لدى Claude Code sandbox؟

نعم. يقدّم Claude Code sandbox مدمجًا لأوامر shell، يُفتح بأمر /sandbox. يستخدم bubblewrap على Linux وSeatbelt على macOS، ويقصر الكتابة على دليل المشروع، ويوجّه الوصول إلى الشبكة عبر بروكسي لا يسمح إلا بالنطاقات المعتمدة. وضع السماح التلقائي فيه ينفّذ الأوامر التي تعمل داخله دون طلبات إذن، فيقلّل المقاطعات بالطريقة نفسها التي يفعلها خيار تخطي الأذونات مع الحفاظ على حدّ يفرضه نظام التشغيل. إنه ليس حدّ عزل كاملًا، فاقرنه بمستخدم مخصص أو جهاز مخصص للتشغيلات غير المراقبة.

لماذا يرفض خيار تخطي الأذونات العمل بصفة root؟

يحظر Claude Code تنفيذ --dangerously-skip-permissions حين يعمل بصفة root أو تحت sudo على Linux وmacOS، لأن root بلا أي طلبات إذن يستطيع تعديل أي ملف وأي خدمة في النظام. الحل ليس في مقاومة هذا الفحص. أنشئ مستخدمًا محدود الصلاحيات للوكيل وشغّله هناك؛ فحدّ الحساب هذا هو أول طبقات الاحتواء وأرخصها.

هل يستطيع Claude Code قراءة مفاتيح SSH وملفات .env الخاصة بي؟

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

ما هي أكثر الطرق أمانًا لتشغيل Claude Code دون مراقبة؟

خادم VPS مخصص رخيص لا يُستخدم إلا لعمل الوكيل: مُحصَّن خلال عشر دقائق، أُخذت له لقطة نظيفة، يشغّل Claude Code تحت مستخدم محدود الصلاحيات مع تفعيل الـsandbox، وملف بصلاحيات 600 يحمل مفتاح API، ومفتاح نشر خاص بكل مستودع، وكل العمل على فروع تراجعها قبل الدمج. إذا سارت تشغيلة ما بشكل خاطئ، تُلغي رمزًا واحدًا وتستعيد اللقطة، ولا يتأثر أي شيء آخر تملكه.