ما الذي يستطيع dsh plugin الوصول إليه وكيف تفحصه؟

ما هو plugin في dsh، وما الذي يمكنه فعله؟

إن plugins في dsh هي حزم Node يحمّلها DeepSeek Harness داخل العملية الخاصة به. يؤدي تثبيت plugin إلى تشغيل كود يخص جهة أخرى باستخدام صلاحيات agent لديك، وعلى الجهاز الذي يستطيع agent الوصول إليه مسبقاً. لا يوجد حاجز بين plugin محمّل وبقية harness. لذلك، قبل تثبيت plugin، اسأل عمّا يمكن لهذا الكود الوصول إليه، وكيف تحافظ على نطاق ذلك الوصول محدوداً.

dsh ‏(DeepSeek Harness) هو harness مفتوح المصدر من DeepSeek AI، ومبني على إطار plugins يسمى Cordis. يذكر README الخاص بالمشروع صراحةً أن كل شيء فيه هو plugin. مواءم النموذج هي plugin. وواجهة الويب التي تكتب فيها هي plugin. وكل ما تثبته من خارج المشروع يوضع في الشجرة نفسها، وبمستوى الثقة نفسه الممنوح للأجزاء التي جاءت معه. إذا لم تكن قد شغّلت واحداً بعد، فابدأ بـ DeepSeek Harness على VPS ثم عُد قبل أن تضيف إليه أي شيء.

نقاط التوسعة التي يمكن لـplugin الوصول إليها مذكورة في AGENTS.md في المستودع. واعتباراً من August 2026، تشمل ما يلي:

• LLM (نموذج اللغة الكبير): المزوّد الذي تُستخدم معه API key الخاصة بك
• Shell: قدرة bash، مع local وpwsh providers
• Filesystem: وصول إلى الملفات يخضع للسياسات
• Web: search وfetch providers
• Subprocess: process-tree provider
• Workflow: worker threads
• Subagent: تفويض المهام إلى agents إضافيين
• Settings وcredentials: الإعدادات المحفوظة ومتغيرات البيئة الخاصة بك

يسجّل plugin أيضاً tools على ctx.tools، وتوضح الوثائق أن schema الخاصة بـtool مسجّل تُضاف إلى تجميع prompt. وهذا هو الجزء الذي يغفل عنه كثيرون. يمكن لـplugin تغيير ما يقرر agent لديك فعله من دون أن ينفّذ كوده الخاص أي شيء غير معتاد، لأن الوصف الذي يضيفه يصبح نصاً يقرأه النموذج. هذه هي البنية نفسها لمشكلة prompt injection ضد coding agents، مع اختلاف واحد: يصل هذا النص عند التثبيت، ويبقى إلى أن تزيل plugin.

كيف يعثر dsh على الإضافات ويحمّلها؟

لا يوجد مجلد عام للإضافات. يكون dsh قيد التشغيل شجرة إضافات تُركَّب عند الإقلاع من طبقات مرتبة، والوحدة التي تحتفظ باختياراتك هي profile. تكون القيمة الافتراضية لـ $DSH_HOME هي ~/.dsh، ويقع كل profile في $DSH_HOME/profiles/<name>. ينشئ profileان web وheadless نفسيهما عند الاستخدام الأول اعتماداً على القوالب المضمّنة مع البرنامج.

يحتوي مجلد profile على ملفين يحددان كل شيء:

• package.json، ويحتوي على تبعيات الإضافات خارج الشجرة، بالإضافة إلى manifest من dsh.profile يتضمن قائمة bundles المرتبة
• cordis.patch.yml، وهي طبقة التصحيحات الخاصة بك فوق تلك الحزم

ls ~/.dsh
ls ~/.dsh/profiles/web

يطبّق الإقلاع الطبقات بهذا الترتيب، وتغلب الطبقات اللاحقة الطبقات السابقة:

1. جذر فارغ
2. حزم profile، بالترتيب الذي تسرده القائمة
3. cordis.patch.yml الخاص بـprofile
4. $DSH_HOME/cordis.patch.yml
5. أي طبقات --patch <path> إضافية تمررها في سطر الأوامر

يعرض خياران نتيجة هذا التركيب من دون بدء أي شيء:

dsh --profile web --dump-default-config
dsh --profile web --dump-config

يعرض --dump-default-config الشجرة المركبة وحدها. ويضيف --dump-config طبقتَي profile والتصحيحات المنزلية، ولذلك فهو أقرب ما يكون إلى جرد فعلي لما سيحمّله الإقلاع التالي. اقرأه قبل أن تثق في جهاز ورثت إدارته.

