Conductor Cloud wird eingestellt: Export vor dem 20. November

Übertrage und prüfe deine Conductor-Cloud-Workspaces vorsorglich vor dem 13. November 2026 und erledige bis dahin alle Backup-Schritte, die Zugriff auf das Cloud-Terminal benötigen. Lade das separate Kontoarchiv vor dem 20. November 2026 herunter und prüfe seinen Inhalt. Nutze Transfer to local für Workspaces und Settings → Account → Export data für das Archiv.

Conductors Ankündigung zum Wechsel zu Meta bestätigt, dass alte Chats und der Datenexport im schreibgeschützten Modus verfügbar bleiben. Sie bestätigt nicht, dass dann auch Workspace-Übertragungen oder Cloud-Terminals weiter funktionieren. Am 20. November wird Cloud abgeschaltet; zugleich beginnt die Löschung der Cloud-Nutzerdaten.

Bestehenden Nutzern kann die lokale Conductor-Version Zeit geben, laufende Aufgaben abzuschließen. Betrachte sie als Übergangslösung, nicht als einziges Backup oder dauerhaften Ersatz.

Welche Termine sind bei der Abschaltung wichtig?

Schließe Workspace-Übertragungen und Backups mit Cloud-Terminal-Zugriff vor Beginn des schreibgeschützten Modus ab. Trenne diese Vorsichtsmaßnahme vom dokumentierten Zeitfenster für den Kontoexport. Mit Stand vom 2026-11-10 gilt folgender offizieller Zeitplan:

Datum	Was sich ändert	Was du tun solltest
4. November 2026	Neue Nutzer können sich nicht mehr bei Conductor registrieren oder die App herunterladen. Bestehende Pro-Nutzer können Pro-Funktionen kostenlos weiterverwenden.	Plane mit deiner vorhandenen Installation und deinem bestehenden Konto.
13. November 2026	Cloud-Workspaces werden schreibgeschützt. Alte Chats und der Datenexport bleiben verfügbar, neue Nachrichten lassen sich aber nicht mehr senden.	Beende interaktive Aufgaben vorher. Schließe vorsorglich auch Übertragungen und Backups mit Terminal-Zugriff vor diesem Datum ab und prüfe sie.
20. November 2026	Cloud wird abgeschaltet, und die Löschung seiner Nutzerdaten beginnt.	Schließe den separaten Kontoexport vor diesem Datum ab und prüfe ihn.
Anfang 2027	Der zugesagte Zeitraum für neue Modelle und kritische Fehlerkorrekturen der lokalen Version endet. Ihre schrittweise Einstellung beginnt.	Beseitige vorher die verbleibenden Abhängigkeiten von der App.

Die Ankündigung verspricht außerdem Erstattungen für aktive Abonnenten. Prüfe deine Abrechnung separat. Die Zusage allein belegt nicht, dass eine Erstattung bereits auf deinem Konto eingegangen ist.

Setze bei einer Teammigration den 12. November als internes Abschlussziel. Das ist ein empfohlener Puffer, kein offizieller Abschalttermin für Übertragungen. Plane nicht damit, dass der Kontoexport noch bis zum Ende des 20. November verfügbar ist.

Conductor Cloud exportieren, ohne offene Arbeit zu verlieren

Nutze beide Exportwege und sichere Dateien mit nicht eingecheckten Änderungen separat, solange der Cloud-Workspace erreichbar ist. Prüfe jede Kopie, bevor du dich auf sie verlässt. Gehe nicht davon aus, dass das Kontoarchiv geänderte, unversionierte oder von Git ignorierte Dateien wiederherstellen kann.

Zustand jedes Workspaces erfassen und Dateien sichern

Erstelle vor der Übertragung eine kurze Bestandsliste. Notiere Workspace-Name, Repository, Branch, letzten Commit, offenen Pull Request und die Person, die das Ergebnis prüft.

