DeepSeek Harness इंस्टॉलेशन और वर्ज़न एरर कैसे ठीक करें

DeepSeek Harness इंस्टॉलेशन वास्तव में क्या है

DeepSeek Harness इंस्टॉलेशन केवल एक कमांड है: npx @deepseek-ai/dsh web। इसमें कोई इंस्टॉलर नहीं है और कॉन्फ़िगर करने के लिए कोई सर्विस नहीं है। लोग जिन समस्याओं का सामना करते हैं, उनमें से अधिकांश इंस्टॉलेशन से संबंधित नहीं होती हैं। यह वर्ज़न रिज़ॉल्यूशन (version resolution) की समस्या है: npx ने आज @deepseek-ai/dsh का कौन सा बिल्ड चलाने का निर्णय लिया है, और क्या आपका Node.js वर्ज़न उसे चलाने में सक्षम है।

नीचे दी गई हर बात दो तथ्यों पर आधारित है। पहला, npm पर अब तक प्रकाशित @deepseek-ai/dsh का प्रत्येक वर्ज़न एक रिलीज़ कैंडिडेट है, और latest टैग उनमें से किसी एक की ओर इशारा करता है। 18 अगस्त 2026 तक, यह 0.1.0-rc.7 है, जिसे 17 अगस्त 2026 को प्रकाशित किया गया था। दूसरा, प्रोजेक्ट README में कहा गया है कि यह हार्नेस डेवलपर प्रीव्यू में है, इसमें तेज़ी से बदलाव हो रहे हैं, और इसमें ऐसे बदलाव होंगे जो पुरानी संगतता (compatibility) को तोड़ देंगे। जो फ्लैग पिछले सप्ताह काम कर रहा था, वह इस सप्ताह हट सकता है। इस पर कुछ भी बनाने से पहले एक वर्ज़न को पिन (pin) करें।

पहले कुछ शब्दों को समझें। dsh, DeepSeek Harness कमांड लाइन टूल है। Node.js वह JavaScript रनटाइम है जिसकी इसे आवश्यकता होती है। npx वह पैकेज रनर है जो npm (node package manager) के साथ आता है, और यह किसी पैकेज को स्थायी रूप से इंस्टॉल करने के बजाय मांग पर उसे फेच (fetch) करता है।

dsh को Node.js के किस version की आवश्यकता है?

Repository के root package.json में "engines": {"node": "^22.19.0 || >=24.0.0"} घोषित है, जिसे 18 August 2026 को version 0.1.0-rc.7 पर पढ़ा गया था। इसलिए Node 22.19.0 या 22 line के भीतर का कोई भी नया version, या Node 24 और उससे ऊपर का version आवश्यक है। Node 20 समर्थित नहीं है।

किसी भी अन्य कार्य से पहले यह जाँच लें कि आपके पास कौन सा version है।

node -v
npm -v

यहाँ वह हिस्सा है जो लोगों को हैरान करता है। प्रकाशित @deepseek-ai/dsh package में अपना कोई engines field नहीं होता है। केवल monorepo root ही एक field घोषित करता है, और वह root file कभी भी npm पर प्रकाशित नहीं होती है। इसलिए npm के पास जाँचने के लिए कुछ नहीं होता, इसलिए यह कोई EBADENGINE warning print नहीं करता और किसी भी चीज़ को अस्वीकार नहीं करता है। Node 20 पर install ऐसा लगता है जैसे सफल रहा, और विफलता बाद में आती है, जब load किया गया code ऐसी syntax या API को छूता है जो आपके runtime में मौजूद नहीं है। खोजने के लिए कोई एक स्थिर error string नहीं है, क्योंकि कौन सी line पहले विफल होगी, यह इस पर निर्भर करता है कि कौन सा module पहले load होता है। crash को पढ़ने के बजाय node -v पढ़ें।

यदि आपका Node बहुत पुराना है, तो VPS पर nvm (node version manager) सबसे कम हस्तक्षेप करने वाला समाधान है, क्योंकि यह आपके home directory के अंतर्गत install होता है और system Node को प्रभावित नहीं करता है।

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash
exec $SHELL -l
nvm install 24
nvm use 24
node -v

