DeepSeek Harness: Installation und Versionsfehler beheben

Was die DeepSeek-Harness-Installation tatsächlich ist

Die Installation von DeepSeek Harness besteht aus einem Befehl: npx @deepseek-ai/dsh web. Es gibt kein Installationsprogramm und keinen Dienst, den Sie konfigurieren müssen. Die meisten Probleme, auf die Sie stoßen, sind überhaupt keine Installationsprobleme. Es geht um die Versionsauflösung: Welchen Build von @deepseek-ai/dsh hat npx heute ausgewählt, und kann Ihre Node.js-Version ihn ausführen? Beim Start wird die ausgegebene Adresse an localhost gebunden. Warum die Weboberfläche nur auf 127.0.0.1:3080 antwortet ist ein separates Problem von den Problemen auf dieser Seite.

Zwei Fakten bestimmen alle folgenden Schritte. Erstens ist jede bisher bei npm veröffentlichte Version von @deepseek-ai/dsh eine Vorabversion. Die meisten sind Release Candidates (-rc.N). Seit dem 30. August 2026 gibt es außerdem Alpha-Builds (-alpha.N). Der Tag latest verweist auf einen Release Candidate. Am 6. Oktober 2026 ist das 0.2.0-rc.2, veröffentlicht am 29. September 2026. Zweitens weist die README des Projekts darauf hin, dass sich die Harness-Software in der Developer Preview befindet, schnell weiterentwickelt wird und inkompatible Änderungen enthalten wird. Ein Flag, das letzte Woche noch funktioniert hat, kann diese Woche bereits entfernt worden sein. Legen Sie eine Version fest, bevor Sie darauf aufbauen.

Zunächst einige Begriffe. dsh ist das Befehlszeilenwerkzeug von DeepSeek Harness. Node.js ist die dafür erforderliche JavaScript-Laufzeitumgebung. npx ist der mit npm (node package manager) ausgelieferte Paket-Runner. Er ruft ein Paket bei Bedarf ab, statt es dauerhaft zu installieren. Falls der Begriff Harness in diesem Zusammenhang ungewohnt ist: Ein Agent-Harness ist das Programm, das das Modell umgibt. Es verwaltet die Schleife, die Werkzeuge, die Berechtigungen und den Sitzungsstatus. Deshalb kann eine Versionsnummer, die Sie nicht selbst ausgewählt haben, das Verhalten Ihres Agenten ändern.

Welche Node.js-Version benötigt dsh?

Die Datei package.json im Repository-Root legt "engines": {"node": "^22.19.0 || >=24.0.0"} fest. Dieser Stand wurde am 6 October 2026 ausgelesen, als das Repository die Version 0.2.1-alpha.1 hatte. Sie benötigen daher Node 22.19.0 oder eine neuere Version innerhalb der 22er-Reihe oder Node 24 und höher. Node 20 wird nicht unterstützt.

Prüfen Sie zuerst Ihre installierte Version.

node -v
npm -v

Der folgende Punkt überrascht viele. Das veröffentlichte @deepseek-ai/dsh-Paket enthält kein eigenes Feld engines. Nur der Root des Monorepos legt dieses Feld fest. Diese Root-Datei wird jedoch nie bei npm veröffentlicht. npm hat daher nichts zu prüfen. Es gibt keine EBADENGINE-Warnung, und npm verweigert die Installation nicht. Unter Node 20 sieht die Installation erfolgreich aus. Der Fehler tritt erst später auf, wenn der geladene Code 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 die Fehlermeldung zu untersuchen.

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 ist am 6 October 2026 die aktuelle LTS-Reihe (long term support). Die neueste Version dieser Reihe ist an diesem Datum 24.21.0. Sie sollten diese Version auch aus einem zweiten, weiter unten erläuterten Grund bevorzugen.

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

npx @deepseek-ai/dsh web enthält keine Versionsnummer. Deshalb fragt npx die Registry ab, auf welche Version der Tag latest aktuell zeigt. Dieser Tag ändert sich häufig. 0.1.0-rc.8 wurde am 19. August 2026 veröffentlicht, zwei Tage nach 0.1.0-rc.7. Am 6. Oktober 2026 zeigte latest bereits auf 0.2.0-rc.2. Bei jeder Änderung führt der Befehl in Ihren Notizen anderen Code aus. Es gibt dabei keine Rückfrage und kein Changelog, das Sie vorher informiert.

