DeepSeek Harness: Installations- und Versionsfehler

Was die Installation von DeepSeek Harness tatsächlich ist

Die Installation von DeepSeek Harness besteht aus einem Befehl: npx @deepseek-ai/dsh web. Es gibt kein Installationsprogramm und keinen Dienst, der konfiguriert werden muss. Die meisten Probleme entstehen überhaupt nicht bei der Installation. Es geht um die Auflösung der Version: Welche Version von @deepseek-ai/dsh hat @deepseek-ai/dsh npx heute ausgewählt, und kann Ihre Node.js-Version sie ausführen?

Zwei Fakten sind für alle folgenden Schritte maßgeblich. Erstens ist jede bisher auf npm veröffentlichte Version von @deepseek-ai/dsh ein Release Candidate, und der Tag latest verweist auf eine dieser Versionen. Am 18 August 2026 war das 0.1.0-rc.7, veröffentlicht am 17 August 2026. Zweitens weist die README des Projekts darauf hin, dass sich das Harness in der Developer Preview befindet, schnell weiterentwickelt wird und inkompatible Änderungen enthalten wird. Ein Flag, das letzte Woche funktioniert hat, kann diese Woche bereits entfernt worden sein. Fixieren Sie eine Version, bevor Sie darauf aufbauen.

Zunächst einige Begriffe. dsh ist das Befehlszeilenwerkzeug von DeepSeek Harness. Node.js ist die dafür benötigte JavaScript-Laufzeitumgebung. npx ist der Paket-Runner, der mit npm (node package manager) ausgeliefert wird. Er ruft ein Paket bei Bedarf ab, statt es dauerhaft zu installieren.

Welche Node.js-Version benötigt dsh?

Die package.json-Datei im Stammverzeichnis des Repositorys deklariert "engines": {"node": "^22.19.0 || >=24.0.0"}. Am 18. August 2026 lautet diese Angabe 0.1.0-rc.7. Sie benötigen daher Node 22.19.0 oder höher innerhalb der 22er-Reihe oder Node 24 und höher. Node 20 wird nicht unterstützt.

Prüfen Sie zuerst Ihre vorhandene Version.

node -v
npm -v

Hier liegt der entscheidende Punkt. Das veröffentlichte @deepseek-ai/dsh-Paket enthält kein eigenes Feld engines. Nur das Root des Monorepositorys deklariert dieses Feld. Die Root-Datei wird jedoch nie bei npm veröffentlicht. npm hat daher nichts zu prüfen. Es gibt keine EBADENGINE-Warnung aus und verweigert die Installation nicht. Unter Node 20 sieht die Installation erfolgreich aus. Der Fehler tritt erst später auf, wenn der geladene Code eine Syntax oder eine API verwendet, die Ihre Laufzeitumgebung nicht unterstützt. Es gibt keine einzelne stabile Fehlermeldung, nach der Sie suchen können. Welche Zeile zuerst fehlschlägt, hängt davon ab, welches Modul zuerst geladen wird. Lesen Sie node -v, statt nur den Absturz zu analysieren.

Wenn Ihre Node-Version zu alt ist, ist nvm (node version manager) auf einem VPS die am wenigsten invasive Lösung. nvm wird in Ihrem Home-Verzeichnis installiert und lässt die Systemversion von Node unverändert.

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 sollte jetzt eine Version ausgeben, die mit v24. beginnt. Wenn die Shell weiterhin die alte Version meldet, wurde die nvm-Shell-Funktion nicht geladen. Öffnen Sie dann eine neue Login-Shell und versuchen Sie es erneut. Node 24.19.0 ist seit August 2026 das aktive LTS-Release (long term support). Es ist aus einem weiteren, weiter unten erläuterten Grund das bessere Ziel.

Warum führt npx jeden Tag eine andere Version aus?

