2026 DeepSeek Harness: Wie verwendet man launchd für den automatischen Start beim Hochfahren?

Der DeepSeek-Harness-Prozess läuft nach einem Neustart nicht, obwohl die Installation erfolgreich war.

Die schnellste belastbare Lösung ist: Verwenden Sie für DeepSeek Harness mit launchd automatisch starten zuerst einen normalen Benutzer als LaunchAgent, legen Sie ausführbaren Pfad, Arbeitsverzeichnis, Profile und Zugangsdaten fest und prüfen Sie anschließend Prozess, Port, Modellaufruf und Wiederanlauf getrennt voneinander.

Diese Anleitung richtet sich an Remote-Mac-Nutzer, die DeepSeek Harness nach einem Neustart oder einer erneuten Anmeldung automatisch wieder verfügbar machen möchten.

Plattformingenieure erhalten ein einheitliches Verfahren für Prozessidentität, Logpfade und Stop-Befehle. Verantwortliche für die Übergabe können anhand einer reproduzierbaren Prüfung entscheiden, ob der Dienst wirklich betriebsbereit ist oder nur gestartet wurde.

Wir empfehlen nicht, sofort eine umfangreiche plist-Datei zu schreiben und anschließend mit KeepAlive jeden Absturz zu überdecken. Der risikoärmere Ablauf besteht aus fünf Phasen:

1. Vorbereitung: Web UI, Headless-Aufruf oder Automatisierungsprozess eindeutig festlegen.
2. Erste Verwaltung: Unter dem vorgesehenen normalen Benutzerkonto einen LaunchAgent anlegen.
3. Startprüfung: Prozessidentität, absolute Pfade, Arbeitsverzeichnis und Logs kontrollieren.
4. Funktionsprüfung: Web-Zugriff oder Headless-Aufgabe mit einem risikoarmen Test bestätigen.
5. Wiederanlauf und Übergabe: Abbruch, Abmeldung, Anmeldung und Neustart testen; danach Stop-, Upgrade- und Rückfallverfahren dokumentieren.

Für diese Reihenfolge spricht die Rolle von launchd: macOS verwendet den Dienst zur Verwaltung von Agents und Daemons, während launchctl zum Laden, Entladen und Kontrollieren der Jobs dient. Benutzerbezogene Agents liegen typischerweise unter ~/Library/LaunchAgents; systemweite Daemons werden dagegen in anderen Verzeichnissen verwaltet. Die Apple-Dokumentation zu den Verzeichnissen von Agents und Daemons beschreibt diese Trennung.

Hinweis: „Automatisch gestartet“ bedeutet zunächst nur, dass ein Prozess von launchd ausgeführt wurde. Es beweist weder, dass die Web UI erreichbar ist, noch dass ein Profile geladen, ein API Key gelesen oder eine Aufgabe erfolgreich beendet wurde.

Bevor Sie eine LaunchAgent-Datei erstellen, müssen Sie den Lebenszyklus des zu verwaltenden Objekts festlegen. Eine Web UI ist ein dauerhaft laufender Prozess. Ein Headless-Aufruf kann dagegen eine einzelne Aufgabe starten und anschließend mit einem Exit-Status enden. Ein periodischer Automatisierungsprozess besitzt wiederum eigene Anforderungen an Statusdateien, Sperren und Wiederholungen.

Diese drei Fälle sollten nicht ohne Prüfung in einen einzigen Job gepackt werden. Ein Agent, der für eine einmalige Headless-Aufgabe ständig neu gestartet wird, kann bei einem normalen Exit sofort eine neue Aufgabe auslösen. Umgekehrt kann eine dauerhaft erwartete Web UI durch einen einmaligen Aufruf beendet werden, obwohl launchd korrekt gearbeitet hat.

Dokumentieren Sie vor der Konfiguration mindestens folgende Werte:

• absolute Position des ausführbaren Programms oder des Startskripts;
• verwendete Version und gegebenenfalls virtuelle Umgebung;
• Profile, Konfigurationsdatei und Statusverzeichnis;
• Arbeitsverzeichnis, in dem Harness relative Pfade auflöst;
• Benutzerkonto und numerische Benutzer-ID;
• erwartete Bind-Adresse und Port der Web UI;
• Methode zum kontrollierten Stoppen;
• erwartetes Verhalten bei normalem Ende, Fehler und manueller Unterbrechung.

Die aktuelle Laufdokumentation des Projekts nennt unter anderem eine Kommandozeilenform mit dsh sowie eine Ausführung über npx. Diese Angaben müssen Sie jedoch auf dem Zielgerät in absolute Pfade übersetzen; eine interaktive Shell lädt häufig zusätzliche Pfade aus Profilskripten, die launchd nicht automatisch übernimmt. Die aktuelle Lauf- und Installationsübersicht von DeepSeek Harness führt die verfügbaren Ausführungsformen und Prüfkommandos auf.

Für Web-Arbeitsabläufe ist ein normaler Benutzer in der Regel der passendere Ausgangspunkt. Ein LaunchAgent wird in der Benutzersitzung geladen und kann dadurch auf benutzerbezogene Profile, Arbeitsbereiche und Sitzungsressourcen zugreifen. Ein LaunchDaemon läuft dagegen systemweit und ist nicht automatisch mit der interaktiven Benutzersitzung gleichzusetzen.

Das ist keine pauschale Aussage gegen Daemons. Ein systemweiter Dienst kann sinnvoll sein, wenn kein Benutzer-Login erforderlich ist, alle Ressourcen bewusst systemweit verwaltet werden und die Berechtigungen sauber modelliert sind. Für eine Web UI mit persönlichen Arbeitsbereichen oder lokalen Konfigurationsdateien erhöht ein voreilig als root gestarteter Prozess jedoch die Komplexität:

• Dateien können danach root gehören und für den normalen Benutzer nicht mehr beschreibbar sein;
• relative Pfade zeigen auf ein anderes Arbeitsverzeichnis;
• benutzerbezogene Credential Stores oder Profile sind nicht verfügbar;
• Logs und Statusdaten landen möglicherweise in einem nicht erwarteten Verzeichnis;
• ein kompromittierter Web-Prozess hätte mehr Rechte als für die Aufgabe erforderlich.

Legen Sie deshalb zunächst eine Datei unter dem vorgesehenen Benutzerkonto an:

/Users/<BENUTZER>/Library/LaunchAgents/<EIGENE-LABEL>.plist

Die Platzhalter müssen durch echte Werte ersetzt werden. <BENUTZER> ist der Kurzname des Kontos, das später angemeldet sein wird. <EIGENE-LABEL> muss innerhalb Ihrer Jobs eindeutig sein. Verwenden Sie weder pauschal /usr/local/bin/dsh noch einen aus einer interaktiven Shell kopierten npx-Aufruf, solange Sie den tatsächlich auflösbaren Pfad nicht geprüft haben.

Eine plist sollte nur Startparameter, Arbeitsverzeichnis, Umgebungsvariablen und Logausgänge beschreiben. Einen echten API Key sollten Sie dort nicht im Klartext ablegen. Die Datei ist zwar keine normale Shell-Datei, kann aber bei falschen Eigentümern, Backups oder Diagnosekopien unnötig viele Personen erreichen.

Die von uns verwendete Struktur ist bewusst nur ein Gerüst und kein universell kopierbares Endprodukt:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string><EINDEUTIGE-LABEL></string>

    <key>ProgramArguments</key>
    <array>
        <string><ABSOLUTER-STARTPFAD></string>
        <string><ARGUMENT-1></string>
        <string><ARGUMENT-2></string>
    </array>

    <key>WorkingDirectory</key>
    <string><ABSOLUTES-ARBEITSVERZEICHNIS></string>

    <key>EnvironmentVariables</key>
    <dict>
        <key>HARNESS_PROFILE</key>
        <string><PROFILE-NAME-ODER-PFAD></string>
    </dict>

    <key>RunAtLoad</key>
    <true/>

    <key>StandardOutPath</key>
    <string><ABSOLUTER-LOGPFAD-STDOUT></string>

    <key>StandardErrorPath</key>
    <string><ABSOLUTER-LOGPFAD-STDERR></string>