node -v को अब v24. से शुरू होने वाला version print करना चाहिए। यदि shell अभी भी पुराने version की रिपोर्ट करता है, तो nvm shell function load नहीं हुआ था, इसलिए एक नया login shell खोलें और पुनः प्रयास करें। August 2026 तक Node 24.19.0 सक्रिय LTS (long term support) release है, और यह नीचे बताए गए दूसरे कारण से एक बेहतर लक्ष्य है।

npx हर दिन अलग version क्यों चलाता है?

npx @deepseek-ai/dsh web में कोई version निर्दिष्ट नहीं है, इसलिए npx registry से वह version मांगता है जिस पर latest tag इंगित करता है। वह tag बदलता रहता है। जब DeepSeek 0.1.0-rc.8 publish करता है, तो आपके notes में मौजूद command अलग code चलाने लगती है, बिना किसी prompt या changelog के।

आप command line से हर गतिशील हिस्से की जांच कर सकते हैं।

npm view @deepseek-ai/dsh dist-tags
npm view @deepseek-ai/dsh versions --json
npm view @deepseek-ai/dsh time --json

dist-tags दिखाता है कि इस समय latest कहाँ इंगित कर रहा है। 18 August 2026 को latest और next दोनों 0.1.0-rc.7 पर इंगित कर रहे थे, इसलिए स्विच करने के लिए कोई अलग stable channel उपलब्ध नहीं है। versions सूची अधिक महत्वपूर्ण है, क्योंकि इसमें अंतराल हैं: 0.0.1-rc.1, 0.0.1-rc.2, 0.0.1-rc.5, 0.1.0-rc.2, 0.1.0-rc.3, 0.1.0-rc.6, 0.1.0-rc.7। उस अनुक्रम में कुछ संख्याएं गायब हैं क्योंकि कुछ release candidates कभी publish ही नहीं किए गए थे। deploy script में अगले -rc.N का अनुमान लगाना विफल रहेगा, इसलिए गिनती करने के बजाय सूची को पढ़ें।

npx पुराना वर्ज़न क्यों चलाता रहता है?

यह पिछली शिकायत के विपरीत है, और npm के वर्ज़न के आधार पर दोनों ही बातें सच हैं।

npx अपनी खुद की package directory रखता है, जो tarball cache से अलग होती है। यह npm cache के अंदर _npx नामक फोल्डर में स्थित होती है। इसका पाथ प्रिंट करें और इसे देखें।

npm config get cache
ls "$(npm config get cache)/_npx"

सालों तक npx किसी भी bare package name के लिए वहां जो कुछ भी मिलता था, उसे ही दोबारा इस्तेमाल करता था और registry से कभी नहीं पूछता था। npm 11.2.0 ने इसे बदल दिया। जब spec एक bare name या version range होता है, तो npx अब manifest को fetch करता है और cached copy का उपयोग तभी करता है जब resolved tarball वही हो जो registry ने अभी-अभी लौटाया है।

आपको कौन सा व्यवहार मिलेगा, यह आपके Node release पर निर्भर करता है, क्योंकि Node एक विशिष्ट npm को बंडल करता है:

• Node 20.20.2 में npm 10.8.2 बंडल होता है।
• Node 22.19.0 में npm 10.9.3 बंडल होता है।
• Node 22.23.2, जो सबसे नया 22 release है, में npm 10.9.8 बंडल होता है।
• Node 24.19.0 में npm 11.17.0 बंडल होता है।

इसलिए पूरी Node 22 लाइन, जिसे harness आधिकारिक तौर पर सपोर्ट करता है, 11.2.0 से पुराना npm प्रदान करती है। Node 22 पर एक bare npx @deepseek-ai/dsh web उस release candidate को चलाता रहेगा जिसे उसने हफ्तों पहले cache किया था। Node 24 पर वही कमांड हर बार फिर से resolve करती है। एक कमांड, दो व्यवहार, और कोई भी आपको चेतावनी नहीं देता। टूल से पूछें कि वह क्या है:

npx @deepseek-ai/dsh --version

npx cache को साफ़ करना

npm 11.2.0 और उसके बाद के वर्ज़न में समर्पित subcommands मौजूद हैं।

npm cache npx ls
npm cache npx rm --force

--force के बिना, npm सब कुछ हटाने से मना कर देता है और Please use --force to remove entire npx cache प्रिंट करता है। जब आप सभी के बजाय किसी एक entry को key के आधार पर हटाना चाहते हैं, तो पहले npm cache npx ls का उपयोग करें।