Pausiere Bearbeitungen und Commits der Agenten, während du den Zustand festhältst. Führe diese Prüfungen im Stammverzeichnis des jeweiligen Repositories aus, solange die Cloud-Terminals erreichbar sind. Erledige diesen Teil vor dem 13. November. Die verwendete Shell ist Bash:

git rev-parse --verify HEAD
git status --short --branch --untracked-files=all
git diff HEAD --stat

Der erste Befehl zeigt die ID des aktuellen Commits. Der zweite zeigt Branch-Informationen sowie geänderte oder unversionierte Dateien. Der dritte fasst die Unterschiede versionierter Dateien gegenüber diesem Commit zusammen. Git beschreibt diese Funktionen in den Referenzen zu Revisionen, Status und Unterschieden.

Speichere die vollständige Ausgabe des zweiten Befehls als pre-transfer-status.txt in deinem unabhängigen Backup. Tue das, bevor du Backup-Ordner innerhalb des Repositories anlegst. Halte auch die vollständige Commit-ID und den Branch-Namen fest. Notiere bei Löschungen und Umbenennungen zusätzlich, welche Pfade im endgültig gesicherten Arbeitsstand fehlen.

Diese Befehle prüfen den Zustand; sie sichern keine Dateiinhalte. Pushe geprüfte Commits in ein freigegebenes Remote-Repository und bestätige dort Branch und Commit. Trage dessen URL ohne eingebettete Geheimnisse in die Bestandsliste ein. Für Commits, die du nicht pushen kannst, erledige vor der Übertragung die unten beschriebene Bundle-Sicherung samt Wiederherstellungsprüfung. Füge keine Zugangsdaten oder privaten Einstellungen zu Git hinzu, nur um einen sauberen Status zu erhalten.

Prüfe .conductor/settings.toml, .conductor/settings.local.toml und .context, sofern vorhanden. Conductor dokumentiert dort Projektskripte, lokale Projekteinstellungen und nicht eingecheckte Übergabenotizen.

Notiere Setup-Befehle, benötigte Laufzeitversionen, externe Dienste und Namen von Umgebungsvariablen. Stelle geheime Werte aus dem freigegebenen Zugangsdaten-Speicher wieder her. Nutze dafür weder ein Migrationsticket noch einen Agenten-Prompt.

Kopiere vor der Workspace-Übertragung alle benötigten Dateien mit nicht eingecheckten Änderungen in ein unabhängiges Backup. Ein dokumentierter Weg ist Sync to a local directory. Diese Funktion spiegelt den Cloud-Workspace in einen lokalen Ordner. Sobald die benötigten Dateien dort erscheinen, kopiere sie in einen separaten, freigegebenen Backup-Speicher.

Erhalte die relativen Pfade und bewahre die Bestandsliste beim Backup auf. Sichere benötigte geänderte und unversionierte Dateien. Prüfe notwendige ignorierte Dateien separat. Speichere vertrauliche Einstellungen nur an Orten, die für diese Daten freigegeben sind.

Öffne die kopierten Dateien und vergleiche ihren Inhalt mit der noch erreichbaren Quelle. Gleiche die Dateiliste mit deiner Bestandsliste ab, einschließlich dokumentierter Löschungen und Umbenennungen. Bearbeite den synchronisierten Ordner nicht und verwende ihn nicht als einziges Backup.

Fehlt eine kleine Textdatei, speichere ihren vollständigen Quellinhalt lokal unter demselben relativen Pfad. Öffne und vergleiche die Kopie erneut. Stoppe die Workspace-Übertragung, wenn für eine benötigte Datei weiterhin keine geprüfte lokale Kopie vorliegt. Das gilt auch für ausgelassene Binärdateien wie repository.bundle. Kontaktiere Conductor über die Angaben in der Ankündigung, solange der Cloud-Workspace noch erreichbar ist.