Sie können alle beteiligten Komponenten ü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 6. Oktober 2026 zeigten sowohl latest als auch next auf 0.2.0-rc.2. Ein dritter Tag, alpha, zeigte auf 0.2.1-alpha.1. Keiner dieser Tags ist ein stabiler Kanal, auf den Sie umstellen können. Die Liste versions ist aufschlussreicher, weil sie Lücken enthält. Am 6. Oktober 2026 umfasste sie 30 Versionen, von 0.0.1-rc.1 bis 0.2.1-alpha.1. Die Zeile 0.0.1 springt von -rc.2 auf -rc.5. Die Zeile 0.1.0 springt von -rc.3 auf -rc.6. Die Alpha-Builds beginnen bei 0.1.2-alpha.2 und 0.1.3-alpha.2. Einen 0.1.4 gibt es überhaupt nicht. Nummern fehlen, weil einige Builds nie veröffentlicht wurden. Außerdem stehen Alpha-Builds und Release Candidates in derselben Liste. Wenn Sie das nächste -rc.N in einem Deploy-Script erraten, schlägt die Bereitstellung fehl. Lesen Sie daher die Liste, statt die Nummern einfach hochzuzählen.

Warum führt npx weiterhin eine alte Version aus?

Das ist die entgegengesetzte Beschwerde. Beide Fälle sind möglich, abhängig davon, welche npm-Version Sie ausführen.

npx verwendet ein eigenes Paketverzeichnis. Dieses ist vom Tarball-Cache getrennt und befindet sich im npm-Cache in einem Ordner namens _npx. Geben Sie den Pfad aus und sehen Sie sich den Inhalt 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 nur aus einem Namen oder einem Versionsbereich besteht, ruft npx jetzt das Manifest ab und verwendet die gecachte Kopie nur dann erneut, wenn der aufgelöste Tarball mit dem gerade von der Registry gelieferten Ergebnis übereinstimmt.

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

• Node 20.20.2 enthält npm 10.8.2.
• Node 22.19.0 enthält npm 10.9.3.
• Node 22.23.3, die neueste 22-Version am 6. Oktober 2026, enthält npm 10.9.9.
• Node 24.19.0 enthält npm 11.17.0.
• Node 24.21.0, die neueste 24-Version am 6. Oktober 2026, enthält npm 11.19.0.

Die gesamte Node-22-Reihe, die der Harness offiziell unterstützt, enthält also 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 gecacht hat. Derselbe Befehl löst unter Node 24 bei jedem Aufruf die Version erneut auf. Ein Befehl, zwei Verhaltensweisen, und keine 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 statt alle Einträge entfernen möchten.

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

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

npm cache clean --force hilft hier nicht. Dieser Befehl leert _cacache, den Tarball-Speicher, und lässt _npx unverändert. Genau diese Trennung war der Grund dafür, dass npm später die npm cache npx-Subcommands hinzugefügt hat. Das Leeren von _npx hat außerdem keine dauerhaften Nachteile: Dort liegen heruntergeladene Pakete, während der Zustand Ihres Harness unter $DSH_HOME/profiles/<name> gespeichert ist und unverändert bleibt.

Wie pinne ich einen bestimmten 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

Die Beispiele auf dieser Seite verwenden 0.1.0-rc.7. Ersetzen Sie den Wert durch den Build, den Sie tatsächlich getestet haben. Am 6. Oktober 2026 verwies der Tag latest auf 0.2.0-rc.2.

--yes ist in einem Skript wichtig, weil npx andernfalls vor der Installation eines 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 Spezifikationszeichenfolge als Schlüssel für sein Cache-Verzeichnis. Bei einer exakten Version vergleicht npx diese Zeichenfolge mit der dort bereits installierten Paket-ID und führt das Paket ohne weitere Abfrage der Registry aus. Bei npm 11.2.0 und höher verursacht ein einfacher Name bei jedem Start einen Abruf des Manifests.

