SSD Nodes Learn 🎉 VPS dès $5.50/mois
Guides Matt ConnorPar Matt Connor · Mis à jour le 2026-08-21

Résoudre les erreurs d’installation et de version de dsh

Toutes les versions de DeepSeek Harness sont des release candidates. Épinglez une version dsh, videz le cache npx et vérifiez le npm fourni avec Node.js.

Ce qu’est réellement l’installation de DeepSeek Harness

L’installation de DeepSeek Harness tient en une commande : npx @deepseek-ai/dsh web. Il n’y a pas d’installateur ni de service à configurer. La plupart des problèmes rencontrés ne concernent pas l’installation. Ils concernent la résolution de version : quelle version de @deepseek-ai/dsh npx a décidé d’exécuter aujourd’hui, et si votre version de Node.js peut l’exécuter.

Deux faits déterminent tout ce qui suit. Premièrement, toutes les versions de @deepseek-ai/dsh publiées sur npm jusqu’à présent sont des release candidates, et le tag latest pointe vers l’une d’elles. Au 18 août 2026, il s’agit de 0.1.0-rc.7, publiée le 17 août 2026. Deuxièmement, le README du projet indique que le harness est en developer preview, qu’il évolue rapidement et que des changements incompatibles sont prévus. Une option qui fonctionnait la semaine dernière peut avoir disparu cette semaine. Épinglez une version avant de construire quoi que ce soit dessus.

Commençons par quelques termes. dsh est l’outil en ligne de commande DeepSeek Harness. Node.js est le runtime JavaScript dont il a besoin. npx est le package runner fourni avec npm (node package manager). Il récupère un package à la demande au lieu de l’installer de manière permanente.

De quelle version de Node.js dsh a-t-il besoin ?

La racine du dépôt package.json déclare "engines": {"node": "^22.19.0 || >=24.0.0"}, qui indiquait la version 0.1.0-rc.7 le 18 August 2026. Il faut donc Node 22.19.0 ou une version ultérieure de la branche 22, ou Node 24 et versions ultérieures. Node 20 n’est pas pris en charge.

Vérifiez d’abord la version installée.

node -v
npm -v

C’est ici que le comportement peut surprendre. Le package @deepseek-ai/dsh publié ne contient pas son propre champ engines. Seule la racine du monorepo en déclare un, et ce fichier racine n’est jamais publié sur npm. npm n’a donc rien à vérifier : il n’affiche aucun avertissement EBADENGINE et ne refuse rien. Avec Node 20, l’installation semble avoir réussi. L’échec survient plus tard, lorsque le code chargé utilise une syntaxe ou une API absente de votre runtime. Il n’existe pas de message d’erreur unique et stable à rechercher, car la première ligne en échec dépend du premier module chargé. Consultez plutôt node -v que le crash.

Si votre version de Node est trop ancienne, nvm (node version manager) est la solution la moins invasive sur un VPS. Il s’installe dans votre répertoire personnel et ne modifie pas le Node du système.

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 doit maintenant afficher une version commençant par v24.. Si le shell affiche encore l’ancienne version, la fonction shell de nvm n’a pas été chargée. Ouvrez alors un nouveau shell de connexion et réessayez. Node 24.19.0 est la version LTS (long term support) active en August 2026. C’est aussi la meilleure cible pour une deuxième raison expliquée plus bas.

Pourquoi npx exécute-t-il une version différente chaque jour ?

npx @deepseek-ai/dsh web n’indique aucune version. npx demande donc au registry vers quelle version pointe le tag latest. Ce tag évolue. Lorsque DeepSeek publie 0.1.0-rc.8, la commande enregistrée dans vos notes commence à exécuter un code différent, sans vous demander confirmation et sans changelog affiché.

Vous pouvez inspecter chaque élément depuis la ligne de commande.

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