</dict>
</plist>

Apple beschreibt Label und ProgramArguments als zentrale Bestandteile einer Jobdefinition. RunAtLoad und KeepAlive sind hingegen keine Garantie für eine fachlich erfolgreiche Aufgabe; sie steuern den Prozesslebenszyklus. Die Referenz zu Launch-Daemons und Launch-Agents erläutert diese Grundprinzipien.

Prüfen Sie vor dem Laden:

plutil -lint "/Users/<BENUTZER>/Library/LaunchAgents/<EIGENE-LABEL>.plist"
ls -l "/Users/<BENUTZER>/Library/LaunchAgents/<EIGENE-LABEL>.plist"

Die Datei sollte dem vorgesehenen Konto gehören und darf nicht durch eine vorherige Bearbeitung mit administrativen Rechten unbemerkt einen falschen Eigentümer erhalten.

Ein typischer Fehler entsteht, wenn der Startbefehl im Terminal funktioniert, im LaunchAgent jedoch mit „command not found“ scheitert. Der Grund ist meistens nicht DeepSeek Harness selbst, sondern die reduzierte Umgebung von launchd: Shell-Initialisierungen wie .zprofile, Versionsmanager oder lokale PATH-Erweiterungen sind dort nicht zuverlässig vorhanden.

Ermitteln Sie deshalb im Zielkonto:

command -v node
command -v npx
command -v dsh
node --version
npx --version
dsh doctor

Übernehmen Sie nur die tatsächlich ausgegebenen absoluten Pfade. Wenn dsh aus einer virtuellen Umgebung stammt, verwenden Sie den dortigen Pfad direkt. Wenn npx lediglich als Vermittler für einen dauerhaft laufenden Prozess dient, prüfen Sie, ob ein stabiler direkter Einstiegspunkt des installierten Pakets existiert. Ein pauschales sh -lc kann zwar Profile laden, verschleiert aber Fehler und macht die Prozessidentität schwerer nachvollziehbar.

Ein robustes Verfahren ist:

1. Den Pfad im Zielkonto ermitteln.
2. Dasselbe Kommando mit minimaler Umgebung ausführen.
3. Erst danach den Pfad in ProgramArguments eintragen.
4. Die erwarteten Variablen explizit in EnvironmentVariables definieren.
5. Einen Fehler im Log beheben, statt die Neustartlogik zu verstärken.

Erfahrung aus der Übergabe: Wenn node oder dsh nicht gefunden wird, ist KeepAlive kein Reparaturmechanismus. Es kann lediglich denselben fehlerhaften Start wiederholen und dadurch die Logs unlesbar machen.

Für launchd und DeepSeek Harness ist die entscheidende Frage nicht nur, ob ein API Key existiert, sondern ob der gestartete Prozess ihn unter genau derselben Benutzeridentität und aus derselben Quelle lesen kann.

Vermeiden Sie drei Muster:

• einen echten Schlüssel direkt in der plist;
• einen Schlüssel als Kommandozeilenargument;
• ein globales root-Konto, nur weil die interaktive Benutzersitzung nicht korrekt abgebildet wurde.

Besser ist eine zugriffsbeschränkte Datei außerhalb des öffentlich erreichbaren Web-Arbeitsbereichs oder ein vom Projekt ausdrücklich unterstützter Credential Store. Der genaue Variablenname und das unterstützte Profile-Verhalten müssen zur installierten DeepSeek-Harness-Version passen. Die README beschreibt je nach Ausführungsform unterschiedliche Installations- und Prüfwege; deshalb sollte die Variable nicht aus einem Beispiel blind übernommen werden. Die dokumentierte CLI- und Profile-Nutzung dient als Referenz, ersetzt aber nicht die Prüfung auf Ihrem Remote Mac.

