2026 DeepSeek Harness parallel Code ändern: Git worktree oder unabhängige Klone?

Die wichtigste Fehlannahme lautet: Ein anderer Verzeichnispfad bedeute automatisch einen vollständig getrennten Lauf. Das trifft bei Git worktree nicht zu. Git beschreibt einen Worktree als zusätzlichen Arbeitsbaum, der an dasselbe Repository angeschlossen ist. Arbeitsbaum-spezifische Informationen wie HEAD und der Index werden getrennt geführt, während Repository-Objekte und viele Referenzen gemeinsam bleiben. Auch die Repository-Konfiguration ist standardmäßig geteilt. Die aktuelle Git-Dokumentation zu git worktree beschreibt diese Aufteilung ausdrücklich.

Für DeepSeek Harness ist zusätzlich wichtig, zwischen einer Produktfunktion und einer Betriebsregel zu unterscheiden. Das offizielle Repository bezeichnet DeepSeek Harness als Developer Preview und weist auf mögliche inkompatible Änderungen hin. Es zeigt den Betrieb aus einem Repository-Checkout, bestätigt aber nicht, dass das Werkzeug Worktrees automatisch anlegt, Sitzungen daran bindet oder sie nach Abschluss sicher entfernt. Das offizielle DeepSeek-Harness-Repository dient hier als maßgebliche Produktquelle.

Daraus ergeben sich drei getrennte Ebenen:

1. Code-Arbeitsbereich: Welche Dateien darf der Agent verändern?
2. Prozess- und Ressourcenbereich: Welche Ports, Build-Verzeichnisse, temporären Dateien und Hintergrundprozesse werden verwendet?
3. Sicherheitsgrenze: Welche Benutzeridentität, Schlüssel, Kundendaten und Netzwerkrechte sind erreichbar?

Ein Worktree löst primär die erste Ebene. Er ist kein Sandbox-Mechanismus und ersetzt weder Prozessisolation noch eine DSGVO-konforme Zugriffstrennung.

Für eine echte Dateisystemtrennung ist ein unabhängiger Klon verständlicher, weil jeder Auftrag seinen eigenen Repository-Checkout erhält. Die offizielle Dokumentation zu git clone macht jedoch ebenfalls deutlich, dass ein Klon nicht automatisch globale Caches, Benutzerkonten, Schlüsselbunde, Netzwerkrechte oder laufende Prozesse trennt. Der Klon ist daher eine stärkere Repository-Grenze, aber noch keine vollständige Sicherheitsumgebung.

Bei zwei kleinen, voneinander unabhängigen Änderungen am selben Repository ist ein eigener Worktree meist der sinnvollste Start. Jede Sitzung muss bereits vor dem Agentenstart an einen konkreten Pfad und einen eigenen Branch gebunden werden. Ein allgemeines Muster sieht so aus:

git worktree add -b <branch-a> <path-worktree-a> <start-point>
git worktree add -b <branch-b> <path-worktree-b> <start-point>

<path-worktree-a>, <path-worktree-b>, <branch-a>, <branch-b> und <start-point> sind Platzhalter und müssen durch die tatsächlichen Werte der Umgebung ersetzt werden. Die offizielle Syntax unterstützt das Erzeugen eines neuen Branches mit -b; alternativ kann ein bestehender Branch verwendet werden, sofern er nicht bereits in einem anderen Worktree ausgecheckt ist.

Die Zuordnung sollte nicht nur im Dateinamen stehen. Für jede DeepSeek-Harness-Sitzung gehören mindestens folgende Informationen in den Auftrag:

• Arbeitsbereichspfad;
• Branchname;
• Ausgangscommit oder Zielbranch;
• erlaubter Dateibereich;
• erwartetes Ergebnis, etwa Commit, Patch oder Analysebericht;
• verantwortliche Person für Review und Merge;
• erlaubter Test- und Buildumfang.

Damit lässt sich die Frage, ob mehrere Sitzungen dasselbe Repository verwenden dürfen, eindeutig beantworten: Ja, aber nicht dasselbe Arbeitsverzeichnis und nicht denselben Branch als unkontrollierte Schreibfläche.

Diese gemeinsamen Bereiche bleiben riskant

Auch bei getrennten Worktrees können sich Sitzungen gegenseitig beeinflussen:

• Repository-Konfiguration: Git dokumentiert, dass die Konfigurationsdatei standardmäßig gemeinsam genutzt wird. Sitzungsabhängige Einstellungen müssen gegebenenfalls über extensions.worktreeConfig und git config --worktree getrennt werden. Die dazugehörigen Optionen sind in der offiziellen Dokumentation zu git config beschrieben.
• Externe Build-Verzeichnisse: Ein Buildsystem kann Ausgaben außerhalb des Worktrees speichern, etwa in einem zentralen Cache oder einem festen temporären Pfad.
• Abhängigkeitsverzeichnisse: Verzeichnisse wie node_modules, virtuelle Python-Umgebungen oder eigene Paketinstallationen sind nicht automatisch isoliert, nur weil der Git-Arbeitsbaum getrennt ist.
• Ports und Hintergrundprozesse: Zwei Entwicklungsserver können denselben Port beanspruchen. Das offizielle DeepSeek-Harness-Repository nennt für die Web-Oberfläche standardmäßig Port 3080; parallele Instanzen benötigen deshalb eine bewusste Portzuweisung.
• Submodule: Mehrfach-Checkouts bei Superprojekten haben weiterhin Einschränkungen, und die Unterstützung für Submodule ist nicht in jedem Szenario vollständig. In einem solchen Repository sollte nicht ohne Testlauf auf Worktrees gesetzt werden.

Ein zusätzlicher Prüfpunkt ist der tatsächliche Git-Status. Für Automationsprozesse sollte die Plattform nicht nur den Pfad, sondern auch geänderte und nicht versionierte Dateien erfassen. git status liefert dafür die offizielle Statusschnittstelle. Der Status allein beweist allerdings nicht, dass keine externen Prozesse oder Artefaktverzeichnisse aktiv sind.

In einem Team verhindert Verzeichnisisolierung allein keine organisatorischen Konflikte. Wenn zwei Agenten dieselbe Datei ändern, kann Git zwar zwei Branches sauber führen, aber die spätere Zusammenführung bleibt konfliktanfällig. Noch schwieriger wird es, wenn ein Agent eine Schnittstelle verändert und ein zweiter gleichzeitig die darauf aufbauenden Tests oder Aufrufer aktualisiert.

Der Aufgabenvertrag sollte daher vier Verantwortungen ausdrücklich festhalten:

Die Anforderungen an den Arbeitsbereich unterscheiden sich nach Aufgabentyp:

• Codeänderung: eigener Worktree und eigener Branch sind zwingend, weil uncommittete Änderungen entstehen.
• Nur-Lese-Analyse: Ein gemeinsamer Klon kann vertretbar sein, sofern der Prozess garantiert keine generierten Dateien, Logs oder Lock-Dateien im Repository anlegt. Für reproduzierbare Ergebnisse bleibt ein eigener, schreibgeschützter Arbeitsbereich dennoch sauberer.
• Testreparatur: eigener Worktree, eigenes temporäres Verzeichnis und eigene Prozessgruppe; Tests verändern häufig Snapshots, Datenbanken oder generierte Dateien.
• Build- und Release-Aufgabe: eigener Artefaktpfad, eigene Portbelegung und klare Veröffentlichungserlaubnis; ein gemeinsamer Branch ist hier keine ausreichende Kontrolle.

Wenn dieselbe Datei häufig verändert wird, ein Agent auf uncommittete Ergebnisse eines anderen angewiesen ist oder beide dieselbe Datenbank beziehungsweise denselben Dienst nutzen, sollte das Team die betreffende Phase seriell ausführen. Parallelisierung ist nur dann ein Vorteil, wenn die spätere Zusammenführung weniger Aufwand verursacht als das Warten.

Für Änderungen mit hoher Überschneidung sollte außerdem nicht versucht werden, einen gemeinsamen Arbeitsbaum durch zusätzliche Agentenanweisungen zu „disziplinieren“. Ein Agent kann sich an eine Vorgabe halten, aber ein laufender Test, ein Formatter oder ein Hintergrunddienst kann trotzdem Dateien verändern. Die belastbare Kontrolle entsteht aus einer Kombination von getrenntem Pfad, eindeutigem Branch, eigener Prozessgruppe und überprüfbarem Rückgabezustand.

Worktrees teilen Repository-Objekte. Das kann den Speicherbedarf gegenüber vollständig unabhängigen Klonen reduzieren, ist aber keine pauschale Zusage für geringeren Gesamtverbrauch: Abhängigkeiten, Build-Ausgaben, Testdaten und generierte Artefakte können weiterhin mehrfach entstehen. Die Entscheidung muss deshalb pro Pfad erfolgen.