انتبه إلى ملفات التصحيحات هذه. الإعدادات ليست بيانات خاملة هنا، لأن التنسيق يسمح بقيم موسومة من !!js داخل كتلة config الخاصة بإضافة. إن مقطع cordis.patch.yml المنسوخ من منشور في منتدى هو تعليمة برمجية، لذلك تعامل معه كما تتعامل مع shell script من المصدر نفسه.

ما الذي يشغّله dsh plugin add فعلياً؟

يمرّر dsh plugin --profile <name> <args> الوسائط التي يتلقاها إلى pnpm داخل دليل ملف التعريف، لذلك يجب أن يكون pnpm موجوداً في PATH. الأفعال هي أفعال pnpm:

dsh plugin --profile web add '<package-or-git-spec>'
dsh plugin --profile web remove '<package-name>'
dsh plugin --profile web why '<package-name>'
dsh plugin --profile web update

لذلك فإن نموذج أمان تثبيت إضافة dsh هو نموذج أمان تثبيت أي تبعية بأسلوب npm، مع خطوة إضافية واحدة تُحمَّل فيها النتيجة إلى agent الخاص بك. تأتي الحزمة مع شجرة تبعيات خاصة بها، وتنتهي كل حزمة في هذه الشجرة داخل العملية نفسها. ينطبق كل ما يرد في كيفية وصول هجمات سلسلة توريد npm إلى خادم هنا دون تعديل.

لا يشغّل pnpm 10 والإصدارات الأحدث scripts الإنشاء الخاصة بالتبعية افتراضياً، وتتم الموافقة لكل حزمة عبر onlyBuiltDependencies أو pnpm approve-builds. تحقّق من إصدار pnpm لديك:

pnpm --version

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

ما الذي تقرؤه قبل تثبيت إضافة dsh

نزّل tarball المنشور واقرأ محتواه. لا يُنفَّذ أي شيء عند فك أرشيف.

npm pack '<package-name>@<version>'
tar -tzf '<package-name>-<version>.tgz'
tar -xzf '<package-name>-<version>.tgz'
less package/package.json

توضح لك أربعة حقول في package.json معظم ما تحتاج إليه. اقرأ scripts بحثاً عن إدخالات preinstall وinstall وpostinstall. اقرأ dependencies بحثاً عن الأسماء التي لا تتعرّف إليها، أو الأسماء التي تختلف بحرف واحد عن أسماء تعرفها. اقرأ bin لمعرفة كل ما تريد الحزمة إضافته إلى PATH. اقرأ main أو exports لمعرفة ملف الإدخال، ثم افتح ذلك الملف واتّبعه.

ثم اقرأ الشيفرة التي سيجري تحميلها فعلياً. لا يوجد سبب يجعل إضافة تعلن عن أداة إشعارات تقرأ ~/.ssh، أو تتصل بمضيف لم تسمع به من قبل، أو تنشئ shell. إذا كانت الحزمة لا تتضمن إلا JavaScript مضمّناً أو مصغّراً، ولم يكن لها مصدر مطابق في مستودع عام، فهذه إجابتك. فضّل الإضافات التي يمكنك قراءة مصدرها، وفضّل الإضافات الصغيرة.

يمكنك أيضاً الاستعلام من السجل من دون تثبيت أي شيء:

pnpm view '<package-name>' dependencies
pnpm view '<package-name>' versions

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

ثبّت الإصدار واحتفظ بملف القفل

يعني نطاق الإصدار العائم أن الشيفرة داخل عملية الوكيل قد تتغير عند أي تثبيت أو تحديث من دون أن تقرر ذلك. ثبّت الإصدار.

dsh plugin --profile web add --save-exact '<package-name>@<version>'

يختلف موضع العلم بين إصدارات pnpm، لذلك تحقّق من النتيجة بدلاً من الوثوق بالأمر. افتح ملف تعريف المستخدم package.json بعد ذلك، وتأكد من أن التبعية تظهر كإصدار مجرد، من دون ^ أو ~ قبلها. يحدد هذا الملف ما سيتم تثبيته.

بعد ذلك، احتفظ بملف القفل؛ فهو يثبّت شجرة التبعيات الانتقالية كاملة، وليس الاسم في المستوى الأعلى فقط:

find ~/.dsh -maxdepth 3 -name 'pnpm-lock.yaml'

انسخه إلى مكان تُجري له نسخاً احتياطية، مع ملف تعريف المستخدم package.json. يعيد هذان الملفان إنشاء الشجرة نفسها على خادم جديد. شغّل dsh plugin --profile web update عندما تقرر تغيير الإصدارات، وليس كإجراء تنظيف روتيني، واقرأ الفرق في ملف القفل بعد ذلك.