Prüfen Sie die Quelle mit einem ungefährlichen Test, der nur den Status ausgibt:

test -r "<ABSOLUTER-CREDENTIAL-PFAD>" && echo "Credential-Datei lesbar"
env | grep -E '^(HARNESS_PROFILE|DEEPSEEK_)' | sed 's/=.*$/=<gesetzt>/'

Ein echter Wert darf nicht in die Ausgabe gelangen. Ebenso sollten Web-Logs keine vollständigen Request-Header, Token oder Umgebungsvariablen protokollieren. Aus DSGVO-Sicht gehört in die Betriebsdokumentation die Quelle und der Zugriffspfad, nicht der geheime Inhalt.

Laden Sie den Agent erst, nachdem plutil die Datei akzeptiert hat. Je nach macOS-Version und Sitzung kann der genaue launchctl-Befehl variieren; für einen Benutzer-Agent ist die grafische Benutzersitzung des vorgesehenen Kontos maßgeblich.

Beispielhaft:

UID_DES_BENUTZERS="$(id -u)"
launchctl bootstrap "gui/${UID_DES_BENUTZERS}" \
  "/Users/<BENUTZER>/Library/LaunchAgents/<EIGENE-LABEL>.plist"

launchctl print "gui/${UID_DES_BENUTZERS}/<EIGENE-LABEL>"

Die Kommandos müssen in derselben Benutzer- und Sitzungslogik ausgeführt werden, für die der Agent gedacht ist. Die Anleitung zur Skriptverwaltung mit launchd beschreibt den Zusammenhang zwischen launchd und launchctl.

Kontrollieren Sie danach in dieser Reihenfolge:

pgrep -af "<KENNZEICHNENDER-PROZESS>"
lsof -nP -iTCP:<PORT> -sTCP:LISTEN
tail -n 100 "<ABSOLUTER-LOGPFAD-STDOUT>"
tail -n 100 "<ABSOLUTER-LOGPFAD-STDERR>"

Damit erhalten Sie vier harte Prüfpunkte:

• Der Prozess läuft unter dem erwarteten Konto.
• Der Prozess verwendet den erwarteten Pfad und das Arbeitsverzeichnis.
• Der erwartete Port lauscht tatsächlich.
• Standardausgabe und Fehlerausgabe sind dauerhaft auffindbar.

Bei einer Web UI muss zusätzlich die Adresse aus dem Remote-Netz geprüft werden. Ein lokaler Listener beweist noch nicht, dass Firewall, Tunnel, Portweiterleitung oder Bind-Adresse den Zugriff erlauben. Prüfen Sie deshalb nicht nur localhost, sondern den real vorgesehenen Zugriffsweg. Für sensible Oberflächen sollte der Zugriff nicht unnötig auf alle Netzwerkschnittstellen erweitert werden.

Bei einer Headless-Aufgabe ist der Erfolg anders zu bewerten: Ein Prozess, der endet, kann korrekt gearbeitet haben. Entscheidend sind Exit-Status, erwartete Ausgabedatei, Statusdaten und ein plausibler Logeintrag. Eine Web UI und ein Headless-Lauf benötigen daher getrennte Abnahmekriterien.

Wenn die Seite geöffnet werden kann, aber kein Modellaufruf oder keine Arbeitsaufgabe funktioniert, ist der Prozessstart bereits bestätigt, die Anwendung jedoch noch nicht betriebsbereit. Prüfen Sie nacheinander:

1. Liest der Prozess das erwartete Profile?
2. Liegt das Arbeitsverzeichnis auf dem richtigen Workspace?
3. Ist die Credential-Quelle im launchd-Kontext lesbar?
4. Enthält das Fehlerlog einen Authentifizierungs-, Netzwerk- oder Pfadfehler?
5. Schreibt die Aufgabe in ein Verzeichnis, das der Benutzer bearbeiten darf?
6. Wird vielleicht eine alte Statusdatei oder ein bereits belegter Lock verwendet?
7. Stimmen Web-Modus und Headless-Argumente mit der installierten Version überein?