dist-tags indique vers quelle version pointe actuellement latest. Le 18 août 2026, latest et next pointaient tous deux vers 0.1.0-rc.7. Il n’existe donc pas de canal stable distinct vers lequel basculer. La liste versions est plus intéressante, car elle comporte des trous : 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. Certains release candidates n’ont jamais été publiés, ce qui explique les numéros manquants dans cette séquence. Si vous devinez le prochain -rc.N dans un script de déploiement, celui-ci échouera. Lisez donc la liste au lieu d’incrémenter les numéros.

Pourquoi npx continue-t-il d’utiliser une ancienne version ?

C’est la plainte inverse, et les deux comportements sont possibles selon la version de npm utilisée.

npx possède son propre répertoire de packages, distinct du cache des tarballs, dans un dossier nommé _npx à l’intérieur du cache npm. Affichez son chemin et examinez-le.

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

Pendant des années, npx a réutilisé ce qu’il trouvait à cet emplacement pour un nom de package simple, sans interroger de nouveau le registry. npm 11.2.0 a changé ce comportement. Lorsque la spécification est un nom simple ou une plage de versions, npx récupère maintenant le manifest et ne réutilise la copie en cache que si le tarball résolu correspond à celui que le registry vient de renvoyer.

Le comportement obtenu dépend de votre version de Node, car Node intègre une version précise de npm :

  • Node 20.20.2 intègre npm 10.8.2.
  • Node 22.19.0 intègre npm 10.9.3.
  • Node 22.23.2, la version 22 la plus récente, intègre npm 10.9.8.
  • Node 24.19.0 intègre npm 11.17.0.

Toute la branche Node 22, officiellement prise en charge par le harness, intègre donc une version de npm antérieure à 11.2.0. Avec Node 22, un npx @deepseek-ai/dsh web simple continue d’exécuter la release candidate mise en cache il y a plusieurs semaines. Avec Node 24, la même commande résout de nouveau la version à chaque exécution. Une seule commande, deux comportements, et aucun avertissement. Demandez à l’outil quelle version il utilise :

npx @deepseek-ai/dsh --version

Vider le cache npx

Avec npm 11.2.0 et les versions ultérieures, des sous-commandes dédiées sont disponibles.

npm cache npx ls
npm cache npx rm --force

Sans --force, npm refuse de tout supprimer et affiche Please use --force to remove entire npx cache. Utilisez d’abord npm cache npx ls lorsque vous voulez supprimer une entrée par sa clé plutôt que toutes les entrées.

Avec npm 10, ces sous-commandes n’existent pas. Supprimez donc vous-même le répertoire.

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

npm cache clean --force n’est d’aucune utilité ici. Cette commande vide _cacache, le stockage des tarballs, mais laisse _npx intact. Cette séparation explique précisément pourquoi npm a ensuite ajouté les sous-commandes npm cache npx. Vider _npx n’a aucune conséquence permanente : ce répertoire contient les packages téléchargés, tandis que l’état de votre harness se trouve sous $DSH_HOME/profiles/<name> et n’est pas modifié.

Comment épingler une release candidate exacte ?

Indiquez la chaîne de version complète, y compris la partie -rc.N.

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

--yes est important dans un script, car npx affiche sinon une invite avant d’installer un package qu’il n’a pas encore rencontré, puis attend une réponse qui ne vient jamais.

Une version exacte est également la solution la plus rapide. npx base le répertoire de cache sur la chaîne de spécification saisie. Pour une version exacte, il compare cette chaîne à l’identifiant du package déjà installé dans ce répertoire et l’exécute sans aucun aller-retour vers le registry. Avec npm 11.2.0 et les versions ultérieures, un nom seul entraîne une récupération du manifest à chaque démarrage.

Une installation globale utilise le même principe et fournit une commande courte.

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

Aucune version correspondante trouvée pour @deepseek-ai/dsh@^0.1.0

Une plage avec caret ou tilde ne correspond pas à ce package. npm install -g @deepseek-ai/dsh@^0.1.0 répond avec le code d’erreur ETARGET et la ligne No matching version found for @deepseek-ai/dsh@^0.1.0. Le registry fonctionne correctement. Il s’agit d’une règle semver : une plage de versions ne correspond pas à une version prerelease, sauf si la plage désigne elle-même une prerelease. Chaque build publiée de ce package est -rc.N, c’est-à-dire une prerelease, et ^0.1.0 ne correspond donc à rien. Indiquez la version exacte.