npm 10 में ये subcommands मौजूद नहीं हैं, इसलिए directory को खुद डिलीट करें।

rm -rf "$(npm config get cache)/_npx"

npm cache clean --force यहाँ मदद नहीं करता है। यह _cacache (tarball store) को साफ़ करता है, और _npx को वैसे ही छोड़ देता है। यही अलगाव कारण है कि npm ने बाद में npm cache npx subcommands जोड़े। _npx को साफ़ करने से आपका कोई स्थायी नुकसान नहीं होता: इसमें केवल डाउनलोड किए गए पैकेज होते हैं, जबकि आपका harness state $DSH_HOME/profiles/<name> के अंतर्गत रहता है और सुरक्षित रहता है।

मैं किसी सटीक release candidate को कैसे पिन करूँ?

पूरा version string लिखें, जिसमें -rc.N वाला भाग भी शामिल हो।

npx --yes @deepseek-ai/dsh@0.1.0-rc.7 web

स्क्रिप्ट में --yes का महत्व है, क्योंकि अन्यथा npx किसी ऐसे package को install करने से पहले एक prompt दिखाता है जिसे उसने पहले नहीं देखा है, और ऐसे उत्तर की प्रतीक्षा करता है जो कभी नहीं आता।

सटीक version का उपयोग करना सबसे तेज़ तरीका भी है। npx आपके द्वारा टाइप किए गए spec string के आधार पर अपनी cache directory को key करता है, और सटीक version के लिए यह उसकी तुलना पहले से install किए गए package id से करता है और बिना किसी registry round trip के उसे चला देता है। npm 11.2.0 और उसके बाद के वर्ज़न में, केवल नाम लिखने पर हर बार start-up के समय manifest fetch करना पड़ता है।

Global install भी इसी तरह पिन होता है, और आपको एक छोटा command देता है।

npm install -g @deepseek-ai/dsh@0.1.0-rc.7
dsh --version

@deepseek-ai/dsh@^0.1.0 के लिए कोई matching version नहीं मिला

इस package के साथ caret या tilde range काम नहीं करती है। npm install -g @deepseek-ai/dsh@^0.1.0 त्रुटि कोड ETARGET और पंक्ति No matching version found for @deepseek-ai/dsh@^0.1.0. के साथ उत्तर देता है। Registry पूरी तरह ठीक है। यह एक semver नियम है: एक version range तब तक prerelease version से मेल नहीं खाती जब तक कि range स्वयं किसी prerelease का नाम न ले। इस package का प्रत्येक प्रकाशित build -rc.N है, जो कि एक prerelease है, इसलिए ^0.1.0 किसी से भी मेल नहीं खाता। सटीक version लिखें।

इस नियम का एक उपयोगी दुष्प्रभाव है। चूँकि ranges किसी नए release candidate पर नहीं जा सकतीं, इसलिए यहाँ कोई half-pinned स्थिति नहीं होती जिसके बारे में सोचना पड़े। आप या तो एक सटीक version पर होते हैं या फिर एक moving tag पर।

क्या मुझे npx का उपयोग करना चाहिए या dsh को globally install करना चाहिए?

पहली बार देखने के लिए npx का उपयोग करें, क्योंकि एक cache directory के अलावा कुछ भी पीछे नहीं छूटता जिसे आप जानते हैं कि कैसे साफ करना है। किसी भी ऐसी चीज़ के लिए जो reboot के बाद भी काम करती रहनी चाहिए, जैसे कि एक coding agent जिसे आप VPS पर चालू रखते हैं, एक pinned global install का उपयोग करें।

यदि आपने एक ही मशीन पर दोनों का उपयोग किया है, तो वे आपस में टकरा सकते हैं, इसलिए उनकी तुलना करें।

which dsh
dsh --version
npx @deepseek-ai/dsh --version

which dsh सफल global install के तुरंत बाद कुछ न मिलना लगभग हमेशा यह दर्शाता है कि npm की global bin directory आपके PATH में मौजूद नहीं है। root directory को print करने के लिए npm prefix -g चलाएँ, और binaries इसके अंतर्गत bin folder में स्थित होती हैं।

एक सुरक्षा संबंधी टिप्पणी। npx जब भी कुछ नया resolve करता है, तो वह registry से code लाता और execute करता है, जो एक सर्वर पर सैद्धांतिक के बजाय एक वास्तविक जोखिम है। Pinning इसका एक समाधान है। बाकी जानकारी npm supply chain attacks सर्वर तक कैसे पहुँचते हैं में दी गई है।

