DeepSeek Harness auf einen Cloud-Mac migrieren

Die Projektdateien sind auf dem neuen Mac sichtbar, aber der Agent findet das falsche Repository, das Modell antwortet nicht oder ein Plugin startet nicht.

Die schnellste sichere Lösung: DeepSeek Harness auf einen Cloud-Mac nicht als vollständige Ordnerkopie migrieren. Legen Sie zuerst eine neue, rücksetzbare Zielumgebung an. Übertragen Sie Arbeitsbereich, Konfiguration, Zugangsdaten-Referenzen, Plugins und Sitzungsprotokolle getrennt. Starten Sie die Abnahme mit einer neuen Sitzung und verschieben Sie laufende Agent-Aufgaben erst nach erfolgreicher Prüfung.

Für wen diese Anleitung gedacht ist:
Lokale Tester, die aus einem Experiment einen dauerhaft erreichbaren Agent-Betrieb machen möchten.
Betreiber, die Sitzungsprotokolle, Plugins und Prüfpfade erhalten müssen.
Projektverantwortliche, die vor der Migration festlegen müssen, welche Zustände kopiert, neu erzeugt oder bewusst verworfen werden.

Zuletzt aktualisiert am 18.08.2026. Die technischen Aussagen wurden gegen die offizielle README, die Architektur-, Provider- und Python-SDK-Dokumentation geprüft.

[ SECTION_01 ] Warum eine vollständige Verzeichnis-Kopie häufig scheitert

DeepSeek Harness befindet sich laut offizieller Projektbeschreibung weiterhin in der Developer Preview. Die Dokumentation warnt ausdrücklich vor kompatibilitätsbrechenden Änderungen. Eine lokale Struktur, die heute funktioniert, ist deshalb kein verlässliches Migrationspaket für eine andere Version oder einen anderen Rechner. Offizieller Projektstatus und Startanleitung

Das typische Fehlerbild besteht aus mehreren gleichzeitig sichtbaren, aber getrennt verursachten Problemen:

Beobachtung auf dem Cloud-Mac	Wahrscheinliche Ursache	Konsequenz
Repository wird angezeigt, der Agent bearbeitet aber einen anderen Ordner	Abweichender absoluter Pfad oder falsches Startverzeichnis	Dateien können im falschen Projekt gelesen oder geändert werden
Modellkarte ist vorhanden, jede Anfrage endet aber mit einem Anmelde- oder Modellfehler	Zugangsdaten fehlen, Credential-Referenz zeigt ins Leere oder Provider-ID wurde geändert	Konfiguration sieht korrekt aus, ist aber nicht ausführbar
Oberfläche startet, ein Plugin fehlt oder der Start bricht ab	Andere Runtime-Version, fehlende Abhängigkeit oder geänderte Plugin-Schicht	Ein Komplett-Reinstall verschleiert die eigentliche Ursache
Sitzungsverlauf ist sichtbar, eine Fortsetzung verhält sich unerwartet	Sitzungsformat, Modell, Provider oder Plugin-Komposition hat sich verändert	Historie bleibt lesbar, ist aber nicht automatisch sicher fortsetzbar

Die Architektur ist für diese Trennung entscheidend: Arbeitsbereich, Modelladapter, Tool-Registry, Session Log, Agent-Schleife und Berechtigungslogik sind unterschiedliche Bestandteile der Plugin-Komposition. Die offizielle Architektur beschreibt außerdem, dass die laufende Konfiguration aus mehreren geordneten Ebenen zusammengesetzt wird. Architekturdokumentation zu Plugins, Profilen und Sitzungsprotokollen

Vor dem ersten Kopiervorgang sollte deshalb eine Asset-Liste angelegt werden:

Asset-Klasse	Typische Inhalte	Migrationsempfehlung	Abnahmekriterium
Projektdateien	Git-Arbeitsbaum, Abhängigkeitserklärungen, lokale Skripte	Reproduzierbar aus Repository oder geprüfter Sicherung herstellen	Branch, Commit und Änderungsstand stimmen
Harness-Konfiguration	Profil, Provider, Modell, Patches, Umgebungsvariablen	Struktur dokumentieren, danach auf dem Zielsystem neu anwenden	--dump-config zeigt die erwartete Komposition
Geheimnisse	API-Schlüssel, Token, native Zugangsdaten	Nicht kopieren; im Zielsystem neu injizieren	Prozess liest die Zielreferenz, ohne Klartext zu protokollieren
Plugins und Runtime	Paketversionen, Plugin-Liste, Build-Artefakte	Versionen erfassen und schrittweise neu installieren	Basisprofil startet vor Zusatz-Plugins
Sitzungsprotokolle	Kontext, Modellanfragen, Tool-Aufrufe, Ergebnisse	Original unverändert sichern, zunächst nur mit Kopie testen	Historie ist lesbar; Fortsetzung nur nach neuer Abnahme

[ SECTION_02 ] Arbeitsbereich und Pfad zuerst festnageln

Ein Agent arbeitet nicht „am Projekt“ im abstrakten Sinn. Er arbeitet in einem konkreten Dateisystembereich. Die offizielle Web-UI-Dokumentation weist darauf hin, dass der aufrufende Ordner als Standard-Dateisystemort dient und zunächst kein Arbeitsbereich ausgewählt ist. Offizielle Anleitung zur Arbeitsbereichsauswahl

Vor der Migration müssen daher vier Werte festgehalten werden:

1. Absoluter Quellpfad.
2. Absoluter Zielpfad.
3. Aktiver Git-Branch.
4. Status nicht übertragener Änderungen.

Der Zielpfad muss nicht identisch sein. Er muss aber bewusst gewählt und dokumentiert werden. Ein relativer Pfad oder ein symbolischer Link ohne Prüfnotiz reicht für einen unbeaufsichtigten Agentenbetrieb nicht aus.

Nach dem Aufbau des Zielarbeitsbereichs sollte die Reihenfolge so aussehen:

1. Repository oder geprüfte Sicherung auf den Cloud-Mac bringen.
2. Branch und Commit vergleichen.
3. Uncommitted Changes der lokalen Umgebung separat archivieren.
4. DeepSeek Harness mit dem Zielordner starten.
5. Arbeitsbereich in der Oberfläche ausdrücklich auswählen.
6. Nur eine lesende Aufgabe senden: Repository-Struktur, Branch und relevante Pakete zusammenfassen lassen.
7. Erst danach Bearbeitung, Shell-Aufrufe oder Hintergrundaufgaben freigeben.

Ein brauchbarer Lesetest fragt nicht nur nach einer allgemeinen Zusammenfassung. Der Agent sollte den absoluten Projektpfad, den Branch-Namen und eine absichtlich ausgewählte Datei nennen. Stimmen diese drei Punkte nicht, wird die Migration angehalten. Der häufigste Fehler wäre dann nicht ein defektes Modell, sondern ein falsch aufgelöstes Arbeitsverzeichnis.

Für den Cloud-Mac-Betrieb sollte der Arbeitsbereich außerdem isoliert sein. Das offizielle Python-SDK-Beispiel weist darauf hin, dass eine großzügige Dateisystemberechtigung nur in einer wegwerfbaren Umgebung oder einem Container eingesetzt werden sollte. Python-SDK-Anleitung zu cwd, Sitzungsverzeichnis und Berechtigungen

[ SECTION_03 ] DeepSeek Harness auf einen Cloud-Mac mit getrennten Konfigurationen übertragen

Nicht jede Einstellung besitzt dieselbe Lebensdauer. Besonders wichtig ist die Unterscheidung zwischen Anzeigeeinstellung, Provider-Identität, Modellstandard und Credential-Referenz.

Die offizielle Provider-Anleitung nennt mehrere harte Grenzen:

• Der eigentliche API-Schlüssel wird schreibgeschützt behandelt und unter $DSH_HOME/.credentials.yaml abgelegt.
• Die übrige Einstellung speichert nur eine Referenz auf das Credential.
• Eine Provider-ID ist dauerhaft relevant, weil gespeicherte Sitzungen, Modellstandards und Credential-Referenzen sie verwenden.
• Ein bereits gestarteter Verlauf behält das Modell, das in seinem eigenen Protokoll aufgezeichnet wurde. Offizielle Provider- und Credential-Dokumentation