إذا ثبّتَّ إضافة من git بدلاً من مستودع حزم، فثبّت commit بدلاً من الفرع. تمنحك مواصفة بالشكل github:owner/repo#<full commit sha> شجرة ثابتة. أما اسم الفرع فيمنحك محتوى ذلك الفرع عند المرة التالية التي يحل فيها pnpm التبعيات، وهذا قرار سلّمته إلى شخص آخر. يحتاج harness نفسه إلى الانضباط ذاته، لأن كل إصدار dsh منشور هو مرشح إصدار، ويمكن لتثبيت غير مثبت أن يحل إلى إصدار مختلف في أي يوم، وهذا هو مصدر معظم أخطاء تثبيت dsh وإصداراته.

سوق الإضافات، وما تستحقه كلمة «منسّق»

يحتوي dsh على سوق، ويُثبَّت فيه كسمة إضافية، وهذا يوضح شيئاً عن البنية:

dsh plugin --profile web add dshmarket

بعد إعادة التشغيل، يظهر ضمن Settings، ثم Plugin Market. يوضح ملف README الخاص به القيود بعبارات مباشرة. تقتصر عمليات التثبيت على المصادر المدرجة في سجل منسّق، ويُرفَض أي مصدر آخر. تُحظر نصوص البناء افتراضياً، ويتطلب تفعيل أي منها موافقة لكل حزمة. وتُعلَّم إضافات الطرفية قبل إدراجها في ملف تعريف الويب. أما الجملة الأهم فهي أن الإدراج لا يعني التزكية، لأن الإضافات عبارة عن شيفرة من جهات خارجية.

ترفع القائمة المنسّقة الحد الأدنى من الجودة. لكنها لا تقرأ الشيفرة نيابةً عنك، ولا يمكنها أن تخبرك بما سيفعله الإصدار التالي من إضافة بعد انتقال حساب المشرف إلى مالك آخر. تعامل مع التثبيت بنقرة واحدة كما تتعامل مع curl | bash من المؤلف نفسه. وهناك سطر آخر من ملف README يستحق التكرار: قد تحتوي نسخة احتياطية مُصدَّرة على بيانات اعتماد من إعدادات ملفك الشخصي، لذلك لا تُرفقها أبداً بتذكرة عامة أو بموقع للصق النصوص. إذا أردت قائمة بداية بدلاً من منهج، فمقالة إضافات dsh التي تستحق التثبيت هي المقالة المرافقة لهذه المقالة.

شغّل dsh بحساب مستخدم مستقل، وليس بحساب root

تقلل المراجعة من احتمال وصول شيء ضار. وتحدد أقلّ الصلاحيات ما يمكنه الوصول إليه عند حدوث ذلك. على VPS، من السهل إعداد هذا الجزء.

أنشئ للحزام حساب Unix خاصاً به ومجلداً منزلياً خاصاً به، ولا تشغّله بحساب root مطلقاً:

sudo adduser --disabled-password --gecos "" dshrun
sudo -iu dshrun

داخل تلك الجلسة، ابدأ الحزام كي ينشئ مجلده المنزلي تحت ذلك الحساب:

npx @deepseek-ai/dsh web

تخدم واجهة الويب على http://127.0.0.1:3080 افتراضياً. اتركها كذلك. يمكن لأي شيء يصل إلى ذلك المنفذ تشغيل agent لديه shell، ولذلك فإن نشر المنفذ 3080 يعادل نشر shell بعيد يعمل دون صلاحيات root، لكن بواجهة سهلة الاستخدام. يمكنك الوصول إليه من حاسوبك المحمول عبر نفق SSH بدلاً من ذلك:

ssh -L 3080:127.0.0.1:3080 you@your-vps

ثم تأكد من عدم وجود أي خدمة تستمع على عنوان عام:

ss -lnt | grep 3080

يجب أن يظهر العنوان المحلي على أنه 127.0.0.1:3080. إذا ظهر على أنه 0.0.0.0:3080، فسيكون جدارك الناري هو الحاجز الوحيد بين أي شخص غريب وagent الخاص بك. ينطبق منطق تشغيل Claude Code بأمان على VPS على dsh دون تغيير. امنح agent مجلد workspace واحداً يُسمح له بإتلافه، واحتفظ بكل ما لا يمكنك إعادة إنشائه خارج ذلك الجهاز. والأفضل من ذلك، تعامل مع هذا الخادم على أنه VM مؤقت لوكلاء البرمجة، لأن إعادة إنشاء VPS تستغرق ساعة، بينما تدقيقه يستغرق أسبوعاً.