Eine globale Installation pinnt die Version auf dieselbe Weise und ermöglicht 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 ist für dieses Paket nicht passend. 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 funktionsfähig. Dies ist eine semver-Regel: Ein Versionsbereich passt nicht zu einer Prerelease-Version, wenn der Bereich nicht selbst eine Prerelease angibt. Jeder veröffentlichte Build dieses Pakets ist eine Prerelease, entweder -rc.N oder -alpha.N. Daher passt ^0.1.0 zu keiner Version. Geben Sie die exakte Version an.

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 einen wechselnden Tag.

Soll ich npx verwenden oder dsh global installieren?

Verwenden Sie npx für einen ersten Überblick. Außer einem Cache-Verzeichnis, das Sie jetzt löschen können, bleibt nichts zurück. Für alles, was nach einem Reboot weiterhin funktionieren muss, verwenden Sie eine versionierte globale Installation, beispielsweise für einen Coding-Agenten, den Sie auf einem VPS dauerhaft ausführen.

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 Ihrer 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 festzuschreiben 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. Seitdem hat sich das Tempo nicht verlangsamt: Zwischen dem 19. August und dem 3. Oktober 2026 wurden 23 weitere Versionen veröffentlicht, darunter 0.2.0-rc.1 am 28. September und 0.2.0-rc.2 am folgenden Tag. Bei diesem Tempo können Anweisungen, die vor einem Monat geschrieben wurden, eine Befehlszeile beschreiben, die nicht mehr existiert. Das gilt auch für diese Seite. Datieren Sie jede Versionsangabe, die Sie festhalten, einschließlich Ihrer eigenen Notizen.

Zwei Gewohnheiten machen die Preview beherrschbar. Fixieren Sie die exakte Version in jedem Befehl und jedem Skript, damit beim erneuten Aufbau eines Servers dasselbe Harness entsteht. Lesen Sie anschließend die Hilfeausgabe des fixierten Builds und nicht die eines beliebigen Leitfadens.

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, und die Profile web und headless werden bei der ersten Verwendung aus den mitgelieferten Vorlagen erstellt. In diesem Verzeichnis liest das Harness außerdem seinen API-Schlüssel, das Modell und die Endpoint-Einstellungen ein. Eine fixierte Version und eine funktionierende Konfiguration sind daher zwei getrennte Punkte, die korrekt eingerichtet werden müssen. Die integrierten Bundles werden aus der aktuell ausgeführten dsh-Installation aufgelöst. Wenn Sie Ihre fixierte Version ändern, ändern sich daher auch diese Bundles. Plugins außerhalb des Installationsbaums verhalten sich anders. Sie befinden sich im Profilverzeichnis, und dsh plugin --profile <name> add <package> übergibt seine Argumente an pnpm, um sie zu installieren. pnpm muss daher in Ihrem PATH enthalten sein. dsh weist ausdrücklich darauf hin, wenn dies nicht der Fall ist. Jedes von Ihnen hinzugefügte Plugin wird mit denselben Berechtigungen ausgeführt wie Ihr Agent. Daher sollten Sie prüfen, worauf ein Plugin zugreifen kann, bevor Sie es installieren. Die pluginspezifische package.json des Profils fixiert diese Plugins. Eine vollständige Fixierung umfasst daher zwei Dateien und nicht nur eine.

Diese Aufteilung kommt Ihnen möglicherweise bekannt vor, wenn Sie Python-Tools in isolierten Umgebungen auf einem Server verwaltet haben: Das Tool und die hinzugefügten Komponenten werden an getrennten Stellen fixiert. Sobald das Harness gestartet ist, betrifft die nächste Frage normalerweise das Netzwerk und nicht die Versionen. An dieser Stelle übernehmen der Zugriff auf die dsh-Weboberfläche auf einem entfernten VPS und die ausführlichere Anleitung DeepSeek Harness auf einem VPS installieren.

Argumentfehler, die Sie tatsächlich sehen werden