Starten Sie danach genau eine risikoarme Modellaufgabe. Für Web-Modus genügt ein kleiner Test mit klar erkennbarem Ergebnis. Für Headless-Modus sollten Sie die Aufgabe so wählen, dass Exit-Status und Artefakt eindeutig kontrolliert werden können. Verwenden Sie keine produktiven Daten, solange Credentials, Logs und Arbeitsverzeichnis nicht bestätigt sind.

Die Trennung zwischen „Prozess läuft“ und „Harness-Aufgabe funktioniert“ ist der wichtigste Unterschied dieser Anleitung. Ein grüner Prozessstatus darf nicht als fachliche Abnahme verwendet werden.

KeepAlive kann einen Prozess nach einem Absturz erneut starten, aber es setzt keine unterbrochene Modellaufgabe fort. Ob ein Web-Arbeitsbereich, eine Session, ein Jobstatus oder ein Artefakt erhalten bleibt, hängt vom jeweiligen Harness-Modus und dessen Speicherstrategie ab.

Testen Sie deshalb vier Situationen getrennt:

• Kontrollierter Stop: Stoppen Sie den Job mit der vorgesehenen Methode und prüfen Sie, ob kein zweiter Prozess übrig bleibt.
• Abnormaler Exit: Beenden Sie nur den Testprozess unerwartet und beobachten Sie, ob ein neuer Prozess entsteht.
• Abmeldung und erneute Anmeldung: Prüfen Sie, ob der LaunchAgent in der erwarteten Benutzersitzung wieder geladen wird.
• Vollständiger Neustart: Kontrollieren Sie nach dem Hochfahren Prozess, Port, Logs und eine minimale Aufgabe.

Notieren Sie nicht nur „wieder verfügbar“, sondern auch:

• Zeitpunkt des Neustarts;
• sichtbarer Fehler im Log;
• ob Profile und Credentials erneut gelesen wurden;
• ob der Port von einem alten Prozess blockiert war;
• ob eine Aufgabe neu begonnen, fortgesetzt oder manuell freigegeben werden musste.

Ein automatischer Prozessneustart ist keine Aufgabenwiederherstellung. Wenn der Harness-Zustand nur im Speicher lag, kann launchd den Prozess zwar erneut starten, aber den verlorenen Arbeitsschritt nicht rekonstruieren.

• [ ] Web UI, Headless-Aufgabe oder Automatisierungsprozess eindeutig als Verwaltungsziel festgelegt.
• [ ] Absolute Pfade für Startprogramm, Node, npx oder dsh ermittelt.
• [ ] Arbeitsverzeichnis, Profile und Statuspfade dokumentiert.
• [ ] Normaler Benutzer als erste LaunchAgent-Identität gewählt.
• [ ] plist mit plutil -lint geprüft.
• [ ] Datei besitzt den erwarteten Eigentümer und keine unnötig weit gefassten Rechte.
• [ ] API Key nicht in plist, Kommandozeile oder Standardlog hinterlegt.
• [ ] Standardausgabe und Fehlerausgabe in wartbaren Pfaden gespeichert.
• [ ] Prozessidentität mit launchctl print oder Prozessliste bestätigt.
• [ ] Listener und tatsächlicher Remote-Zugriffsweg geprüft.
• [ ] Eine risikoarme Modellaufgabe erfolgreich abgeschlossen.
• [ ] Kontrollierter Stop ohne verbleibende Doppelinstanz getestet.
• [ ] Abnormaler Exit und anschließender Prozessneustart geprüft.
• [ ] Erneute Anmeldung und vollständiger Neustart getestet.
• [ ] Unterschied zwischen Prozesswiederherstellung und Aufgabenfortsetzung dokumentiert.
• [ ] Upgrade-, Deaktivierungs- und Rückfallbefehl schriftlich festgehalten.