Ein gemeinsamer Cache ist eher vertretbar, wenn er:

• ausschließlich bereits heruntergeladene, unveränderliche Pakete enthält;
• Integritäts- oder Prüfsummenvalidierung durch das jeweilige Werkzeug unterstützt;
• keine Zugangsdaten, Projektdateien oder sitzungsspezifischen Lock-Dateien speichert;
• nicht von einem Auftrag überschrieben oder bereinigt wird, während ein anderer ihn verwendet.

Task-spezifische Pfade sind dagegen erforderlich für:

• Build-Ausgaben;
• Testdatenbanken und Migrationsstände;
• Codegenerierung;
• lokale Konfigurationsdateien;
• Logs mit Kundendaten;
• temporäre Archive;
• laufende Entwicklungsserver.

Die Grundregel lautet: Download-Cache darf geteilt werden, Arbeitszustand nicht. Bei einer unabhängigen Klonstruktur ist der Repository-Zustand getrennt, aber auch dort bleiben Betriebssystem, Schlüsselbund, Benutzerrechte, Ports und globale Tool-Caches gemeinsam, wenn keine zusätzlichen Maßnahmen getroffen werden.

Ein Cache darf zudem nicht deshalb als sicher gelten, weil mehrere Jobs ihn nur lesen sollen. Entscheidend ist, ob das verwendete Werkzeug tatsächlich atomare Aktualisierung, Versionsprüfung und beschädigungsfreie Parallelzugriffe gewährleistet. Wenn diese Eigenschaften nicht dokumentiert sind, sollte der Cache mindestens nach Aufgabe, Toolchain oder Vertrauensbereich aufgeteilt werden. Bei Kundenprojekten mit unterschiedlichen Berechtigungen ist ein gemeinsamer Cache grundsätzlich zu vermeiden, weil auch Paketnamen, Pfade, Metadaten oder Logs sensible Informationen offenlegen können.

Für einen großen Build sollte deshalb nicht nur pwd geprüft werden. Der Prozess muss auch anzeigen, wo Git, Abhängigkeiten, Buildsystem und temporäre Dateien tatsächlich schreiben:

git rev-parse --show-toplevel
git rev-parse --git-dir
git rev-parse --git-common-dir
git worktree list --porcelain

Die Porzellan-Ausgabe von git worktree list ist für Skripte gedacht und eignet sich besser für eine automatisierte Bestandsaufnahme als eine rein formatierte Standardausgabe.

Eine automatisierte DeepSeek-Harness-Umgebung sollte Worktrees nicht lediglich in ein Verzeichnis schreiben. Die Plattform braucht eine nachvollziehbare Verantwortungskette.

Erstellung

1. Repository-Zustand aktualisieren und den erlaubten Ausgangspunkt festlegen.
2. Einen eindeutigen Branchnamen aus Auftrag oder Job-ID ableiten.
3. Den Worktree mit git worktree add erstellen.
4. Sitzungs-ID, Pfad, Branch und Ausgangscommit in einer Job-Datenbank oder einem Audit-Log speichern.
5. Abhängigkeitspfad, Buildpfad, Port und temporären Pfad festlegen.
6. Erst danach die DeepSeek-Harness-Sitzung mit genau diesem Arbeitsverzeichnis starten.

Die Plattform sollte einen Fehler bei der Branch- oder Pfadzuordnung nicht mit --force übergehen. Git schützt standardmäßig davor, einen bereits belegten Branch gleichzeitig in einem weiteren Worktree auszuchecken; --force hebt diese Sicherheitsprüfung auf und gehört daher in Ausnahmeprozesse mit manueller Freigabe.

Vor dem Start sollte der Dienst außerdem prüfen, ob der Ausgangspunkt tatsächlich dem vereinbarten Zielbranch entspricht. Ein formal sauberer Worktree aus dem falschen Commit ist organisatorisch ebenso problematisch wie ein gemeinsames Verzeichnis, weil der Agent dann auf einer unerwarteten Codebasis arbeitet und ein Review den Fehler möglicherweise erst spät erkennt.

Laufzeit

Während der Sitzung müssen mindestens folgende Zustände beobachtbar sein:

• aktiver Arbeitsbereich;
• aktiver Branch;
• laufende Prozesse und ihre Prozessgruppe;
• offene Ports;
• Status von Änderungen und untracked Dateien;
• verwendete Cache- und Artefaktpfade;
• letzte Agentenaktion und Abbruchgrund.

