DeepSeek Harness Web UI nicht erreichbar: Checkliste 2026

Die Seite bleibt nach dsh web leer oder der Browser meldet „Verbindung abgelehnt“.

Schnellste Lösung: Installieren Sie nicht sofort neu. Prüfen Sie zuerst, ob der dsh-Prozess noch läuft und welche Adresse das Terminal ausgibt. Danach folgen Browserzugriff, Modellzugang, Workspace und Freigaben. Auf einem entfernten Mac behandeln Sie den Zugriff als eigene Fehlerkette und veröffentlichen die lokale Bindung nicht direkt im Internet.

Für wen diese Anleitung gedacht ist: Für Entwickler, die DeepSeek Harness unter macOS erstmals starten und keine erreichbare Web UI sehen. Für AI-Agent-Entwickler, bei denen Modell oder Workspace nicht verfügbar sind. Für Administratoren, die einen entfernten Mac als Entwicklungs- oder Testknoten betreuen.

Stand der Prüfung: Zuletzt aktualisiert am 18.08.2026. Die Angaben wurden anhand der offiziellen README, des Web-UI-Leitfadens, der Modellkonfiguration und der Entwicklungsdokumentation geprüft.

Die häufigste Fehlentscheidung besteht darin, einen Browserfehler als Installationsfehler zu behandeln. dsh web kann jedoch aus mehreren Gründen nicht an dem Punkt ankommen, an dem eine Webadresse erreichbar wird:

• Der Befehl ist nicht installiert oder wird in der aktuellen Shell nicht gefunden.
• Der Startprozess beendet sich sofort wegen einer inkompatiblen Umgebung, fehlender Abhängigkeiten oder eines Build-Problems.
• Der Prozess läuft, aber der Zugriff erfolgt über die falsche Adresse.
• Der Dienst ist lokal erreichbar, wird aber von einem anderen Gerät aus über 127.0.0.1 angesprochen.
• Ein vorhandener Prozess oder eine lokale Sicherheitsregel verhindert die erwartete Bindung.

Die aktuelle offizielle Dokumentation beschreibt den Start über npx @deepseek-ai/dsh web und nennt http://127.0.0.1:3080 als standardmäßige lokale Adresse. Diese Adresse ist eine Prüfreferenz, aber kein Ersatz für die Ausgabe Ihres Terminals: Bei einer späteren Version, einer Quellcode-Installation oder einer abweichenden Konfiguration kann die tatsächliche Adresse anders lauten. (offizielle README)

Die lokale Startprüfung als Checkliste

Arbeiten Sie die Punkte in dieser Reihenfolge ab und markieren Sie jeden bestätigten Zustand:

• [ ] Der verwendete Befehl ist in der aktuellen Shell verfügbar.
• [ ] dsh web beendet sich nicht unmittelbar nach dem Start.
• [ ] Das Terminal zeigt eine Webadresse oder einen laufenden Server an.
• [ ] Die ausgegebene Adresse wird auf demselben Mac geöffnet.
• [ ] Ein Browser-Reload ändert nichts am grundsätzlichen Ergebnis.
• [ ] Die Terminalausgabe wurde vor Änderungen vollständig gesichert.

Starten Sie den Befehl in einem eigenen Terminalfenster und lassen Sie dieses Fenster geöffnet. Wenn der Shell-Prompt sofort wieder erscheint, ist der Prozess wahrscheinlich beendet worden. Wenn das Fenster aktiv bleibt, der Browser aber keine Verbindung erhält, prüfen Sie Prozess und Listening-Socket:

ps aux | grep -i '[d]sh'
lsof -nP -iTCP -sTCP:LISTEN

Diese Befehle liefern keine vollständige Fehlerdiagnose, trennen aber zwei wichtige Fälle: „Kein Webdienst läuft“ und „Webdienst läuft, aber die angeforderte Adresse stimmt nicht“. Der Start gilt erst dann als erfolgreich, wenn der Prozess aktiv bleibt, eine Adresse ausgibt und diese Adresse lokal eine Antwort liefert.

Entscheidung nach dem Beobachtungssignal