Cette règle a aussi un effet utile. Comme les plages ne peuvent pas dériver vers une nouvelle release candidate, il n’existe pas d’état partiellement épinglé à gérer. Vous utilisez soit une version exacte, soit un tag susceptible d’évoluer.

Faut-il utiliser npx ou installer dsh globalement ?

Utilisez npx pour un premier test, car il ne laisse rien derrière lui, à l’exception d’un répertoire de cache que vous savez maintenant supprimer. Utilisez une installation globale avec une version figée pour tout ce qui doit continuer à fonctionner après un redémarrage, par exemple un agent de codage que vous laissez fonctionner sur un VPS.

Les deux peuvent produire des résultats différents sur un serveur où vous avez utilisé les deux. Comparez-les.

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

which dsh ne rien trouver juste après une installation globale réussie signifie presque toujours que le répertoire global des binaires de npm est absent de votre PATH. Exécutez npm prefix -g pour afficher la racine. Les binaires se trouvent dans le répertoire bin situé dessous.

Un point important concernant la sécurité : npx télécharge et exécute du code depuis le registre chaque fois qu’il résout un nouvel élément. Sur un serveur, il s’agit d’une véritable exposition, pas d’un risque théorique. Figer les versions fait partie de la solution. Le reste est expliqué dans la manière dont les attaques de la chaîne logistique npm atteignent un serveur.

Ce que signifie une version préliminaire pour la reproductibilité

0.1.0-rc.6 a été publiée le 13 août 2026 et 0.1.0-rc.7 le 17 août 2026. Quatre jours d’écart. À ce rythme, des instructions rédigées il y a un mois peuvent décrire une ligne de commande qui n’existe déjà plus, y compris cette page. Datez chaque affirmation de version que vous consignez, y compris dans vos propres notes.

Deux habitudes permettent de travailler avec une version préliminaire. Épinglez la version exacte dans chaque commande et chaque script afin que la reconstruction d’un serveur produise le même environnement de test. Lisez ensuite la sortie de l’aide depuis la version épinglée, plutôt que depuis un guide.

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

La seconde moitié de la reproductibilité concerne le profil. dsh --profile <name> démarre avec le profil stocké dans $DSH_HOME/profiles/<name>, et les profils web et headless sont créés à partir des modèles fournis lors de leur première utilisation. Ce répertoire contient également les paramètres de sa clé d’API, de son modèle et de son endpoint, que l’environnement de test lit. Une version épinglée et une configuration fonctionnelle sont donc deux éléments distincts à configurer correctement. Les bundles intégrés sont résolus depuis l’installation de dsh actuellement exécutée. Modifier la version épinglée modifie donc aussi ces bundles. Les plugins externes se comportent différemment. Ils résident dans le répertoire du profil, et dsh plugin --profile <name> add <package> transmet ses arguments à pnpm pour les installer. pnpm doit donc être présent dans votre PATH, et dsh l’indique clairement lorsqu’il ne l’est pas. Le propre package.json du profil épingle ces plugins. Un épinglage complet couvre donc deux fichiers, et non un seul.

Cette séparation vous semblera familière si vous avez maintenu des outils Python dans des environnements isolés sur un serveur : l’outil et les éléments que vous lui ajoutez sont épinglés à des endroits distincts. Une fois l’environnement de test démarré, la question suivante concerne généralement le réseau plutôt que les versions. C’est là qu’interviennent l’accès à l’interface Web de dsh sur un VPS distant et le guide détaillé Installer DeepSeek Harness sur un VPS.

Erreurs d’arguments que vous rencontrerez réellement

Ces erreurs viennent de l’analyseur de la CLI lui-même. Elles restent donc stables dans la série des release candidates, et chacune indique précisément le problème.

error: --profile <name> is required

Vous avez exécuté npx @deepseek-ai/dsh sans sous-commande ni profil. La commande seule démarre un profil et nécessite donc un nom. dsh web est la sous-commande qui n’accepte aucun --profile, car elle démarre à votre place le profil web fourni.