Die Sitzung darf nicht allein anhand eines sichtbaren Fensters als beendet gelten. Ein Hintergrundprozess kann weiterhin Dateien verändern, Ports belegen oder geheime Werte in Logs schreiben.

Bei einem Remote Mac sollte die Plattform zusätzlich die Benutzeridentität und den Schlüsselzugriff protokollieren, ohne geheime Inhalte in das Audit-Log zu schreiben. Ein Logeintrag darf festhalten, welcher Schlüssel oder welche Rolle verwendet wurde; der geheime Wert selbst gehört nicht in Sitzungsprotokolle, Build-Artefakte oder temporäre Diagnosearchive.

Rückgabe

Vor der Entfernung sollte der Automationsdienst:

git status --short
git worktree list --porcelain
git worktree remove <path-worktree>
git worktree prune --dry-run

ausführen. git worktree remove entfernt standardmäßig nur einen sauberen Worktree. Ein erzwungenes Entfernen mit --force darf nur erfolgen, wenn der Inhalt archiviert, verworfen oder ausdrücklich freigegeben wurde. Ein Worktree-Verzeichnis sollte nicht einfach manuell gelöscht werden, weil dabei Git-Metadaten zurückbleiben können; für verwaiste Einträge ist git worktree prune vorgesehen.

Die Reihenfolge ist wichtig: Zuerst müssen laufende Agenten- und Buildprozesse beendet werden, danach werden Status und Artefakte erfasst, anschließend erfolgt die Git-Bereinigung. Wird das Verzeichnis zuerst gelöscht, kann die Plattform später nicht mehr zuverlässig unterscheiden, ob Änderungen absichtlich verworfen, unvollständig übertragen oder durch einen Fehler verloren wurden.

Wichtig: Wenn die Rückgabe wegen uncommitteter Dateien, aktiver Prozesse oder beschädigter Verknüpfungen fehlschlägt, sollte die Plattform Beweise sichern und den Fall an eine verantwortliche Person übergeben. Ein automatisches Löschen kann den einzigen reproduzierbaren Zwischenstand eines Agenten vernichten.

Ein Worktree trennt Git-Arbeitsbereiche, aber keine Identitäten. Wenn zwei Projekte unterschiedliche Zugriffsstufen, API-Schlüssel, SSH-Schlüssel, Cloud-Rollen oder Kundendaten verwenden, bleiben diese Werte bei gemeinsamem macOS-Konto und gemeinsamem Remote Mac potenziell erreichbar.

Ein unabhängiger Klon erweitert die Dateisystemtrennung, löst aber ebenfalls nicht automatisch alle Sicherheitsfragen. Die Plattform sollte mindestens dann auf ein separates macOS-Konto oder eine eigene Mac-Umgebung wechseln, wenn:

• Projekte verschiedenen Kunden gehören;
• Rollen oder Schlüssel nicht gegenseitig sichtbar sein dürfen;
• Datenaufbewahrung und Löschung getrennt nachweisbar sein müssen;
• ein Kunde die Berechtigung unabhängig widerrufen können muss;
• Netzwerkzugriff oder VPN-Zugang unterschiedlich geregelt ist;
• ein Build vertrauliche Artefakte auf lokale Datenträger schreibt.

Die Entscheidung folgt damit nicht der Frage „Welcher Ordner ist schneller erstellt?“, sondern der Frage „Wer darf welche Daten und Prozesse sehen?“ Bei DSGVO-relevanten Projekten müssen außerdem Logs, temporäre Dateien und Cache-Inhalte in die Lösch- und Zugriffskontrolle einbezogen werden.

Ein unabhängiger Klon ist vor allem dann sinnvoll, wenn ein Auftrag eigene Lock-Dateien, Toolversionen oder Installationsverzeichnisse benötigt. Er sollte jedoch nicht als Ersatz für ein Berechtigungskonzept verkauft werden. Wenn zwei Klone unter demselben macOS-Konto laufen und dieselben Umgebungsvariablen, Schlüsselbundobjekte und Netzwerkfreigaben sehen, wurde die Sicherheitsgrenze nur teilweise verschoben.

Die folgende Tabelle dient als erste Einordnung. Sie ersetzt keinen Test mit dem tatsächlichen Repository, den verwendeten Abhängigkeiten und den realen Berechtigungen.

Vor dem produktiven Parallelbetrieb abhaken