• command not found oder ein ähnlicher Shell-Fehler: Installations- oder Pfadproblem. Prüfen Sie die offizielle Startmethode, die Node-Umgebung und den verwendeten Paketmanager.
• Der Prozess beendet sich sofort: Startfehler. Sichern Sie die vollständige Terminalausgabe, bevor Sie Dateien löschen oder neu installieren.
• Der lokale Browser meldet „Verbindung abgelehnt“: Prozess, Port oder Bindung prüfen.
• Die lokale Adresse funktioniert, ein anderes Gerät aber nicht: Die Web UI läuft wahrscheinlich; der Fehler liegt in der Zugriffskette.
• Die Seite lädt, Felder bleiben aber leer: Der Webserver ist erreichbar. Fahren Sie mit Modell- und Workspace-Diagnose fort.

Wenn Sie DeepSeek Harness aus dem Quellcode betreiben, müssen Sie den Entwicklungsweg von einer normalen Paketinstallation unterscheiden. Die Entwicklungsdokumentation nennt Node.js 22.19 oder neuer beziehungsweise Node.js 24 sowie Corepack-fähiges pnpm für diesen Ablauf. Diese Voraussetzungen sind nicht automatisch auf jede Installationsart übertragbar. (offizielle Entwicklungsdokumentation)

127.0.0.1 bezeichnet immer den lokalen Rechner. Läuft DeepSeek Harness auf einem entfernten Mac und wird auf dem eigenen Arbeitsplatz http://127.0.0.1:3080 geöffnet, fragt der Browser den Arbeitsplatz selbst ab, nicht den Remote-Knoten. Diese Verwechslung erzeugt häufig den Eindruck, die DeepSeek Harness Web UI sei defekt.

Unsere empfohlene Reihenfolge lautet:

1. Öffnen Sie die vom Terminal ausgegebene Adresse direkt auf dem Remote-Mac.
2. Prüfen Sie, ob die Web UI dort lokal funktioniert.
3. Testen Sie den vorgesehenen Fernzugang unabhängig von DeepSeek Harness.
4. Verwenden Sie anschließend einen kontrollierten Tunnel oder eine andere abgesicherte Zugriffsmethode.
5. Planen Sie eine externe Netzwerkfreigabe nur dann, wenn Authentifizierung und Netzwerkgrenzen bereits festgelegt sind.

Für einen SSH-Tunnel kann die Struktur beispielsweise so aussehen:

ssh -N -L 3080:127.0.0.1:3080 BENUTZER@REMOTE-MAC

Danach öffnen Sie auf dem eigenen Rechner die lokale Tunneladresse. Benutzername und Hostname hängen von Ihrer Umgebung ab. Der Tunnel verändert die lokale Bindung des Webdienstes nicht automatisch und reduziert damit die Zahl der nach außen sichtbaren Netzwerkflächen.

Sicherheitsgrenze: Eine lokale Web UI ohne vorgeschaltete Authentifizierung sollte nicht einfach an eine öffentliche Adresse gebunden werden. API-Schlüssel, Workspace-Dateien und ausgeführte Agent-Befehle gehören nicht in einen unkontrolliert erreichbaren Dienst. Prüfen Sie DSGVO-relevante Datenflüsse, Firewall-Regeln, SSH-Schlüssel, Sitzungsdauer und Protokollierung vor jeder Freigabe.

Bei einem Remote-Mac entstehen mindestens drei zusätzliche Fehlerquellen: eine zweite Netzwerkstrecke, ein weiterer Benutzer- und Berechtigungskontext sowie unterschiedliche Lebenszyklen von Browser, Tunnel und Webprozess. Wenn der Mac schläft, die SSH-Sitzung endet oder ein Hintergrundprozess den Dienst beendet, kann die Oberfläche aus Sicht des Benutzers verschwinden, obwohl die Installation unverändert ist.

Welcher Zugriffspfad ist für den jeweiligen Fall sinnvoll?

• Lokaler Mac: Geeignet für die erste Diagnose, weil Prozess, Browser und Dateisystem unter derselben Kontrolle stehen.
• Entfernter Mac mit sicherem Tunnel: Sinnvoll für dauerhafte Entwicklung, wenn Benutzerkonto, Netzwerk und Energieversorgung stabil geregelt sind.
• Öffentlich erreichbarer Webdienst: Nur vertretbar, wenn Authentifizierung, Netzwerksegmentierung, TLS, Protokollierung und Rückfallplan umgesetzt sind.

Für eine vorübergehende Testumgebung kann ein Mac-Arbeitsplatz von JEXCLOUD die Fehlerquelle „privates Netzwerk gegen Remote-Netzwerk“ sauber isolieren. Das ersetzt keine Sicherheitsprüfung, verhindert aber, dass eine unklare Portfreigabe am privaten Entwicklungsrechner zum Standardbetrieb wird.