Developer preview का reproducibility के लिए क्या अर्थ है

0.1.0-rc.6 को 13 August 2026 को और 0.1.0-rc.7 को 17 August 2026 को प्रकाशित किया गया था। इनमें चार दिनों का अंतर है। इस गति से, एक महीने पहले लिखे गए निर्देश ऐसे command line का वर्णन कर सकते हैं जो अब मौजूद नहीं है, और इसमें यह पृष्ठ भी शामिल है। अपने द्वारा लिखे गए प्रत्येक version दावे की तारीख लिखें, जिसमें आपके स्वयं के नोट्स भी शामिल हैं।

दो आदतें preview को सुरक्षित बनाती हैं। प्रत्येक command और प्रत्येक script में सटीक version को pin करें, ताकि सर्वर को फिर से बनाने पर वही harness प्राप्त हो। फिर किसी भी guide के बजाय, pinned build से प्राप्त help output को पढ़ें।

npx @deepseek-ai/dsh@0.1.0-rc.7 --help
npx @deepseek-ai/dsh@0.1.0-rc.7 web --dump-config

Reproducibility का दूसरा भाग profile है। dsh --profile <name>, $DSH_HOME/profiles/<name> पर संग्रहीत profile को boot करता है, और web तथा headless profiles पहली बार उपयोग किए जाने पर shipped templates से स्वयं को बनाते हैं। वह directory वह स्थान भी है जहाँ harness अपनी API key, model, और endpoint settings को पढ़ता है, इसलिए एक pinned version और एक कार्यशील configuration, सही करने के लिए दो अलग-अलग चीजें हैं। In-box bundles वर्तमान में चल रहे dsh installation से resolve होते हैं, जिसका अर्थ है कि अपने pinned version को बदलने से वे bundles भी बदल जाते हैं। Out-of-tree plugins अलग तरह से व्यवहार करते हैं। वे profile directory में रहते हैं, और dsh plugin --profile <name> add <package> उन्हें install करने के लिए अपने arguments को pnpm को forward करता है। इसलिए pnpm का आपके PATH पर होना आवश्यक है, और जब ऐसा नहीं होता है तो dsh इसे स्पष्ट रूप से बताता है। Profile की अपनी package.json ही उन plugins को pin करती है, इसलिए एक पूर्ण pin में दो files शामिल होती हैं, न कि एक।

यदि आपने Python tools को सर्वर पर isolated environments में रखा है, तो यह विभाजन आपको परिचित लगेगा: tool और उसमें जो चीजें आप जोड़ते हैं, उन्हें अलग-अलग स्थानों पर pin किया जाता है। एक बार जब harness शुरू हो जाता है, तो अगला प्रश्न आमतौर पर versions के बजाय networking का होता है, जहाँ remote VPS पर dsh Web UI तक पहुँचना और VPS पर DeepSeek Harness install करना में दिया गया विस्तृत walkthrough काम आता है।

वे तर्क त्रुटियाँ जो आपको वास्तव में दिखाई देंगी

ये त्रुटियाँ CLI के अपने पार्सर से आती हैं, इसलिए वे release candidate लाइन में स्थिर रहती हैं और प्रत्येक त्रुटि सटीक समस्या का नाम बताती है।

error: --profile <name> is required

आपने बिना किसी subcommand और बिना किसी profile के npx @deepseek-ai/dsh चलाया। bare command एक profile को बूट करता है, इसलिए इसे एक नाम की आवश्यकता होती है। dsh web वह subcommand है जिसे किसी --profile की आवश्यकता नहीं होती, क्योंकि यह आपके लिए shipped web profile को बूट करता है।

error: --patch needs a path

--patch को उसके बाद कुछ भी दिए बिना पास किया गया था। यह flag repeatable है, और प्रत्येक उपयोग एक file path लेता है।

error: --dump-config and --dump-default-config are mutually exclusive

इनमें से एक को चुनें। --dump-default-config shipped bundle layers को प्रिंट करता है और कोई --patch स्वीकार नहीं करता है। --dump-config एक profile के लिए composed configuration को प्रिंट करता है। दोनों ही harness को शुरू किए बिना प्रिंट करके exit हो जाते हैं, जो यह देखने का सुरक्षित तरीका है कि एक नया release candidate आपके लिए क्या बदलाव लाया है।