npx @deepseek-ai/dsh web enthält keine Versionsangabe. Deshalb fragt npx die Registry ab, auf die der Tag latest aktuell zeigt. Dieser Tag kann sich ändern. Wenn DeepSeek 0.1.0-rc.8 veröffentlicht, führt der in Ihren Notizen gespeicherte Befehl plötzlich anderen Code aus. Es gibt dabei keine Rückfrage und kein Changelog, das Sie vorher sehen.

Sie können jedes bewegliche Element über die Befehlszeile prüfen.

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

dist-tags zeigt, worauf latest derzeit verweist. Am 18. August 2026 verwiesen sowohl latest als auch next auf 0.1.0-rc.7. Es gibt daher keinen separaten stabilen Kanal, auf den Sie wechseln können. Die Liste versions ist interessanter, weil sie Lücken enthält: 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. In dieser Folge fehlen Nummern, weil einige Release Candidates nie veröffentlicht wurden. Wenn Sie im Deploy-Skript den nächsten -rc.N erraten, schlägt es fehl. Lesen Sie daher die Liste, statt die Nummern hochzuzählen.

Warum führt npx weiterhin eine alte Version aus?

Das ist die entgegengesetzte Beschwerde. Beide Aussagen können zutreffen, abhängig davon, welche npm-Version Sie verwenden.

npx verwaltet ein eigenes Paketverzeichnis. Es ist vom Tarball-Cache getrennt und liegt in einem Verzeichnis namens _npx innerhalb des npm-Cache-Verzeichnisses. Geben Sie den Pfad aus und sehen Sie sich das Verzeichnis an.

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

Jahrelang verwendete npx bei einem einfachen Paketnamen alles, was es dort fand, und fragte die Registry nicht erneut ab. npm 11.2.0 hat dieses Verhalten geändert. Wenn die Spezifikation ein einfacher Name oder ein Versionsbereich ist, ruft npx jetzt das Manifest ab. Die zwischengespeicherte Kopie wird nur wiederverwendet, wenn der aufgelöste Tarball mit dem gerade von der Registry zurückgegebenen Tarball übereinstimmt.

Welches Verhalten Sie erhalten, hängt von Ihrer Node-Version ab, weil Node eine bestimmte npm-Version enthält:

• Node 20.20.2 enthält npm 10.8.2.
• Node 22.19.0 enthält npm 10.9.3.
• Node 22.23.2, die neueste Version der 22er-Reihe, enthält npm 10.9.8.
• Node 24.19.0 enthält npm 11.17.0.

Die gesamte Node-22-Reihe, die der Harness offiziell unterstützt, enthält daher eine ältere npm-Version als 11.2.0. Unter Node 22 führt ein einfacher npx @deepseek-ai/dsh web weiterhin den Release Candidate aus, den npx vor Wochen zwischengespeichert hat. Derselbe Befehl löst unter Node 24 bei jeder Ausführung die Version erneut auf. Ein Befehl, zwei Verhaltensweisen, und keines davon wird angekündigt. Fragen Sie das Tool nach seiner Version:

npx @deepseek-ai/dsh --version

npx-Cache leeren

Ab npm 11.2.0 gibt es dafür eigene Subcommands.

npm cache npx ls
npm cache npx rm --force

Ohne --force verweigert npm das vollständige Löschen und gibt Please use --force to remove entire npx cache aus. Verwenden Sie zuerst npm cache npx ls, wenn Sie einen einzelnen Eintrag anhand seines Schlüssels und nicht alle Einträge entfernen möchten.

Unter npm 10 existieren diese Subcommands nicht. Löschen Sie das Verzeichnis daher selbst.

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

npm cache clean --force hilft hier nicht. Der Befehl leert _cacache, den Tarball-Speicher, und lässt _npx unverändert. Diese Trennung ist genau der Grund, warum npm später die Subcommands npm cache npx hinzugefügt hat. Das Löschen von _npx hat außerdem keine dauerhaften Nachteile: Das Verzeichnis enthält heruntergeladene Pakete. Der Status Ihres Harness liegt unter $DSH_HOME/profiles/<name> und bleibt unverändert.