Lass Bearbeitungen pausiert, bis die Backups geprüft sind. Aktualisiere andernfalls Statusaufzeichnung und Kopien nach der letzten Änderung. Schließe alle Kopierschritte, die das Cloud-Terminal benötigen, vor dem 13. November ab und prüfe sie.

Commits sichern, die du nicht pushen kannst

Sichere den Git-Verlauf lokal, bevor du einen Branch mit nicht pushbaren Commits überträgst. Der Git-Befehl bundle kann Repository-Referenzen und den zugehörigen Commit-Verlauf für eine Wiederherstellung ohne Netzwerkverbindung bündeln. Behalte zusätzlich die separaten Backup-Kopien der Dateien mit nicht eingecheckten Änderungen.

Pausiere neue Commits und Branch-Änderungen während dieser Sicherung. Führe das folgende Bash-Beispiel im Stammverzeichnis des Cloud-Repositories aus. Das Verzeichnis conductor-history-backup darf noch nicht existieren:

mkdir conductor-history-backup &&
git for-each-ref --format='%(objectname) %(refname)' refs/heads > conductor-history-backup/branches.txt &&
git bundle create conductor-history-backup/repository.bundle --all

Prüfe, ob branches.txt jeden benötigten Branch und die vollständige Commit-ID aus deiner Bestandsliste enthält. Kopiere den gesamten Ordner mit dem zuvor beschriebenen Verfahren in den freigegebenen lokalen Speicher. Bewahre die Kopie außerhalb des synchronisierten Ordners auf. Bestätige, dass auch repository.bundle selbst auf deinem Mac angekommen ist. Lege pre-transfer-status.txt, Bestandsliste und gesicherte Dateien dazu.

Teste vor der Workspace-Übertragung die Wiederherstellung aus dieser lokalen Kopie. Öffne Bash im kopierten Ordner conductor-history-backup. Verwende ein noch nicht vorhandenes Zielverzeichnis restored.git:

git clone --mirror repository.bundle restored.git &&
git --git-dir=restored.git for-each-ref --format='%(objectname) %(refname)' refs/heads > restored-branches.txt &&
git diff --no-index --exit-code -- branches.txt restored-branches.txt &&
git --git-dir=restored.git fsck

Der Mirror-Klon stellt die Referenzen in einem separaten Bare-Repository wieder her. Dieses enthält keine ausgecheckten Arbeitsdateien. Der Vergleich der Branch-Listen darf keine Unterschiede zeigen. git fsck darf keine fehlenden oder beschädigten Git-Objekte melden.

Bestätige vor der Übertragung die erwarteten Branch-Namen und Commit-IDs in restored-branches.txt. Stoppe, wenn ein Befehl fehlschlägt oder ein benötigter Branch fehlt. Behebe das Backup-Problem, solange das Cloud-Repository erreichbar ist.

Schütze Bundle, Branch-Listen und die Backup-Kopien der Dateien mit nicht eingecheckten Änderungen wie private Repository-Daten. Wiederhole das Verfahren für jedes Repository mit nicht gepushter Arbeit. Aktualisiere das Backup nach weiteren Commits.

Einen Workspace übertragen, prüfen und dann fortfahren

Schließe jede Workspace-Übertragung vorsorglich vor dem 13. November ab und prüfe das Ergebnis. Klicke auf deinem Mac mit der rechten Maustaste auf einen Cloud-Workspace und wähle Transfer to local. Conductors Versionshinweise zu 0.93.0 beschreiben damit das Verschieben des Workspaces samt Chats auf den Mac.

Öffne nach Abschluss den lokalen Workspace und führe die Bestandsbefehle erneut aus. Vergleiche Branch, Commit, nicht eingecheckte Änderungen und Dateiinhalte mit der Bestandsliste und den vorab geprüften unabhängigen Kopien. Öffne sowohl einen älteren Chat als auch die jüngste Unterhaltung.