• [ ] Jeder Agent besitzt einen eigenen Arbeitsbereichspfad.
• [ ] Jeder Agent arbeitet auf einem eindeutig benannten Branch.
• [ ] Die Sitzung speichert Arbeitsbereich, Branch und Ausgangscommit.
• [ ] Gemeinsame Git-Konfiguration wurde geprüft.
• [ ] Build- und Testausgaben liegen nicht in einem gemeinsamen Pfad.
• [ ] Ports und Hintergrundprozesse sind pro Aufgabe nachvollziehbar.
• [ ] Der gemeinsame Cache enthält keine Schlüssel oder Projektdateien.
• [ ] Abbruch beendet auch untergeordnete Prozesse.
• [ ] Uncommittete Änderungen werden vor der Rückgabe erfasst.
• [ ] git worktree remove wird vor manueller Verzeichnislöschung verwendet.
• [ ] Fehler bei der Rückgabe erzeugen einen Audit-Fall statt eines stillen Löschvorgangs.
• [ ] Kunden- und Projektberechtigungen wurden unabhängig vom Git-Modell bewertet.

Vor dem dauerhaften Einsatz sollte das Team nicht nur zwei Agenten starten und auf ein erfolgreiches Ergebnis hoffen. Ein kleiner Basistest muss dieselben Bedingungen prüfen, die später Probleme verursachen:

Wenn der Worktree-Test nur bei manueller Nacharbeit funktioniert, ist die Struktur für einen automatisierten Remote-Mac-Pool noch nicht reif. Wenn die Tests mit unterschiedlichen Zugangsdaten oder Kundendaten durchgeführt werden, sollte der Basistest direkt auf unabhängigen Klonen und getrennten Konten wiederholt werden.

Der Test sollte außerdem einen absichtlich abgebrochenen Lauf enthalten. Dabei wird geprüft, ob der Agent, der Buildprozess und mögliche Unterprozesse tatsächlich beendet werden, ob der Arbeitsbereich seinen Zustand behält und ob die Rückgabe trotz des Abbruchs nachvollziehbar bleibt. Ein erfolgreicher Normalfall sagt wenig über die Robustheit einer Plattform aus, wenn Abbrüche und verschmutzte Arbeitsbereiche nicht kontrolliert behandelt werden.

Für die Planung eines solchen Pools kann die Übersicht zu Remote-Mac-Arbeitsplätzen von NUKCLOUD als nächster organisatorischer Bezugspunkt dienen. Bei einer konkreten Bereitstellung sollte außerdem die regionale Übergabe, beispielsweise über Mac-Bereitstellung in US East, getrennt von der Repository-Entscheidung bewertet werden.

Für zwei kurzfristige Aufgaben im selben Repository lautet die belastbare Standardentscheidung: ein Worktree pro Aufgabe, ein Branch pro Worktree und eine DeepSeek-Harness-Sitzung pro Arbeitsbereich. Das reduziert Überschreibungen, ohne sofort für jeden kleinen Auftrag einen vollständigen Klon und eine eigene Umgebung zu verwalten.

Ein unabhängiger Klon ist die bessere Wahl, wenn Installationen, Lock-Dateien, Build-Artefakte oder Caches nicht gemeinsam genutzt werden dürfen. Bei unterschiedlichen Kunden, Berechtigungen oder Schlüsselbeständen sollte das Team noch weitergehen und Konto oder Remote Mac trennen. DeepSeek Harness bestätigt keine automatische Worktree-Orchestrierung; Erstellung, Sitzungsbindung, Prüfung und Rückgabe bleiben daher Aufgaben der Betriebsumgebung.

Das bestehende lokale Setup hat gegenüber einem gemieteten Remote Mac häufig drei konkrete Nachteile: Es bietet möglicherweise nicht genügend getrennte Arbeitsbereiche, es bindet langfristig Speicher und Buildprozesse an eine einzelne Maschine, und die Rückgabe- sowie Zugriffskontrolle muss vollständig selbst betrieben werden. Für kurzfristige Tests, parallele Agentenläufe oder eine zeitlich begrenzte Abnahme kann ein von NUKCLOUD bereitgestellter Remote Mac deshalb die sauberere Option sein, sofern die Aufgaben keine dauerhafte Hochlast und keine physischen Schnittstellen am eigenen Gerät voraussetzen.

Am sichersten startet der Wechsel mit zwei wegwerfbaren Branches: Änderung, Build, Abbruch und Rückgabe werden einmal vollständig durchlaufen. Erst wenn dieser Ablauf ohne manuelle Überraschungen funktioniert, sollte das Team weitere Sitzungen oder Kundenprojekte auf derselben Struktur betreiben.