شغّل Claude Code بأمان على خادمك

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

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

ما الذي يستطيع Claude Code فعله على خادمك

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

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

نظام الصلاحيات بكلمات بسيطة

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

يفترض هذا التصميم أن شخصاً يراقب الطرفية، وهذا صحيح على الحاسوب المحمول. أما على الخادم، فغالباً لا يراقب أحد الطرفية. تبدأ مهمة طويلة داخل tmux ثم تذهب إلى النوم، فيتوقف الوكيل لطرح سؤال عند الساعة 2 صباحاً، ولا يحرز أي تقدم حتى الصباح. يسبب هذا التوقف تكلفة مالية إلى جانب ضياع الوقت، لأن جلسة Claude Code الخاملة تفقد ذاكرة التخزين المؤقت الدافئة للمطالبة، وتدفع الجولة التالية تكلفة إعادة بنائها. هذا هو السبب الفعلي الذي يدفع الناس إلى استخدام skip flag على الخوادم، والمشكلة التي يحلها هذا الخيار حقيقية. يشرح باقي هذا الدليل كيفية حلها من دون التخلي عن جميع وسائل الحماية.

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

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

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

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

الحاوية المعزولة المضمّنة في Claude Code

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

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

sudo apt install bubblewrap socat

في Ubuntu 24.04 والإصدارات الأحدث، تمنع سياسة AppArmor الافتراضية bubblewrap من إنشاء مساحات أسماء المستخدمين التي يحتاج إليها. تعرض لوحة الحماية المعزولة ما ينقصك، وتحتوي وثائق العزل في Claude Code على ملف تعريف AppArmor المختصر الذي يعالج المشكلة.

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

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

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

ثلاث درجات، مرتبة من الأقل إلى الأعلى من حيث العزل. اختر أدنى درجة تناسب ما يوجد أيضاً على الخادم.

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

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

يبقي حد الحساب الوكيل بعيداً عن ملفاتك: مفاتيح SSH وكل مشروع آخر على الجهاز. كما يجعل استخدام skip flag ممكناً أصلاً، لأن هذا الـflag يرفض التشغيل بصفة root. هذا هو المبدأ نفسه الوارد في تشغيل كل خدمة بصفة مستخدم غير ذي صلاحيات، مطبقاً على وكيل. لا تعزل الدرجة 1 الشبكة أو أي شيء على الجهاز يمكن للجميع قراءته.

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

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

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

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

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

امنح مفتاح API للوكيل فقط. ضعه في ملف يملكه مستخدم الوكيل وبصلاحية 600، وحمّله عند بدء الصدفة:

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/* وأصلح أي شيء يمكن لحساب الوكيل عرضه.

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

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

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

git switch -c agent/refactor-auth

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

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

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

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

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

أمِّن الخادم أولاً

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

FAQ

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

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

هل يتضمن Claude Code بيئة sandbox؟

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

لماذا يرفض خيار skip التشغيل بصفة root؟

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

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

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

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

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