error: --patch needs a path

Vous avez indiqué --patch sans rien ajouter après. Cette option peut être répétée, et chaque occurrence doit être suivie du chemin d’un fichier.

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

Choisissez-en une seule. --dump-default-config affiche les couches du bundle fourni et n’accepte aucun --patch. --dump-config affiche la configuration composée d’un profil. Ces deux options affichent le résultat puis quittent le programme sans démarrer le harness. Elles constituent donc la méthode sûre pour voir les modifications introduites par une nouvelle release candidate.

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

Vous avez indiqué dsh plugin --profile <name> sans rien à transmettre. Lorsque le profil est absent, la sous-commande l’initialise, puis transmet le reste de la ligne de commande à pnpm. Elle nécessite donc des arguments tels que add @scope/dsh-plugin-example.

FAQ

De quelle version de Node.js DeepSeek Harness a-t-il besoin ?

Le dépôt déclare ^22.19.0 || >=24.0.0 dans son fichier racine package.json, consulté le 18 August 2026 à la version 0.1.0-rc.7. Il faut donc Node 22.19.0 ou une version ultérieure de la branche 22, ou Node 24 et les versions suivantes. Node 20 ne fonctionnera pas. Le package npm publié ne possède pas son propre champ engines. npm ne vous avertit donc pas et ne bloque pas l’installation ; l’échec apparaît à l’exécution. Vérifiez d’abord node -v. Node 24 reste le meilleur choix, car il intègre npm 11, qui corrige la réutilisation des versions par npx.

Comment forcer npx à utiliser la dernière version de dsh au lieu d’une version mise en cache ?

Avec npm 11.2.0 et les versions suivantes, npx @deepseek-ai/dsh vérifie déjà le registry à chaque exécution pour un simple nom de package. Ce n’est pas le cas avec npm 10, fourni avec toutes les versions de Node 22. Videz le cache npx avec npm cache npx rm --force sous npm 11, ou supprimez le dossier avec rm -rf "$(npm config get cache)/_npx" sous npm 10. Vérifiez ensuite avec npx @deepseek-ai/dsh --version. Notez que npm cache clean --force vide un autre répertoire et ne résoudra pas ce problème.

Pourquoi l’installation de @deepseek-ai/dsh@^0.1.0 échoue-t-elle ?

npm renvoie le code d’erreur ETARGET avec la ligne No matching version found for @deepseek-ai/dsh@^0.1.0.. Toutes les builds publiées sont des préversions, comme 0.1.0-rc.7, et une plage semver ne correspond pas aux versions de préversion, sauf si la plage en mentionne elle-même une. Installez la chaîne de version exacte, suffixe -rc.N inclus. Exécutez npm view @deepseek-ai/dsh versions --json pour voir quelles versions existent, car la séquence comporte des trous lorsque des release candidates n’ont jamais été publiées.

Dois-je installer dsh globalement ou l’exécuter avec npx ?

npx convient pour une première prise en main, car rien ne persiste à part un répertoire de cache. Une installation globale avec version figée, comme npm install -g @deepseek-ai/dsh@0.1.0-rc.7, convient à tout ce qui doit continuer à fonctionner, car la version ne change que lorsque vous la modifiez. Si la commande dsh est introuvable après une installation globale, le répertoire bin global de npm est absent de votre PATH, et npm prefix -g affiche la racine sous laquelle il se trouve.

DeepSeek Harness est-il suffisamment stable pour servir de base à un projet ?

Pas encore, d’après sa propre description. Le README indique que le projet est en developer preview, qu’il évolue rapidement et qu’il connaîtra des changements rompant la compatibilité. Les release candidates 0.1.0-rc.6 et 0.1.0-rc.7 ont été publiées à quatre jours d’intervalle en August 2026. Épinglez une version exacte et consultez --help pour cette build figée plutôt que n’importe quel guide. Datez vos propres notes afin de pouvoir déterminer à quel point elles sont devenues obsolètes.