Konfiguration	Darf strukturell übernommen werden?	Muss im Zielsystem geprüft oder neu erzeugt werden?	Typischer Fehler
Profilname und Bundle-Reihenfolge	Ja, als dokumentierte Vorlage	Ja	Andere Schicht überschreibt die lokale Anpassung
Provider-ID	Nur unverändert	Ja	Alte Sitzungen und Defaults zeigen auf einen nicht vorhandenen Provider
Anzeigename und Modellstandard	Meist ja	Ja	Neue Sitzung startet mit falschem Modell
API-Schlüssel	Nein	Ja	Geheimnis landet in Archiv, Shell-Historie oder Log
Umgebungsvariablen	Nein, nur Namen dokumentieren	Ja	Zielprozess sieht die Variable nicht
settings.yaml-Patches	Mit Versionsnotiz	Ja	Veraltetes Feld wird ignoriert oder blockiert den Start

Die richtige Reihenfolge lautet:

1. Auf dem Quellsystem Provider-ID, Modell-ID, Basis-URL und verwendetes Profil dokumentieren.
2. Den Klartextschlüssel aus der Sicherung ausschließen.
3. Auf dem Cloud-Mac das Profil und die Provider-Struktur anlegen.
4. Zugangsdaten über die vorgesehene Oberfläche oder eine kontrollierte Umgebungsvariable setzen.
5. Prüfen, aus welcher Quelle der laufende Prozess das Credential tatsächlich liest.
6. Eine neue Sitzung mit einer kleinen Modellanfrage starten.
7. Erst danach gespeicherte Sitzungsdaten in einer Kopie öffnen.

Das Umbenennen eines Providers ist keine harmlose Aufräumaktion. Wenn eine neue Bezeichnung nötig ist, sollte ein neuer Provider angelegt und der alte erst nach einer kontrollierten Prüfung entfernt werden. Ein Modellaufruf in einer neuen Sitzung ist Pflicht, weil ein bereits gespeicherter Verlauf nicht automatisch die neue Provider-Konfiguration übernimmt.

[ SECTION_04 ] Können Sitzungsprotokolle auf einem anderen Mac weiterlaufen?

Lesen: häufig ja; sicher fortsetzen: nicht automatisch. Die offizielle Architektur beschreibt das Session Log als Quelle für den Modellkontext. Daraus werden Verlauf, Wiederaufnahme, Forks, Transkripte und Persistenz abgeleitet. Ein Protokoll ist daher nicht bloß eine Chat-Exportdatei, sondern ein Ausführungszustand mit Kontext und Tool-Ereignissen. Dokumentation zum Session Log

Das Python-SDK beschreibt für seine Beispielkomposition zusätzlich ein JSONL-Sitzungsprotokoll. Es trennt workspace, session_root und session_id. Eine wiederverwendete Sitzungs-ID setzt dieselbe dauerhafte Unterhaltung fort; eine neue ID erzeugt eine unabhängige Aufgabe. SDK-Dokumentation zu Sitzungs-IDs und JSONL-Persistenz

Für die Migration bedeutet das:

• Das Originalprotokoll bleibt unverändert als Beweissicherung erhalten.
• Eine Arbeitskopie wird auf dem Cloud-Mac nur lesend geöffnet.
• Provider-ID, Modell, Plugin-Komposition und Arbeitsbereich werden vor einer Fortsetzung verglichen.
• Bei abweichender Version wird zunächst eine neue Sitzung angelegt.
• Die alte Sitzung dient dann als Kontextquelle und Prüfspur, nicht als automatisch fortsetzbarer Prozess.

Sitzungsprotokolle können außerdem sensible Inhalte enthalten: Systemanweisungen, Dateiinhalte, Befehle, Tool-Ergebnisse und möglicherweise personenbezogene Daten. Für DSGVO-relevante Projekte gehören sie in einen kontrollierten Speicherbereich mit begrenzten Zugriffsrechten. Sie dürfen nicht unbesehen in ein allgemeines Projektarchiv oder in ein öffentliches Repository gelangen.