Prüfe unversionierte Dateien und Projekteinstellungen separat. Ein sichtbares Repository beweist nicht, dass alle Dateien und Umgebungsabhängigkeiten erhalten geblieben sind.

Stelle Abhängigkeiten nach dem dokumentierten Setup-Verfahren des Projekts wieder her. Führe anschließend den kleinsten sinnvollen vorhandenen Test oder Build-Check aus. Untersuche Abweichungen anhand des geprüften Remote- oder Bundle-Verlaufs und der unabhängigen Dateikopien. Nutze den ursprünglichen Cloud-Workspace nur zum Vergleich, wenn er weiterhin erreichbar ist.

Wiederhole das für alle benötigten Workspaces. Berücksichtige auch offene Experimente und ältere Arbeit mit wichtigen Entscheidungen. Weise jeder Prüfung eine verantwortliche Person zu. Verlasse dich nicht darauf, dass ein anderes Teammitglied die gemeinsame Arbeit bereits exportiert hat.

Kontoarchiv herunterladen und prüfen

Erstelle das Kontoarchiv auch dann, wenn deine Workspaces bereits lokal sichtbar sind. Öffne Settings → Account → Export data und speichere den Download außerhalb der Workspace-Verzeichnisse von Conductor. Schließe diesen Export samt Prüfung vor dem 20. November ab.

Bewahre eine weitere Kopie am freigegebenen Backup-Ort deines Teams auf. Öffne den Export lokal mit einem passenden Programm und prüfe eine Auswahl von Projektaufzeichnungen und Unterhaltungen. Notiere Exportdatum und fehlende Inhalte.

Betrachte das Archiv als zu prüfendes Backup, nicht als garantiertes Importformat für ein anderes Coding-Tool. Baue eine nutzbare Umgebung aus geprüftem Code, separat gesicherten Dateien, Einstellungen, Abhängigkeiten und Zugangsdaten auf.

Fehlt Transfer to local oder schlägt es fehl, wähle unten den passenden Wiederherstellungsweg. Nutze das freigegebene Remote-Repository, wenn du die Commits dorthin gepusht hast, oder den geprüften Mirror bei einem Bundle-Backup. Hole fehlende Inhalte nur aus Cloud zurück, wenn es weiterhin erreichbar ist. Exportiere das Konto separat, aber betrachte das nicht als Beweis, dass sich Code mit nicht eingecheckten Änderungen wiederherstellen lässt.

Notiere App-Version, betroffenen Workspace und den genauen Fehler. Nutze vor Ablauf der Frist den Supportkontakt in Conductors Ankündigung. Sende keine Zugangsdaten oder vertraulichen Gesprächsinhalte.

Im angekündigten schreibgeschützten Zeitraum bleiben alte Chats und Datenexporte verfügbar. Mache die Wiederherstellung nach dem 13. November nicht von einer neuen Agentennachricht, einer Übertragung oder einem weiterhin funktionierenden Cloud-Terminal abhängig.

Eine Arbeitskopie aus dem Backup wiederherstellen

Stelle gepushte Historie aus dem freigegebenen Remote-Repository wieder her. Hast du ein Bundle erstellt, verwende stattdessen restored.git. Wähle einen dieser Wege und führe danach dieselben Schritte zum Wiederherstellen der Dateien und Nachbilden dokumentierter Löschungen aus.

Öffne für gepushte Commits Bash in einem freigegebenen lokalen Wiederherstellungsverzeichnis. Gib die Remote-URL ohne eingebettete Geheimnisse ein. Verwende den Branch-Namen ohne refs/heads/ und die vollständige Commit-ID aus deiner Bestandsliste. Nutze deine übliche Git-Authentifizierung und ein noch nicht vorhandenes Verzeichnis recovered-worktree:

read -r -p "Approved remote URL (no embedded secrets): " RECOVERY_REMOTE &&
read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
mkdir recovered-worktree &&
(
  cd recovered-worktree &&
  git init &&
  git remote add origin "$RECOVERY_REMOTE" &&
  git fetch origin &&
  git switch --create "$RECOVERY_BRANCH" "$RECOVERY_COMMIT" &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

Der Fetch-Schritt lädt den Remote-Verlauf. git switch --create erstellt den gewünschten lokalen Branch am aufgezeichneten Commit, nicht am neuesten Remote-Commit. Stoppe bei fehlgeschlagener Anmeldung, nicht verfügbarem Commit oder einem fehlgeschlagenen Vergleich. Beschaffe den fehlenden Commit aus einem geprüften Bundle oder einem erreichbaren Cloud-Workspace. Ersetze ihn nicht durch einen anderen Commit.

Öffne für ein Bundle-Backup Bash im lokalen Verzeichnis conductor-history-backup. Gib den Branch-Namen ohne refs/heads/ und die vollständige Commit-ID aus der gespeicherten Bestandsliste ein. Verwende ein noch nicht vorhandenes Verzeichnis recovered-worktree:

read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
git clone --branch "$RECOVERY_BRANCH" restored.git recovered-worktree &&
(
  cd recovered-worktree &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

git clone --branch wählt den Branch für die Arbeitskopie. git branch --show-current prüft seinen Namen, git rev-parse --verify HEAD den Commit. Die abschließende Statusausgabe erscheint nur, wenn beide Vergleiche erfolgreich sind. Stoppe bei Fehlern oder Abweichungen.

Arbeite nach erfolgreicher Wiederherstellung innerhalb der neuen Arbeitskopie recovered-worktree. Kopiere gesicherte geänderte, hinzugefügte und unversionierte Dateien an ihre ursprünglichen relativen Pfade. Stelle benötigte ignorierte Dateien separat wieder her. Verändere die ursprünglichen Backup-Kopien nicht.

Nutze pre-transfer-status.txt und deine Aufzeichnung der im Endzustand fehlenden Pfade, um Löschungen und Umbenennungen nachzubilden. Entferne ausschließlich als gelöscht vermerkte Pfade, nachdem du ihre Abwesenheit im gesicherten Endzustand bestätigt hast. Lösche sie nur aus der Wiederherstellungskopie. Stelle bei einer Umbenennung die gesicherte Datei am neuen Pfad wieder her. Entferne den alten Pfad nur, wenn er im Endzustand nicht mehr vorhanden war.

Führe die Bestandsbefehle erneut im Stammverzeichnis der wiederhergestellten Arbeitskopie aus. Gleiche jeden geänderten Pfad mit dem gespeicherten Status ab und vergleiche Inhalte mit den unabhängigen Kopien. Das stellt den Inhalt des Worktrees wieder her, nicht den ursprünglichen Staging-Zustand. Prüfe die Unterschiede, bevor du Änderungen zum Index hinzufügst oder die Arbeit mit dem Agenten fortsetzt. Pushe keine Commits in den Backup-Mirror.

Die lokale Conductor-Version als Übergang nutzen

Behalte Conductor lokal für laufende Arbeit, während du Abhängigkeiten von seiner Workspace-Oberfläche entfernst. Die Ankündigung verspricht neue Modelle und kritische Fehlerkorrekturen bis Anfang 2027. Danach beginnt die schrittweise Einstellung. Das verlängert die Cloud-Frist vom 20. November nicht.

Prüfe nach einer Workspace-Übertragung die Ausführungsumgebung. Conductors Cloud-Workspace-Dokumentation beschreibt eine Linux-Sandbox, mit der sich dein Mac verbindet. Ein funktionierender Cloud-Build beweist daher nicht, dass dieselben Abhängigkeiten und Befehle lokal funktionieren.

Lokale Ausführung bedeutet auch nicht, dass das Modell offline arbeitet. Laut Conductors Datenschutzdokumentation geht der Modellverkehr lokaler Workspaces an den konfigurierten Modellanbieter.

Plane die andere Prozesslaufzeit ein. Die Cloud-FAQ erklärt, dass lokale Sitzungen beim Schließen von Conductor oder Herunterfahren des Macs enden. Ein übertragener Workspace ersetzt deshalb keinen dauerhaft laufenden Cloud-Prozess.

Nutze die Übergangszeit, um das Repository ohne Conductor nutzbar zu machen. Halte Setup-Anweisungen, Testbefehle und Übergabenotizen in geprüften Projektdateien fest. Prüfe das Nutzungskontingent des Modellanbieters oder die API-Abrechnung getrennt von Conductors kostenlosen Pro-Funktionen.

Mit Claude Code, Codex oder OpenCode parallel weiterarbeiten

Beginne mit dem Coding-Agenten, den du bereits verwendest. Stelle parallele Arbeit anschließend über getrennte Git-Worktrees wieder her. Ein Worktree ist eine weitere Arbeitskopie desselben Repositories, meist auf einem anderen Branch.

Dieser Ansatz eignet sich für Entwickler, die Projekte lokal ausführen und Änderungen mit Git prüfen können. Er erzeugt getrennte Arbeitsverzeichnisse. Er ersetzt weder Conductors gemeinsamen Cloud-Dienst noch dessen vollständige Oberfläche.

Agent auswählen und Authentifizierung prüfen

Installiere den gewählten CLI außerhalb von Conductor und richte die Authentifizierung ein, bevor du eine Aufgabe übernimmst. Das folgende Beispiel mit unterschiedlichen Agenten benötigt Claude Code und Codex, jeweils installiert und authentifiziert. Bei einer Migration zu nur einem Agenten startest du denselben CLI in beiden Worktrees.

Nutze Claude Code, wenn du deine bisherige Arbeitsweise damit beibehalten möchtest. Starte claude im Projektverzeichnis und folge beim ersten Aufruf den Anmeldehinweisen.

Nutze Codex CLI, wenn du mit Codex weiterarbeiten möchtest. Starte codex im Projektverzeichnis. Beim ersten Start kannst du dich mit ChatGPT oder einer anderen verfügbaren Methode anmelden.

Nutze OpenCode, wenn du dort bereits Modellanbieter konfigurierst oder zwischen Anbietern wählen möchtest. Starte opencode und verwende anschließend /connect und /models gemäß den Anbieteranweisungen.

Gehe nicht davon aus, dass nur in Conductor hinterlegte Zugangsdaten dem eigenständigen CLI zur Verfügung stehen. Prüfe aktives Konto, Anbieter und Modell, bevor du Zugriff auf eine echte Aufgabe erteilst.

Für einen separaten API-Zugang mit nutzungsabhängiger Abrechnung veröffentlicht BetterToken eigene Anleitungen für Claude Code und Codex. Trenne die Einrichtung des Modellzugangs von der Workspace-Wiederherstellung. Nutze vor einer produktiven Aufgabe die Checkliste für den ersten API-Test mit Claude Code und Codex.

Zwei Worktrees erstellen und den gesamten Ablauf prüfen

Beginne im Stammverzeichnis deines geprüften lokalen Repositories mit einem bekannten Commit als Ausgangspunkt. Dieses Bash-Beispiel erstellt zwei Branches vom aktuellen HEAD:

git worktree add -b migration/docs ../migration-docs HEAD &&
git worktree add -b migration/tests ../migration-tests HEAD &&
git worktree list

Gits Worktree-Referenz dokumentiert das Erstellen von Branches mit -b und das Prüfen mit list. Bestätige, dass die Ausgabe beide neuen Verzeichnisse mit ihren zugehörigen Branches enthält.

Das sind neue Arbeitskopien des eingecheckten Zustands. Sie übernehmen keine nicht eingecheckten Dateien und keinen Conductor-Chatverlauf. Sichere wiederhergestellte, noch nicht eingecheckte Änderungen, bevor du mit diesem Beispiel neue Worktrees erstellst.

Verwende noch freie Branch- und Verzeichnisnamen. Prüfe bei einem Erstellungsfehler, welche Branches und Worktrees bereits existieren. Entscheide danach, ob du den fehlgeschlagenen Schritt erneut ausführen musst. Ergänze nicht einfach --force, um einen Fehler zu umgehen.

Die nächsten beiden Startbefehle setzen voraus, dass Claude Code und Codex installiert und authentifiziert sind. Öffne zwei Terminal-Tabs, beide zunächst im Stammverzeichnis des ursprünglichen Repositories. Starte im ersten Tab Claude Code:

(cd ../migration-docs && claude)

Starte im zweiten Tab Codex:

(cd ../migration-tests && codex)

Verwendest du nur einen Agenten, starte in beiden Verzeichnissen denselben installierten CLI-Befehl: claude, codex oder opencode. Vermeide zwei schreibende Agenten im selben Arbeitsverzeichnis.

Beginne jede Sitzung mit diesem Prüf-Prompt:

Use read-only tools to inspect this repository.
Report the current directory and Git branch.
Identify the documented setup command and one existing test command.
Cite the repository files that define those commands.
If a command is not documented, say so.
Do not edit files, install packages, commit, or push.

Erwartet werden zwei Berichte, die sich auf unterschiedliche Verzeichnisse und Branches beziehen. Jeder Bericht soll die tatsächlichen Repository-Dateien nennen, in denen der Setup-Befehl und der Testbefehl definiert sind. Er darf keinen allgemeinen Testbefehl erfinden. Lass die üblichen Freigabekontrollen aktiviert. Ein Prompt ist keine Sicherheitsgrenze.

Wenn diese Prüfungen erfolgreich sind, genehmige das nötige Setup und führe in jedem Worktree einen kleinen vorhandenen Test aus. Vergib danach unabhängige Aufgaben, etwa eine Dokumentationskorrektur und eine separate Testverbesserung. Prüfe jeden Diff vor dem Commit oder Merge.

Erstelle aus den exportierten Gesprächen eine kurze Übergabenotiz für jede Aufgabe. Halte Ziel, Einschränkungen, abgeschlossene Änderungen, offene Arbeit und das letzte Testergebnis fest. Prüfe importierte Anweisungen und Hooks vor der Wiederverwendung. Der Leitfaden zur Prüfung von Agentenkonfigurationen bietet dafür eine Checkliste.

Verwechsle eine neue CLI-Sitzung nicht mit einem wiederhergestellten Gesprächsverlauf. OpenAIs Importdokumentation nennt Claude Code und Cursor als Importquellen für Codex CLI. Sie belegt keinen direkten Import eines Conductor-Kontoarchivs.

Getrennte Worktrees stellen auch keine getrennten Datenbanken, Dienstkonten oder Entwicklungsports bereit. Teile diese Ressourcen bewusst zu, bevor du parallele Builds startest. Conductor unterscheidet selbst zwischen Workspace-Isolation und einer Sicherheitsgrenze.

Verfolge für jede aktive Sitzung das Nutzungskontingent des Anbieters oder die API-Kosten. OpenAIs Authentifizierungsdokumentation trennt beispielsweise die nutzungsabhängige Abrechnung per API-Schlüssel vom Guthaben, das im ChatGPT-Plan enthalten ist. Zusätzliche Terminal-Tabs erhöhen das Nutzungskontingent deines Abonnements nicht.

Markiere die Migration erst als abgeschlossen, wenn sich das Archiv öffnen lässt, benötigte Dateien und Commits geprüft sind und eine lokale Aufgabe ihre Prüfungen besteht. Behalte ungeklärte Workspaces auf der Migrationsliste. Die verantwortliche Person muss sie prüfen oder ausdrücklich dokumentieren, was nicht wiederhergestellt werden konnte.