error: plugin needs pnpm arguments to forward (e.g. add <package>)

dsh plugin --profile <name> को आगे भेजने के लिए कुछ भी नहीं दिया गया था। जब subcommand गायब होता है तो यह profile को initialize करता है, फिर command line के बाकी हिस्से को pnpm को सौंप देता है, इसलिए इसे add @scope/dsh-plugin-example जैसे तर्कों की आवश्यकता होती है।

FAQ

DeepSeek Harness को Node.js के किस version की आवश्यकता है?

Repository अपने root package.json में ^22.19.0 || >=24.0.0 घोषित करती है, जिसे 18 August 2026 को version 0.1.0-rc.7 पर पढ़ा गया था। इसलिए Node 22.19.0 या 22 line का बाद का version, या Node 24 और उससे नए versions की आवश्यकता है। Node 20 काम नहीं करेगा। प्रकाशित npm package में अपना कोई engines field नहीं है, इसलिए npm आपको कभी चेतावनी नहीं देता और install को कभी नहीं रोकता, और विफलता runtime पर दिखाई देती है। सबसे पहले node -v की जाँच करें। वैसे भी Node 24 बेहतर विकल्प है, क्योंकि इसमें npm 11 शामिल है, जो npx version reuse की समस्या को ठीक करता है।

मैं npx को cached version के बजाय सबसे नया dsh इस्तेमाल करने के लिए कैसे बाध्य करूँ?

npm 11.2.0 और उससे नए versions पर, npx @deepseek-ai/dsh हर बार run करने पर bare package name के लिए registry की दोबारा जाँच करता है। npm 10 पर, जो हर Node 22 release के साथ आता है, ऐसा नहीं होता है। npm 11 पर npm cache npx rm --force के साथ npx cache को साफ़ करें, या npm 10 पर rm -rf "$(npm config get cache)/_npx" के साथ folder को delete करें। फिर npx @deepseek-ai/dsh --version के साथ पुष्टि करें। ध्यान दें कि npm cache clean --force एक अलग directory को साफ़ करता है और इससे यह समस्या ठीक नहीं होगी।

@deepseek-ai/dsh@^0.1.0 को install करना विफल क्यों हो जाता है?

npm error code ETARGET के साथ No matching version found for @deepseek-ai/dsh@^0.1.0. line लौटाता है। हर प्रकाशित build एक prerelease है जैसे कि 0.1.0-rc.7, और एक semver range prerelease versions से मेल नहीं खाती जब तक कि range स्वयं किसी एक का नाम न ले। सटीक version string install करें, जिसमें -rc.N suffix शामिल हो। यह देखने के लिए कि कौन से versions मौजूद हैं, npm view @deepseek-ai/dsh versions --json चलाएँ, क्योंकि sequence में ऐसे अंतराल हैं जहाँ release candidates कभी प्रकाशित नहीं किए गए थे।

क्या मुझे dsh को globally install करना चाहिए या npx के माध्यम से चलाना चाहिए?

npx पहली बार देखने के लिए उपयुक्त है, क्योंकि cache directory के अलावा कुछ भी persist नहीं रहता है। npm install -g @deepseek-ai/dsh@0.1.0-rc.7 जैसा एक pinned global install उन चीजों के लिए उपयुक्त है जिन्हें काम करते रहना है, क्योंकि version तभी बदलता है जब आप इसे बदलते हैं। यदि global install के बाद dsh command नहीं मिलती है, तो npm की global bin directory आपके PATH से गायब है, और npm prefix -g उस root को print करता है जिसके अंतर्गत वह रहती है।

क्या DeepSeek Harness उस पर निर्माण करने के लिए पर्याप्त स्थिर है?

अभी तक नहीं, इसके स्वयं के विवरण के अनुसार। README बताता है कि project developer preview में है, तेजी से बदल रहा है, और इसमें compatibility तोड़ने वाले बदलाव होंगे। Release candidates 0.1.0-rc.6 और 0.1.0-rc.7 अगस्त 2026 में चार दिनों के अंतराल पर प्रकाशित किए गए थे। एक सटीक version को pin करें और किसी भी guide के बजाय उस pinned build से --help पढ़ें। अपने नोट्स पर तारीख डालें, ताकि आप बता सकें कि वे कितने पुराने हो गए हैं।