Wie pinne ich einen exakten Release Candidate?

Geben Sie die vollständige Versionszeichenfolge einschließlich des Teils -rc.N an.

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

--yes ist in einem Skript wichtig, weil npx andernfalls vor der Installation eines ihm unbekannten Pakets eine Eingabeaufforderung ausgibt und auf eine Antwort wartet, die nie kommt.

Eine exakte Version ist außerdem der schnellste Weg. npx verwendet die von Ihnen eingegebene Spec-Zeichenfolge als Schlüssel für sein Cache-Verzeichnis. Bei einer exakten Version vergleicht es diese mit der dort bereits installierten Paket-ID und führt das Paket ohne eine Registry-Anfrage aus. Ab npm 11.2.0 kostet ein bloßer Name bei jedem Start einen Abruf des Manifests.

Eine globale Installation pinnt die Version auf dieselbe Weise und bietet Ihnen einen kurzen Befehl.

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

Keine passende Version für @deepseek-ai/dsh@^0.1.0 gefunden

Ein Caret- oder Tilde-Bereich schlägt bei diesem Paket fehl. npm install -g @deepseek-ai/dsh@^0.1.0 antwortet mit dem Fehlercode ETARGET und der Zeile No matching version found for @deepseek-ai/dsh@^0.1.0. Die Registry ist in Ordnung. Das ist eine semver-Regel: Ein Versionsbereich passt nicht zu einer Prerelease-Version, wenn der Bereich nicht selbst eine Prerelease-Version angibt. Jeder veröffentlichte Build dieses Pakets ist -rc.N, also eine Prerelease-Version. Daher passt ^0.1.0 zu nichts. Schreiben Sie die exakte Version.

Diese Regel hat einen nützlichen Nebeneffekt. Da Bereiche nicht auf einen neuen Release Candidate wechseln können, gibt es keinen teilweise gepinnten Zustand, den Sie berücksichtigen müssen. Sie verwenden entweder eine exakte Version oder ein sich änderndes Tag.

Soll ich npx verwenden oder dsh global installieren?

Verwenden Sie npx für einen ersten Test, weil außer einem Cache-Verzeichnis nichts zurückbleibt und Sie nun wissen, wie Sie es löschen. Für alles, was nach einem Reboot weiterhin funktionieren muss, beispielsweise einen dauerhaft auf einem VPS laufenden Coding-Agent, verwenden Sie eine versionierte globale Installation.

Auf einem System, auf dem Sie beide Varianten verwendet haben, können sie unterschiedliche Ergebnisse liefern. Vergleichen Sie sie daher.

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

which dsh Wenn direkt nach einer erfolgreichen globalen Installation nichts gefunden wird, fehlt fast immer das globale Binärverzeichnis von npm in Ihrem PATH. Führen Sie npm prefix -g aus, um das Root-Verzeichnis auszugeben. Die Binärdateien befinden sich im Verzeichnis bin darunter.

Ein Hinweis zur Sicherheit: npx lädt Code aus der Registry herunter und führt ihn aus, sobald es etwas Neues auflöst. Auf einem Server ist das ein reales und kein theoretisches Risiko. Versionen festzulegen ist ein Teil der Lösung. Weitere Informationen finden Sie unter wie Angriffe auf die npm-Lieferkette einen Server erreichen.

Was eine Developer Preview für die Reproduzierbarkeit bedeutet

0.1.0-rc.6 wurde am 13. August 2026 veröffentlicht und 0.1.0-rc.7 am 17. August 2026. Dazwischen lagen vier Tage. Bei diesem Tempo können Anleitungen, die vor einem Monat geschrieben wurden, eine Befehlszeile beschreiben, die nicht mehr existiert. Das gilt auch für diese Seite. Datieren Sie jeden Versionshinweis, den Sie festhalten, einschließlich Ihrer eigenen Notizen.