Die folgende Tabelle hilft bei der Auswahl des passenden macOS-Mechanismus. Sie ist keine Empfehlung, jeden Fall systemweit zu betreiben.

Apple dokumentiert außerdem, dass moderne App-Service-Strukturen zwischen Agents und Daemons unterscheiden und die jeweilige plist dem passenden Kontext zugeordnet werden muss. Die Übersicht zur Verwaltung von App-Services ist für eigene Installationspakete relevant; für eine manuell verwaltete Benutzer-plist bleibt die Kontextprüfung entscheidend.

Vor einem Upgrade stoppen Sie den alten Job kontrolliert, prüfen den belegten Port und sichern die bisherigen Logs. Anschließend wechseln Sie den Startpfad auf die neue Version und laden den Agent erneut. Mehrere Instanzen desselben Web-Dienstes dürfen nicht parallel auf denselben Port oder dasselbe Statusverzeichnis zugreifen.

Ein mögliches Rückfallmuster lautet:

launchctl bootout "gui/<BENUTZER-UID>" \
  "/Users/<BENUTZER>/Library/LaunchAgents/<EIGENE-LABEL>.plist"

mv "<NEUER-STARTPFAD>" "<BACKUP-ODER-ALTER-STARTPFAD>"
# Danach nur den zuvor geprüften alten Startweg aktivieren.

Die konkrete Syntax muss zum installierten macOS und zur verwendeten Ladeart passen. Bewahren Sie die alte plist, die vorherige Startzeile und die letzten relevanten Logs getrennt voneinander auf. Entfernen Sie die Agent-Datei erst, wenn klar ist, wie der Dienst manuell gestartet und beendet wird.

Für die endgültige Abnahme zählt nicht der einzelne erfolgreiche Terminalstart. Der stärkere Nachweis ist eine vollständige Kette: Neustart des Remote Mac, automatische Anmeldung des vorgesehenen Kontos, Prozessstart, erreichbare Web UI oder korrekter Headless-Exit, erfolgreiche risikoarme Aufgabe und nachvollziehbarer Logeintrag.

Wenn der aktuelle Mac dauerhaft laufen muss, entstehen bei einer lokalen oder selbst verwalteten Umgebung dennoch reale Nachteile: Die Maschine benötigt ein verlässlich angemeldetes Benutzerkonto, Strom- und Netzwerkunterbrechungen müssen überwacht werden, und ein Upgrade kann den Pfad von Node, npx oder dsh verändern. Ein Root-Dienst verschärft zusätzlich die Rechte- und Credential-Frage. Für kurze Testfenster, reproduzierbare Abnahmen oder einen klar begrenzten Nutzungszeitraum kann das Mieten eines vorbereiteten Remote Mac über JEXCLOUD deshalb organisatorisch sauberer sein, sofern Sie die Übergabe, Zugriffskontrolle und Laufzeit vorher festlegen. Einen Überblick über verfügbare Remote-Mac-Umgebungen von JEXCLOUD können Sie als nächsten Planungsschritt heranziehen.

Entscheidend ist, dass Sie nicht für jede Umgebung dieselbe Betriebsform erzwingen: Langfristige, dauerhaft hohe Last oder benötigte physische Schnittstellen sprechen eher für einen eigenen Mac. Für temporäre DeepSeek-Harness-Tests, eine kontrollierte Web-UI-Abnahme oder einen zeitlich begrenzten Headless-Lauf ist eine klar abgegrenzte Remote-Mac-Umgebung häufig leichter zu dokumentieren. Falls Ihr vorhandener Mac kein stabiles Dauerfenster bietet, prüfen Sie vor der Buchung zuerst Mietoptionen für Remote Macs und übernehmen Sie die hier beschriebene Checkliste unverändert in das Abnahmeprotokoll.