[ SECTION_05 ] Plugins und Runtime kontrolliert wiederherstellen

Ein Plugin kann technisch installiert sein und trotzdem nicht verwendbar sein. Ursachen sind beispielsweise eine geänderte Runtime, eine fehlende native Abhängigkeit, eine andere Profilreihenfolge oder ein Konfigurationsfeld, das in der aktuellen Version nicht mehr gilt.

Die offizielle Architektur macht deutlich, dass Plugins nicht nur Zusatzfunktionen liefern. Sie können Modelladapter, Tools, Sitzungsverwaltung, Sandbox, Genehmigungslogik und Benutzeroberfläche bereitstellen. Eine Plugin-Abweichung verändert daher unter Umständen den gesamten Agentenlauf.

Die Wiederherstellung sollte nicht mit einer Vollinstallation aller Erweiterungen beginnen:

1. Quellversion von DeepSeek Harness und Runtime notieren.
2. Profilname, Bundle-Reihenfolge und eigene Patch-Dateien dokumentieren.
3. Plugin-Namen, Versionen und Installationsquellen erfassen.
4. Zielumgebung mit dem offiziellen Basisprofil starten.
5. Modellaufruf und Arbeitsbereich ohne Zusatz-Plugin prüfen.
6. Plugins einzeln oder in kleinen, logisch zusammengehörigen Gruppen hinzufügen.
7. Nach jeder Gruppe Start, Modellanfrage und Werkzeugliste kontrollieren.
8. Bei einem Fehler auf die letzte funktionierende Kombination zurücksetzen.

Wiederherstellungsstufe	Inhalt	Ergebnisbewertung
Basis	Kernprofil, Arbeitsbereich, Modell, minimale Berechtigungen	Muss ohne Zusatz-Plugin starten
Erweiterung	Ein Plugin oder eine klar abgegrenzte Plugin-Gruppe	Start und erwartete Werkzeuge vorhanden
Arbeitsbetrieb	Lesetest, kontrollierte Änderung, genehmigter Befehl	Aktion wird korrekt protokolliert
Dauerbetrieb	Neustart, neue Sitzung, optional geprüfte alte Sitzung	Zustand bleibt nach Neustart nachvollziehbar

Wiederholtes vollständiges Neuinstallieren ist kein Diagnoseverfahren. Wenn das Basisprofil funktioniert und ein Zusatz-Plugin den Start bricht, ist die Ursache eingegrenzt. Genau diese Grenze sollte dokumentiert werden.

[ SECTION_06 ] Die Abnahme des Cloud-Mac erfolgt in fünf Stufen

Die Migration ist erst beendet, wenn die Zielumgebung nicht nur startet, sondern den geplanten Agentenbetrieb reproduzierbar abbildet.

• [ ] Quellzustand sichern: Repository, Branch, Commit, Konfigurationsdateien, Plugin-Liste und originale Sitzungsprotokolle getrennt archivieren.
• [ ] Zielumgebung isolieren: Eigenen Cloud-Mac-Arbeitsbereich anlegen und eine Rückfallmöglichkeit offenhalten.
• [ ] Arbeitsbereich abnehmen: Absoluten Pfad, Branch, Commit und absichtlich ausgewählte Datei per Lesetest bestätigen.
• [ ] Konfiguration vergleichen: Profil, Provider-ID, Modell-ID, Basis-URL, Patch-Reihenfolge und Umgebungsvariablen dokumentiert abgleichen.
• [ ] Credential-Quelle prüfen: Ohne Klartextausgabe feststellen, ob der laufende Prozess die erwartete Credential-Referenz verwendet.
• [ ] Neue Modell-Sitzung ausführen: Kleine Anfrage senden und Antwort, Modell und Provider im Abnahmeprotokoll notieren.
• [ ] Plugin-Basis prüfen: Erst das Basisprofil, danach jede Erweiterung einzeln testen.
• [ ] Kontrollierte Änderung ausführen: Eine ungefährliche Datei ändern lassen und die Änderung vor dem Schreiben genehmigen.
• [ ] Befehlsfreigabe testen: Einen harmlosen, klar begrenzten Befehl ausführen und prüfen, ob Genehmigung und Ergebnis protokolliert werden.
• [ ] Neustart simulieren: Prozess beenden, Cloud-Mac-Umgebung neu starten und danach dieselbe Prüfkette wiederholen.
• [ ] Sitzungskopie prüfen: Protokoll nur aus einer Kopie lesen; bei Unsicherheit eine neue Sitzung statt einer direkten Fortsetzung verwenden.
• [ ] Rückfallbedingung festlegen: Bei falschem Arbeitsbereich, fehlendem Credential, Plugin-Startfehler oder abweichendem Modell sofort auf die Quellumgebung zurückschalten.
• [ ] Quellsystem behalten: Die lokale Umgebung erst aus dem Betrieb nehmen, wenn die Zielumgebung vollständig abgenommen und die Übergabe dokumentiert ist.