Zwei Gewohnheiten machen den Preview-Betrieb beherrschbar. Tragen Sie die exakte Version in jeden Befehl und jedes Skript ein, damit der Wiederaufbau eines Servers denselben Harness erzeugt. Lesen Sie anschließend die Hilfeausgabe des festgelegten Builds und nicht die Angaben aus einer Anleitung.

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

Die zweite Hälfte der Reproduzierbarkeit ist das Profil. dsh --profile <name> startet das unter $DSH_HOME/profiles/<name> gespeicherte Profil. Die Profile web und headless werden bei der ersten Verwendung aus den mitgelieferten Vorlagen erstellt. In diesem Verzeichnis liest der Harness auch seine API-Key-, Modell- und Endpunkt-Einstellungen. Eine festgelegte Version und eine funktionierende Konfiguration sind daher zwei getrennte Aspekte, die korrekt eingerichtet werden müssen. Integrierte Bundles werden aus der aktuell ausgeführten dsh-Installation aufgelöst. Wenn Sie also die festgelegte Version ändern, ändern sich auch diese Bundles. Plugins außerhalb des Quellbaums verhalten sich anders. Sie liegen im Profilverzeichnis, und dsh plugin --profile <name> add <package> leitet seine Argumente an pnpm weiter, um sie zu installieren. Daher muss pnpm in Ihrem PATH enthalten sein. dsh weist ausdrücklich darauf hin, wenn dies nicht der Fall ist. Die profileigene package.json legt diese Plugins fest. Eine vollständige Festlegung umfasst daher zwei Dateien und nicht nur eine.

Diese Trennung ist vertraut, wenn Sie bereits Python-Tools in isolierten Umgebungen auf einem Server verwaltet haben: Das Tool und die hinzugefügten Komponenten werden an getrennten Stellen festgelegt. Sobald der Harness läuft, geht es normalerweise nicht mehr um Versionen, sondern um Netzwerke. Dann sind der Zugriff auf die dsh-Weboberfläche auf einem entfernten VPS und die ausführlichere Anleitung DeepSeek Harness auf einem VPS installieren relevant.

Argumentfehler, die tatsächlich auftreten

Diese Fehler stammen aus dem Parser der CLI. Sie bleiben daher innerhalb der Release-Candidate-Reihe stabil, und jeder Fehler nennt das genaue Problem.

Fehler: --profile <name> ist erforderlich

Sie haben npx @deepseek-ai/dsh ohne Subcommand und ohne Profil ausgeführt. Der Befehl ohne weitere Argumente startet ein Profil und benötigt daher einen Namen. dsh web ist das Subcommand, das kein --profile übernimmt, weil es das mitgelieferte web-Profil für Sie startet.

Fehler: --patch benötigt einen Pfad

--patch wurde ohne nachfolgenden Wert übergeben. Das Flag kann wiederholt werden. Jede Angabe benötigt einen Dateipfad.

Fehler: --dump-config und --dump-default-config schließen sich gegenseitig aus

Wählen Sie eines der beiden Flags. --dump-default-config gibt die Ebenen des mitgelieferten Bundles aus und akzeptiert kein --patch. --dump-config gibt die zusammengesetzte Konfiguration für ein Profil aus. Beide Befehle geben die Ausgabe aus und beenden sich, ohne den Harness zu starten. Dadurch können Sie sicher prüfen, was sich unter Ihnen in einem neuen Release Candidate geändert hat.

Fehler: Das Plugin benötigt weiterzuleitende pnpm-Argumente, z. B. add <package>

dsh plugin --profile <name> wurde ohne weiterzuleitende Argumente angegeben. Das Subcommand initialisiert das Profil, falls es fehlt, und übergibt anschließend den restlichen Befehl an pnpm. Daher benötigt es Argumente wie add @scope/dsh-plugin-example.