Wenn die Seite geöffnet wird, aber kein Modell verfügbar ist, liegt der Fehler meistens nicht mehr beim Webserver. Der Web-UI-Leitfaden beschreibt, dass ein neuer Start zunächst noch keinen ausgewählten Workspace besitzt; die Modellkonfiguration erfolgt dagegen über „Settings“ und „Models“. Der Schlüssel wird gespeichert und soll ohne Serverneustart für die nächste Anfrage wirksam werden. (offizieller Web-UI-Leitfaden)

Achten Sie auf diese Beobachtungssignale:

• Der API-Key lässt sich speichern, aber die Modellliste bleibt leer.
• Ein Modell erscheint, lässt sich jedoch nicht auswählen.
• Der Composer bleibt trotz gespeicherter Zugangsdaten deaktiviert.
• Ein benutzerdefinierter Provider wird angezeigt, aber die Modellabfrage schlägt fehl.
• Eine Aufgabe startet und endet mit einem Authentifizierungs- oder Modellfehler.

Prüfen Sie anschließend:

1. Öffnen Sie Settings → Models.
2. Speichern Sie den DeepSeek API-Key erneut, ohne ihn in Logs, Screenshots oder der Shell-History zu veröffentlichen.
3. Kontrollieren Sie, ob ein konkretes Modell im Auswahlfeld erscheint.
4. Prüfen Sie bei einem benutzerdefinierten Provider Provider-ID, Basis-URL, API-Protokoll und Modell-ID.
5. Starten Sie eine neue Sitzung, wenn die bestehende Sitzung ein veraltetes Modell gespeichert hat.
6. Wenn die automatische Modellabfrage scheitert, tragen Sie das Modell entsprechend der Provider-Dokumentation manuell ein.

Die Provider-Dokumentation nennt unter anderem MISSING_CREDENTIAL, UNKNOWN_MODEL und eine fehlgeschlagene Modellabfrage mit HTTP 401. Bei benutzerdefinierten Endpunkten wird die Modellliste über GET /models abgerufen; ein Endpunkt ohne diese Funktion kann deshalb trotz gültigem Schlüssel leer erscheinen. (offizielle Provider-Dokumentation)

Ein gespeicherter Schlüssel beweist außerdem nicht, dass jede Anfrage zugelassen wird. Die offizielle DeepSeek-Dokumentation unterscheidet unter anderem zwischen 401 für fehlgeschlagene Authentifizierung, 402 für fehlendes Guthaben, 422 für ungültige Parameter, 429 für ein erreichtes Ratenlimit sowie 500 und 503 für serverseitige oder Überlastungsfehler. (offizielle Fehlercode-Dokumentation der DeepSeek API)

Wenn die Modellliste leer bleibt, obwohl der Schlüssel gültig ist, sollten Sie deshalb nicht automatisch den Browser oder den Workspace zurücksetzen. Prüfen Sie zuerst Provider-Endpunkt und Modell-ID. Bei einem HTTP-429-Fehler ist eine Änderung des API-Keys ebenfalls keine verlässliche Lösung; zunächst müssen Anfragehäufigkeit und parallele Sitzungen betrachtet werden.

Ein vollständig geladener Bildschirm mit deaktiviertem Eingabefeld ist besonders irreführend. In diesem Fall funktioniert der Webserver, aber die Anwendung hat noch keinen gültigen Arbeitsbereich. Der Startordner von dsh ist nur der anfängliche Dateisystemstandort; eine frische Web UI besitzt noch keinen ausgewählten Workspace. (offizieller Web-UI-Leitfaden)

Prüfen Sie nacheinander:

• Existiert der angezeigte Pfad tatsächlich auf dem Mac, auf dem dsh läuft?
• Wird die Web UI unter demselben Benutzerkonto ausgeführt, das Zugriff auf diesen Ordner hat?
• Ist der Ordner lokal vorhanden oder handelt es sich um ein nicht eingebundenes Netzlaufwerk?
• Liegt das Repository auf dem Remote-Mac an derselben Stelle wie auf dem lokalen Rechner?
• Sind Lese- und, für geplante Änderungen, Schreibrechte vorhanden?
• Wurde der Workspace nach Benutzerwechsel, Migration oder Neustart erneut ausgewählt?