Diese Fehler stammen aus dem eigenen Parser der CLI. Jeder Fehler benennt das genaue Problem. Der Wortlaut war über die Builds hinweg weitgehend stabil, aber nicht vollständig. Daher wurden die folgenden Meldungen am 6. Oktober 2026 gegen 0.2.0-rc.2 geprüft.

Fehler: --profile <name> ist erforderlich

Sie haben npx @deepseek-ai/dsh ohne Subcommand und ohne Profil ausgeführt. Der reine Befehl startet ein Profil und benötigt daher einen Namen. dsh web funktioniert ohne --profile, weil der Parser ein einzelnes erstes Wort als Profilnamen interpretiert. Dadurch startet er für Sie das mitgelieferte Profil web.

Fehler: --patch benötigt einen Pfad

--patch wurde ohne nachfolgenden Wert angegeben. Das Flag kann wiederholt werden. Jede Angabe erwartet einen Dateipfad.

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

Wählen Sie eines der beiden Flags. In 0.2.0-rc.2, auf das der am 6. Oktober 2026 verwendete Build latest zeigte, nennt die Meldung ein drittes Flag und lautet error: --dump-config, --dump-default-config, and --dump-config-schema are mutually exclusive, weil --dump-config-schema inzwischen zu den beiden anderen Flags hinzugekommen ist. Dieses Flag gibt das JSON Schema für Profileinträge und Patches aus. --dump-default-config gibt die mitgelieferten Bundle-Schichten aus und akzeptiert kein --patch. --dump-config gibt die zusammengesetzte Konfiguration für ein Profil aus. Alle diese Befehle geben ihre Ausgabe aus und beenden sich, ohne den Harness zu starten. Dadurch können Sie sicher prüfen, was ein neuer Release Candidate an Ihrer Konfiguration geändert hat.

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

dsh plugin --profile <name> wurde ohne Argumente zur Weitergabe aufgerufen. Das Subcommand initialisiert das Profil, falls es fehlt, und übergibt anschließend den restlichen Teil der Befehlszeile 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. Diese Angabe wurde am 6. Oktober 2026 ausgelesen, als das Repository die Version 0.2.1-alpha.1 hatte. Sie benötigen daher Node 22.19.0 oder neuer innerhalb der 22er-Linie oder Node 24 und neuer. Node 20 funktioniert nicht. Das veröffentlichte npm-Paket hat kein eigenes Feld engines. npm gibt deshalb 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. Damit wird die Wiederverwendung von Versionen durch npx behoben.

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

Unter npm 11.2.0 und neuer prüft npx @deepseek-ai/dsh bei jedem Aufruf erneut die Registry, wenn nur ein Paketname angegeben ist. Unter npm 10, das in jeder Node-22-Version enthalten ist, geschieht das nicht. Leeren Sie den npx-Cache unter npm 11 mit npm cache npx rm --force. Unter npm 10 löschen Sie das Verzeichnis mit rm -rf "$(npm config get cache)/_npx". Bestätigen Sie das 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 ein Prerelease wie 0.2.0-rc.2 oder 0.2.1-alpha.1. Ein Semver-Bereich erfasst keine Prerelease-Versionen, sofern der Bereich nicht selbst eine solche Version angibt. Installieren Sie die exakte Versionszeichenfolge einschließlich des Suffixes. Mit npm view @deepseek-ai/dsh versions --json sehen Sie, welche Versionen vorhanden sind. Die Versionsfolge enthält Lücken, weil bestimmte Builds 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 dauerhaft 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 PATH. Mit npm prefix -g geben Sie das Stammverzeichnis aus, unter dem es liegt.

Ist DeepSeek Harness stabil genug für die Entwicklung darauf?

Nach eigener Beschreibung noch nicht. Die README erklärt, dass sich das Projekt in einer Entwicklervorschau 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. 0.2.0-rc.1 und 0.2.0-rc.2 folgten im September 2026 im Abstand von einem Tag. Legen Sie eine exakte Version fest und lesen Sie --help aus diesem festgelegten Build statt aus einer beliebigen Anleitung. Datieren Sie Ihre eigenen Notizen, damit Sie erkennen können, wie veraltet sie sind.