FAQ

Welche Node.js-Version benötigt DeepSeek Harness?

Das Repository deklariert ^22.19.0 || >=24.0.0 in seiner package.json im Stammverzeichnis. Dieses wurde am 18 August 2026 in der Version 0.1.0-rc.7 gelesen. Daher benötigen Sie Node 22.19.0 oder neuer aus der 22er-Reihe oder Node 24 und neuer. Node 20 funktioniert nicht. Das veröffentlichte npm-Paket besitzt kein eigenes Feld engines. npm gibt daher keine Warnung aus und blockiert die Installation nicht. Der Fehler tritt stattdessen erst zur Laufzeit auf. Prüfen Sie zuerst node -v. Node 24 ist ohnehin die bessere Wahl, weil es npm 11 enthält. Dadurch wird die Wiederverwendung von Versionen durch npx behoben.

Wie zwinge ich npx dazu, das neueste dsh statt einer zwischengespeicherten Version zu verwenden?

Bei npm 11.2.0 und neuer prüft npx @deepseek-ai/dsh das Registry bereits bei jedem Aufruf erneut auf einen einfachen Paketnamen. Bei npm 10, das in jeder Node-22-Version enthalten ist, geschieht das nicht. Leeren Sie den npx-Cache mit npm cache npx rm --force unter npm 11 oder löschen Sie das Verzeichnis mit rm -rf "$(npm config get cache)/_npx" unter npm 10. Bestätigen Sie anschließend mit npx @deepseek-ai/dsh --version. Beachten Sie, dass npm cache clean --force ein anderes Verzeichnis leert und dieses Problem nicht behebt.

Warum schlägt die Installation von @deepseek-ai/dsh@^0.1.0 fehl?

npm gibt den Fehlercode ETARGET mit der Zeile No matching version found for @deepseek-ai/dsh@^0.1.0. zurück. Jeder veröffentlichte Build ist eine Vorabversion wie 0.1.0-rc.7. Ein Semver-Bereich passt nicht auf Vorabversionen, sofern der Bereich nicht selbst eine Vorabversion angibt. Installieren Sie die genaue Versionszeichenfolge einschließlich des Suffixes -rc.N. Führen Sie npm view @deepseek-ai/dsh versions --json aus, um die vorhandenen Versionen anzuzeigen. Die Versionsfolge enthält Lücken, weil einige Release Candidates nie veröffentlicht wurden.

Sollte ich dsh global installieren oder über npx ausführen?

npx eignet sich für einen ersten Test, weil außer einem Cache-Verzeichnis nichts dauerhaft gespeichert wird. Eine festgelegte globale Installation wie npm install -g @deepseek-ai/dsh@0.1.0-rc.7 eignet sich für alles, was zuverlässig weiter funktionieren muss. Die Version ändert sich dann nur, wenn Sie sie selbst ändern. Wenn der Befehl dsh nach einer globalen Installation nicht gefunden wird, fehlt das globale Bin-Verzeichnis von npm in Ihrem PATH. npm prefix -g gibt das Verzeichnis aus, unter dem sich dieses Verzeichnis befindet.

Ist DeepSeek Harness stabil genug für darauf aufbauende Entwicklungen?

Nach eigener Beschreibung noch nicht. Die README erklärt, dass sich das Projekt in der Developer Preview befindet, sich schnell weiterentwickelt und inkompatible Änderungen enthalten wird. Die Release Candidates 0.1.0-rc.6 und 0.1.0-rc.7 wurden im August 2026 im Abstand von vier Tagen veröffentlicht. Legen Sie eine exakte Version fest und lesen Sie --help aus diesem festgelegten Build statt aus einem beliebigen Leitfaden. Datieren Sie Ihre eigenen Notizen, damit Sie erkennen können, wie veraltet sie inzwischen sind.