Eine sichere Prüfung im Terminal ist:

pwd
ls -ld /PFAD/ZUM/PROJEKT
test -r /PFAD/ZUM/PROJEKT && echo "lesbar"
test -w /PFAD/ZUM/PROJEKT && echo "beschreibbar"

Ein sichtbarer Ordner genügt nicht als Wiederherstellungsstandard. Der Workspace muss in der Web UI hinzugefügt, ausgewählt und für eine Sitzung verwendet werden können. Wenn der Pfad auf dem lokalen Rechner existiert, aber auf dem Remote-Mac nicht, korrigieren Sie nicht vorschnell die Web-UI-Einstellungen. Wählen Sie stattdessen das tatsächlich auf dem Remote-Knoten vorhandene Projektverzeichnis oder stellen Sie die erwartete Verzeichnisstruktur wieder her.

Wenn der Composer nach der Auswahl weiterhin deaktiviert ist, prüfen Sie erneut die Modellwahl. Ein gelöschter oder umbenannter Provider kann dazu führen, dass eine gespeicherte Sitzung kein gültiges Standardmodell mehr besitzt; in diesem Zustand muss ein verfügbares Modell ausgewählt werden.

Warum öffnet sich die Web UI nach dem Start von dsh web nicht?

Prüfen Sie zuerst, ob der Prozess noch läuft und welche Adresse das Terminal tatsächlich ausgibt. Die dokumentierte lokale Standardadresse ist 127.0.0.1:3080, aber eine andere Version oder Konfiguration kann abweichen. Ein anderer Rechner kann diese lokale Adresse nicht verwenden. Erst wenn der lokale Aufruf funktioniert, sollte die entfernte Zugriffskette untersucht werden.

Was tun, wenn DeepSeek Harness keinen Workspace auswählen lässt?

Der Startordner ist nur der anfängliche Dateisystemkontext und ersetzt keinen ausgewählten Workspace. Fügen Sie das auf dem jeweiligen Mac vorhandene Projektverzeichnis über die Workspace-Auswahl hinzu und wählen Sie es anschließend aus. Prüfen Sie außerdem, ob der ausführende Benutzer den Pfad lesen und bei geplanten Änderungen beschreiben darf.

Warum bleibt das Modell trotz gespeichertem DeepSeek API-Key unbrauchbar?

Ein gespeicherter Schlüssel zeigt nur, dass die Zugangsdaten angenommen wurden. Prüfen Sie danach Modell-ID, Provider-ID, Basis-URL und API-Protokoll. Wenn ein benutzerdefinierter Endpunkt keine Modellliste über GET /models liefert, kann die automatische Auswahl leer bleiben. In diesem Fall ist eine manuelle Modellkonfiguration erforderlich.

Wie lässt sich die DeepSeek Harness Web UI auf einem entfernten Mac sicher erreichen?

Behalten Sie die lokale Bindung zunächst bei und testen Sie den Zugriff über einen abgesicherten Fernzugang oder einen SSH-Tunnel. Öffnen Sie den Dienst nicht ungeprüft für das öffentliche Internet. Vor einer externen Freigabe benötigen Sie Authentifizierung, eine begrenzte Netzwerkregel, Protokollierung und eine Rückfallmöglichkeit.

„Die Aufgabe hängt“ beschreibt mindestens vier unterschiedliche Zustände:

1. Die Web UI wartet auf eine Bedienfreigabe.
2. Die Anfrage wartet auf eine Antwort der DeepSeek API.
3. Die API hat mit 429, 500 oder 503 geantwortet.
4. Die Sitzung oder der Browser zeigt einen veralteten Zustand.

Beobachten Sie daher nicht nur die Animation im Browser, sondern auch:

• den Zeitpunkt des Starts,
• die letzte sichtbare Statusänderung,
• den vollständigen Fehlercode,
• die verwendete Modell-ID,
• ob ein Bestätigungsdialog geöffnet ist,
• ob im Terminal neue Meldungen erscheinen,
• ob eine neue Sitzung dasselbe Verhalten zeigt.

Aktionen wie Dateizugriffe und Befehle können je nach aktiver Berechtigungsrichtlinie eine Bestätigung verlangen. Ein wartender Agent ist deshalb nicht zwingend abgestürzt. Starten Sie zur Eingrenzung eine neue Sitzung mit einer Aufgabe ohne Seiteneffekte:

Lesen Sie die Projektstruktur und nennen Sie die wichtigsten Verzeichnisse. Ändern Sie keine Dateien und führen Sie keine Befehle aus.

Wenn diese Aufgabe funktioniert, aber ein Schreib- oder Shell-Schritt wartet, liegt der Verdacht auf einer Freigabe oder Berechtigung. Wenn bereits die reine Lesaufgabe keine Antwort erhält, vergleichen Sie Modell, API-Key, Netzwerkzugriff und Sitzungsprotokoll.

Notieren Sie für einen Supportfall mindestens Modell, Zeitstempel, HTTP-Status, betroffenen Workspace und die kleinste reproduzierbare Aufgabe. Entfernen Sie API-Schlüssel und vertrauliche Dateiinhalte. Ohne diese Informationen wird aus einem beobachtbaren Fehler schnell die unprüfbare Aussage „Web UI kaputt“.

Nach einer Korrektur sollten Sie nicht sofort ein großes Agent-Projekt starten. Verwenden Sie diese Abnahme-Checkliste:

• [ ] Die vom Terminal ausgegebene Adresse öffnet sich auf dem vorgesehenen Gerät.
• [ ] Ein gültiges Modell erscheint und bleibt nach dem Speichern auswählbar.
• [ ] Der Workspace kann die Projektstruktur ohne Änderung zusammenfassen.
• [ ] Ein ungefährlicher Prüf- oder Versionsbefehl wartet gegebenenfalls auf Zustimmung.
• [ ] Eine neue Sitzung lässt sich anlegen.
• [ ] Die Sitzung bleibt nach einem Browser-Reload nachvollziehbar.
• [ ] Der definierte Remote-Zugriff funktioniert erneut.
• [ ] Die Web UI ist nicht unkontrolliert öffentlich erreichbar.
• [ ] API-Schlüssel und Sitzungsdaten wurden nicht in Diagnoseprotokolle kopiert.

Vor einem Neustart sichern Sie die relevante Konfiguration, notieren den verwendeten Benutzer und speichern die Terminalausgabe. Bei einer Quellcode-Installation prüfen Sie außerdem, ob ein Build erforderlich ist; ein Build- oder Abhängigkeitsproblem sollte nicht durch das Löschen einer funktionierenden Umgebung verschleiert werden.

Eine Rückkehr zu einer bereits geprüften Umgebung ist sinnvoll, wenn die aktuelle Version in einer sauberen Umgebung nicht reproduzierbar startet, Provider- und Modellwerte mehrfach verändert wurden oder der Remote-Mac unklare Benutzerrechte besitzt. Erstellen Sie in diesem Fall zuerst eine Konfigurationssicherung beziehungsweise einen Umgebungsschnappschuss, bevor Sie eine neue Sitzung oder einen neuen Workspace anlegen.

Wenn DeepSeek Harness auf dem vorhandenen Rechner läuft, aber der aktuelle Ansatz regelmäßig an wechselnden Benutzerrechten, Schlafzuständen, Portfreigaben oder uneinheitlichen Projektpfaden scheitert, entstehen versteckte Betriebskosten: wiederholte Fehlersuche, nicht reproduzierbare Sitzungen und ein erhöhtes Risiko, Zugangsdaten oder Workspace-Dateien über eine zu offene Netzwerkstrecke zu exponieren. Eine direkte öffentliche Freigabe des privaten Macs ist deshalb selten die beste langfristige Lösung.

Für gelegentliche Tests ist ein eigener Mac weiterhin sinnvoll, besonders wenn physische Geräte, lokale Dateien oder dauerhaft laufende Hintergrundprozesse benötigt werden. Für zeitlich begrenzte AI-Agent-Tests, reproduzierbare Remote-Sitzungen und eine getrennte Arbeitsumgebung kann die Miete eines Mac über JEXCLOUD jedoch die bessere Balance aus Kontrolle und Aufwand bieten. Die Mac-Optionen für die USA sollten nach Latenz, Datenschutzanforderungen und Zugriffspfad ausgewählt werden, nicht nur nach dem niedrigsten Mietpreis.

Entscheidend ist, dass vor dem nächsten Upgrade eine Konfigurationssicherung, ein getesteter Zugriffsweg und ein kurzer Wiederherstellungstest dokumentiert sind. So wird aus der heutigen Fehlerbehebung ein zurückrollbarer Betriebsablauf statt der nächsten Neuinstallation.