Das Abnahmeprotokoll sollte mindestens Version, Profil, Provider-ID, Modell, Arbeitsbereich, Plugin-Zustand, Sitzungs-ID, Neustartergebnis und offene Abweichungen enthalten. Ein Screenshot der Oberfläche ersetzt diese Angaben nicht.

[ SECTION_07 ] Cloud-Mac oder lokale Umgebung: Welche Lösung passt?

Die Migration auf einen Cloud-Mac ist besonders sinnvoll, wenn ein Agent dauerhaft erreichbar sein, ein Team auf denselben Arbeitsbereich zugreifen oder ein lokales Notebook nicht ständig eingeschaltet bleiben soll. Sie ist weniger geeignet, wenn ein Projekt dauerhaft unter hoher Last läuft, besondere physische Schnittstellen benötigt oder sensible Daten aus organisatorischen Gründen nicht außerhalb der lokalen Umgebung verarbeitet werden dürfen.

Lösung	Stärken	Reale Nachteile	Geeignet für
Lokaler Mac	Direkter Zugriff, keine zusätzliche Fernverbindung	Gerät muss verfügbar bleiben; lokale Änderungen sind schwerer zu standardisieren	Einzeltests und kurzfristige Entwicklung
Cloud-Mac	Getrennter Arbeitsbereich, Fernzugriff, reproduzierbare Zielumgebung	Zusätzliche Netzwerk-, Zugriffs- und Migrationsprüfung	Dauerhafte Agent-Aufgaben und Teamzugriff
Sofortige Komplettkopie	Schnell auf den ersten Blick	Hohe Gefahr von falschen Pfaden, Geheimnislecks und inkompatiblen Sitzungen	Nur für unkritische Wegwerfexperimente

Für einen kontrollierten Testlauf kann eine Mac-Mini-Umgebung von NOVAKVM als getrennte Zielumgebung dienen. Entscheidend ist nicht die bloße Verfügbarkeit des Rechners, sondern dass die Migration vor dem Umschalten der laufenden Aufgaben nachvollziehbar abgenommen wird. Weitere Mac-Optionen finden Sie auf der deutschen NOVAKVM-Übersicht.

Wer dagegen eine langfristige, gleichbleibende Schwerlastumgebung benötigt, sollte Mietdauer, Datenhaltung, Zugriffsmodell und Wiederherstellungsprozess gegen den Kauf eines eigenen Macs abwägen. Bei kurzfristigen Experimenten oder einer geplanten Migration ist ein gemieteter Cloud-Mac jedoch oft sauberer als das direkte Umbauen des einzigen lokalen Systems: Das lokale Setup bleibt als Rückfallpunkt erhalten, während die Zielumgebung unabhängig geprüft werden kann.

Der sicherste nächste Schritt ist deshalb kein sofortiger Austausch des alten Rechners. Bereiten Sie zunächst einen separaten Cloud-Mac vor, migrieren Sie Arbeitsbereich, Provider, Plugins und Sitzungsprotokolle in dieser Reihenfolge und schalten Sie kontinuierliche Agent-Aufgaben erst nach bestandener Neustart- und Rückfallprüfung um.