مكان حفظ مفاتيحك، ولماذا لا تكفي أذونات الملفات وحدها

يحتفظ dsh بمفاتيح API في $DSH_HOME/.credentials.yaml، وبقيم البيئة في $DSH_HOME/.env، وبإعدادات النماذج في $DSH_HOME/settings.yaml، بينما يُخزّن سجل الجلسات ضمن $DSH_HOME/storages. يوضّح إعداد مفاتيح API والنماذج ونقاط النهاية في dsh أي مفتاح يجب أن تضعه في كل ملف من هذه الملفات، وما الذي يغادر الخادم فعلياً في كل وضع. احسم هذا قبل إضافة plugin، لأن كل مفتاح تضعه في الإعدادات يمثل مورداً إضافياً يمكن لـplugin قراءته. أمّن الملفين الحساسين:

chmod 600 ~/.dsh/.credentials.yaml ~/.dsh/.env
ls -l ~/.dsh

يمنح الوضع 600 المالك أذونات القراءة والكتابة، ولا يمنح أي أذونات للآخرين. من المفيد معرفة ذلك بالصيغة الرقمية والرمزية معاً (أوضاع chmod الرقمية مقابل الرمزية). لكن كن دقيقاً بشأن ما يوفره هذا الإعداد. تحمي أذونات الملفات هذه الملفات من الحسابات الأخرى على الخادم. ولا تحميها من plugin، لأن plugin يعمل بصفة المستخدم الذي يملك هذه الملفات، وداخل العملية التي تقرؤها. لذلك يعني إبعاد الأسرار عن متناول وكيل الذكاء الاصطناعي عدم وضعها على الجهاز أصلاً. يجب أن يحتفظ خادم dsh بمفتاح النموذج الوحيد الذي يحتاج إليه. أما بيانات اعتماد الخدمات السحابية ومفاتيح التوقيع، فيجب حفظها في مكان آخر.

لماذا يغيّر المكوّن الإضافي الذي يقرأ الويب نموذج التهديد

توفّر وصلة Web للمكوّنات الإضافية موفّري البحث والجلب. عندما يجلب مكوّن إضافي صفحة إلى جلستك، فهو يجلب نصاً يستطيع مهاجم كتابته. لا يفصل prompt النموذج بين التعليمات والبيانات، لذلك يمكن أن تحتوي الصفحة التي جرى جلبها على سطر موجّه إلى وكيلك، ويصبح harness الذي يملك صلاحية shell على بُعد خطوة مطيعة واحدة من تشغيله.

توجد آلية التحكم في harness بالفعل. dsh-base، وهي الحزمة الأولى في كل profile، توفّر sandbox وسياسة الموافقة. استخدمها. يجب أن تتطلب الجلسة التي تستطيع جلب صفحات غير موثوقة موافقة على أي إجراء يكتب أو ينفّذ، حتى لا تتحول التعليمات التي جرى جلبها إلى إجراء من تلقاء نفسها. يشرح وضع إجراءات الوكيل خلف الموافقات كيفية تحديد موضع هذا الحد. تسري العلاقة في الاتجاهين أيضاً، لأن خادمك نفسه صفحة سيجلبها وكيل شخص آخر، وهذا هو موضوع حظر برامج زحف الذكاء الاصطناعي على خادمك.

كيف تتحقق مما غيّره plugin؟

أنشئ snapshot قبل التثبيت، ثم ثبّت plugin، وأنشئ snapshot بعده، ثم اقرأ الفرق.

dsh --profile web --dump-config > /tmp/dsh-before.txt
dsh plugin --profile web add '<package-name>@<version>'
dsh --profile web --dump-config > /tmp/dsh-after.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after.txt

يوضح diff إدخالات plugin التي أضافها التثبيت إلى الشجرة المركّبة. إذا ثبّتَّ plugin لميزة صغيرة واحدة، لكنه أضاف عدة إدخالات لا تستطيع تفسيرها، فتوقّف واقرأ المصدر قبل تشغيله. يجيب dsh plugin --profile web why <package-name> عن السؤال الآخر: أيّ من تبعياتك المباشرة جلب حزمة معيّنة.

تُثبَّت الحزم ضمن $DSH_HOME/profiles/node_modules، لذلك يمكنك أيضاً فحص الشجرة على القرص:

ls ~/.dsh/profiles/node_modules

احتفظ بملف تعريف ثانٍ لا تُجري فيه أي تجارب. إذا أدى تثبيت إلى تعطيل بيئة الاختبار، فإن تشغيل dsh --profile <clean-name> يوضح خلال ثوانٍ ما إذا كان plugin هو السبب.

كيفية إزالة إضافة dsh؟

dsh plugin --profile web remove '<package-name>'
dsh --profile web --dump-config > /tmp/dsh-after-removal.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after-removal.txt

لا تؤدي إزالة الاعتمادية دائماً إلى إزالة الإعدادات. تبقى الإدخالات المكتوبة في cordis.patch.yml الخاص بالملف التعريفي في مكانها، لأن هذا الملف ملكك ولن يعيد الـharness كتابته نيابةً عنك. افتحه واحذف أي كتلة تذكر الحزمة التي أزلتها.

less ~/.dsh/profiles/web/cordis.patch.yml

ثم عالج الجزء الذي لا يمكن لأي أمر إزالة تثبيت إصلاحه. إذا أزلت إضافة لأنك لم تعد تثق بها، فقد قرأت بالفعل كل ما كان بإمكانها قراءته. دوّر مفتاح DeepSeek API في وحدة تحكم المزوّد، ودوّر أي بيانات أخرى كانت موجودة في $DSH_HOME. ثم حدّد الموارد التي كان بإمكان حساب unix الذي شغّلها الوصول إليها على بقية شبكتك.

النسخة المختصرة

• اقرأ tarball المنشور قبل التثبيت، بدءاً من scripts وملف الإدخال
• ثبّت الإصدار المحدد بدقة، أو commit المحدد بدقة في مواصفة git، واحتفظ بملف القفل
• ثبّت في profile واحد، واحتفظ بـprofile نظيف يمكنك الإقلاع إليه عند حدوث مشكلة
• اعرض الفروقات في --dump-config قبل كل عملية تثبيت وبعدها
• شغّل harness كمستخدم unix مستقل، على loopback، وتصل إليه عبر SSH
• احتفظ بمفتاح API واحد على الخادم، وبدّله في اليوم الذي تزيل فيه plugin لم تعد تثق بها

لا يبرر أي من ذلك تجنّب plugins. إن نموذج plugins هو سبب فائدة dsh، كما أن harness الذي لا يمكنك توسيعه هو harness ستستبدله. السبب هو أن تعرف ما ثبّتَه، ومن أي جهة، وبأي إصدار، وأن تشغّل المنظومة كاملة في مكان يمكنك إعادة بنائه.

FAQ

هل يعزل dsh الإضافات عن بعضها؟

لا. تُحمَّل الإضافة في عملية harness عبر Cordis، ويمكنها الوصول إلى نقاط القدرات الموثقة، بما في ذلك shell وfilesystem وweb وsubprocess وsubagent وcredentials. dsh-base، وهي الحزمة الأولى في كل profile، توفّر سياسة العزل والموافقة التي تحدد ما يمكن لأدوات الوكيل تنفيذه، وهذه السياسة هي مصدر الحماية لديك. لا يوجد حد صلاحيات مستقل لكل إضافة، لذلك فإن النموذج الدقيق هو أن تثبيت إضافة يوسّع نطاق ثقتك ليشمل مؤلفها وكل حزمة في شجرة تبعياتها.

هل يمكنني تثبيت إضافة dsh من دون تشغيل نصوص تثبيتها؟

يحظر pnpm 10 والإصدارات الأحدث نصوص بناء التبعيات افتراضياً، وdsh plugin ... add يمرر الطلبات إلى pnpm. لذلك، في إصدار pnpm حديث، لا يشغّل التثبيت نصوص الحزم ما لم توافق على تلك الحزمة. تحقّق من الإصدار باستخدام pnpm --version. هذا لا يجعل الإضافة غير المقروءة آمنة. تعمل شيفرة الإضافة نفسها عند الإقلاع التالي لأن harness يحمّلها عمداً، ولا يؤثر أي تقييد وقت التثبيت في ذلك.

أين توجد إضافات dsh وإعداداتها فعلياً؟

يكون $DSH_HOME مضبوطاً افتراضياً على ~/.dsh. توجد profiles في $DSH_HOME/profiles/<name>، ويحتوي كل منها على package.json مع تبعيات إضافاته، بالإضافة إلى بيان dsh.profile للحزم المرتبة، وطبقة التصحيح cordis.patch.yml. تُثبَّت الحزم تحت $DSH_HOME/profiles/node_modules. توجد المفاتيح في $DSH_HOME/.credentials.yaml، وقيم البيئة في $DSH_HOME/.env، ويُطبَّق $DSH_HOME/cordis.patch.yml على مستوى home فوق كل profile. شغّل dsh --profile web --dump-config لعرض النتيجة المركبة من دون الإقلاع.

هل التثبيت من سوق إضافات dsh آمن؟

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