Google Jules wird eingestellt: Daten exportieren und migrieren

Exportiere deine Google-Jules-Daten jetzt und wiederhole den Export nach deinen letzten Programmiersitzungen. Nach Googles Angaben, Stand 2026-11-01, kannst du Sitzungen bis zum 11. November 2026 abschließen. Danach bleibt bis Jahresende nur Lesezugriff. Jules wird am 31. Dezember 2026 eingestellt, wie die offizielle Ankündigung erklärt.

Die Migration hat zwei Schritte: Sichere zuerst die Daten in Jules und führe danach eine funktionierende Aufgabe im neuen Werkzeug aus. Dein Repository allein enthält nicht die Erinnerungen, die Umgebungskonfiguration und den Sitzungsverlauf, die du dafür brauchst.

Was solltest du vor dem Lesemodus abschließen?

Schließe laufende Arbeiten ab und sichere nützliche Änderungen vor dem 11. November. Laut Google wechselt Jules nach diesem Datum in den Lesemodus. Eine genaue Uhrzeit oder Zeitzone nennt die Ankündigung nicht.

Sie verspricht auch nicht, dass die Export-Endpunkte während des gesamten Lesemodus erreichbar bleiben. Der Export vor dem 11. November ist deshalb eine vorsichtige Empfehlung, keine gesondert angekündigte Exportfrist.

Code, Branches und Pull Requests, die bereits auf GitHub liegen, bleiben dort. Prüfe unfertige Sitzungen und veröffentliche sinnvolle Änderungen, wenn sie bereit sind. Bewahre exportierte Patches für Arbeiten auf, die noch in keinem Branch liegen.

Google erklärt, dass Erfahrungen aus Jules in Antigravity einfließen. Daraus folgt weder ein Migrationsverfahren noch die Zusage, dass deine Jules-Konfiguration automatisch übertragen wird.

Wie exportierst du deine Jules-Daten?

Verwende Googles vollständigen Export-Prompt mit einem lokalen Coding-Agenten über die Kommandozeile (CLI). Der Prompt enthält ein Python-Skript, das Kontoeinstellungen, Repository-Informationen und Sitzungsdaten abruft.

Bereite die CLI und einen privaten Zielordner vor

Die folgenden Befehle sind für Bash unter macOS oder Linux vorgesehen. Du brauchst Node.js mit npm, Python und einen installierten CLI-Coding-Agenten.

Prüfe die Voraussetzungen:

node --version
npm --version
python3 --version

Verwende für das veröffentlichte Skript Python 3.9 oder neuer. Das ergibt sich aus seiner Verwendung von str.removeprefix. Laut Python-Referenz wurde diese Methode mit Python 3.9 eingeführt.

Installiere Jules Tools und melde dich an:

npm install -g @google/jules
jules login
jules remote list --repo

Schließe die Anmeldung im Browser selbst ab. Verwende das Google-Konto, dessen Jules-Daten du sichern möchtest. Der letzte Befehl sollte die Repositories auflisten, die mit diesem Konto verbunden sind.

Falls Repositories fehlen, kläre das vor dem Export. Prüfe Verbindung und Repository-Zugriff auf der GitHub-Installationsseite von Google Labs Jules.

Wechsle in dein Home-Verzeichnis und lege einen privaten Exportordner an:

cd "$HOME"
umask 077
mkdir -m 700 "$HOME/jules-export"

Falls der Ordner schon existiert, halte an und benenne das vorherige Archiv um. Schütze auch diese Sicherung vor fremdem Zugriff. Verwende für den abschließenden Export einen neuen Zielordner.

Starte deinen installierten Coding-Agenten aus derselben Shell. Für Claude Code führst du claude aus. Bei Bedarf beschreibt die Schnellstartanleitung Installation und Anmeldung.

Führe den vollständigen offiziellen Prompt aus

Öffne die Ankündigung zur Einstellung, klappe Show the export prompt auf und kopiere den gesamten Prompt einschließlich Python-Skript. Füge ihn in deinen CLI-Agenten ein.

Entferne unter Linux vor dem Absenden die separate Vorabprüfung mit secret-tool lookup aus dem Prompt. Dieser Befehl schreibt den gespeicherten geheimen Wert in die Standardausgabe, wie die libsecret-Implementierung zeigt. Teile dem Agenten mit, dass du die Prüfung der Jules-CLI bereits abgeschlossen hast.

Lass Zugangsdaten ausschließlich innerhalb des Exportskripts auslesen. Bitte den Agenten nicht, das Zugriffstoken oder die Werte aus env-variables.json anzuzeigen.

Lass den Agenten das bereitgestellte Skript speichern und aus deinem Home-Verzeichnis ausführen. Fordere anschließend die ausgegebenen Zähler, aufgetretene Fehler und den vollständigen Zielpfad an. Der dokumentierte Zielordner lautet ~/jules-export.

Prüfe das Archiv, bevor du dich darauf verlässt

Prüfe error_count und die erwarteten Dateien zusätzlich zur abschließenden Erfolgsmeldung. Der Zähler sessions erfasst die aufgelisteten Sitzungen, auch wenn einzelne Sitzungsdownloads fehlgeschlagen sind.

Der Export soll folgende Daten sichern:

Daten	Speicherort	Nächster Schritt
Kontoeinstellungen, Umgebungsvariablen und geplante Aufgaben	JSON-Dateien des Kontos, darunter env-variables.json	Richte benötigte Einstellungen und Secrets im Ziel neu ein
Verbundene Repositories	sources.json	Vergleiche die Liste mit den erwarteten Repositories
Erinnerungen, Setup-Skripte und Testbefehle der Repositories	Ordner je Repository, sofern entsprechende Datensätze vorhanden sind	Prüfe die Inhalte und passe sie vor der Verwendung an
Prompts, Pläne, Aktivitätsprotokolle und Patches der Sitzungen	Ordner je Sitzung mit lesbaren summary.md-Dateien	Sichere den Verlauf und stelle unfertige Arbeiten wieder her

Stelle sicher, dass error_count den Wert 0 hat. Prüfe anschließend eine Auswahl alter und neuer Sitzungen. Kontrolliere deine wichtigste unfertige Sitzung separat. Prompt, Plan, Aktivitätsdaten und erwartete Patches müssen vorhanden sein.

Setup-Skripte und Testbefehle werden aus den Metadaten der Sitzungsausgaben wiederhergestellt. Falls eine benötigte setup.sh fehlt, prüfe die Repository-Konfiguration in Jules, solange du noch darauf zugreifen kannst.

Behandle den Ordner als Archiv für Konfiguration und Verlauf. Sichere das GitHub-Repository separat. Halte das gesamte Archiv außerhalb von Repositories, denn env-variables.json enthält die tatsächlichen Werte deiner Umgebungsvariablen.

Welcher Exportfehler tritt auf?

Erneuere die Google-Authentifizierung, wenn alle Aufrufe fehlschlagen. Prüfe den GitHub-Zugriff, wenn nur die Repository-Abfrage scheitert. Googles Fehlerbehebung unterscheidet diese Fälle.

Symptom	Wahrscheinliche Ursache oder dokumentierte Bedingung	Behebung und Prüfung
Alle Exportaufrufe liefern 401	Das Zugriffstoken könnte abgelaufen sein. Laut Google gilt es etwa eine Stunde nach der Anmeldung.	Führe einen Jules-Befehl aus oder melde dich mit jules login erneut an. Wiederhole die Repository-Prüfung und danach den Export.
ListSources liefert 401 mit missing required authentication credential, während andere Aufrufe funktionieren	Google nennt für dieses Muster eine fehlende GitHub-Verbindung.	Verbinde GitHub, bestätige den Repository-Zugriff und führe jules remote list --repo erneut aus.
Ein erwartetes Repository fehlt	Kontoverbindung oder Zugriff auf ausgewählte Repositories müssen geprüft werden.	Prüfe das richtige Google-Konto und die App-Installation auf GitHub. Exportiere erneut und kontrolliere sources.json.
Ein Export-Endpunkt liefert 404 oder 400	Das Exportskript verwendet undokumentierte interne Endpunkte.	Notiere den fehlgeschlagenen Aufruf und seinen Status. Prüfe vor dem nächsten Versuch den aktuellen offiziellen Prompt. Versuche nicht, Ersatz-Endpunkte zu erraten.

Falls du Jules nie mit GitHub-Repositories verwendet hast, erlaubt Googles Prompt, diese Verbindung zu überspringen. Laut Prompt enthält der Export dann keine Repository-Daten. Falls du solche Daten erwartest, verbinde GitHub und wiederhole die Repository-Prüfung vor dem Export.

Übertrage Erinnerungen und Setup auf deinen nächsten Agenten

Migriere zuerst dauerhaft nützliches Projektwissen und eine reproduzierbare Einrichtung. Bewahre das vollständige Sitzungsarchiv als Referenz auf.

Mache nützliche Erinnerungen zu Projektanweisungen

Gleiche die gespeicherten Erinnerungen jedes Repositories mit dem aktuellen Code ab. Behalte gültige Build-Befehle, Architekturvorgaben und Lösungen für wiederkehrende Fehler. Entferne veraltete Hinweise, doppelte Regeln und Secrets.

Lege gemeinsame Anweisungen in einer AGENTS.md im Stammverzeichnis des Repositories ab. Codex liest diese Datei, und OpenCode 2 verwendet sie für Projektanweisungen. OpenCode 2 greift nicht ersatzweise auf CLAUDE.md zurück.

Für ein npm-Projekt mit package-lock.json und einem funktionierenden npm test-Skript eignet sich dieses kleine Beispiel:

- Install dependencies with `npm ci`.
- Run `npm test` after code changes.
- Keep generated files out of manual edits.
- Report failing checks and unresolved setup requirements.

Das Beispiel legt Installation, Tests, den Umgang mit generierten Dateien und die Meldung offener Probleme fest. Ergänze bestehende Dateien um geprüfte Anweisungen, statt ihren Inhalt zu ersetzen.

Füge für Claude Code diesen Import in eine CLAUDE.md im Stammverzeichnis des Repositories ein. Behalte dabei vorhandene Claude-spezifische Anweisungen bei:

@AGENTS.md

Die Claude-Dokumentation zu Erinnerungen beschreibt diese gemeinsame Dateinutzung. Starte eine neue Sitzung und prüfe mit /context, ob CLAUDE.md unter Memory files erscheint.

Lass den Agenten die benötigten Setup- und Testbefehle nennen, bevor du Änderungen erlaubst. So prüfst du, ob die migrierten Anweisungen nützlich sind. Für eine längerfristige Struktur hilft die Anleitung zu Erinnerungen für Coding-Agenten.

Baue die Ausführungsumgebung neu auf

Passe das exportierte Setup-Skript an die Laufzeit und die Einrichtungsphasen des neuen Werkzeugs an. Prüfe vorher Arbeitsverzeichnisse, Laufzeitversionen, Paket-Registries, den Zugriff auf Secrets und benötigte Dienste.

Öffne für Claude-Code-Cloud-Sitzungen den Umgebungseditor und wähle Setup script. Lade über Choose file ein geprüftes Skript. Die Anleitung für Cloud-Umgebungen erklärt die einzelnen Phasen. Während das Setup-Skript läuft, sind die für die Sitzung konfigurierten Umgebungsvariablen noch nicht gesetzt. Gehe deshalb nicht davon aus, dass der Variablenzugriff wie in Jules funktioniert.

Erstelle für Codex Cloud eine Umgebung für deine GitHub-Repositories anhand der aktuellen Anleitung für Cloud-Umgebungen. Hinterlege die geprüften Installations- und Testbefehle. Verwende Install script für Abhängigkeiten und Start skill zum Starten von Diensten. Prüfe die vorbereitete Umgebung, veröffentliche sie und starte eine neue Aufgabe.

Richte für den lokalen Einsatz von Claude Code oder OpenCode die benötigte Umgebung auf deinem Rechner oder in einem Entwicklungscontainer, einem devcontainer, ein. Du kannst geprüfte Installationsbefehle beispielsweise als .devcontainer/setup.sh speichern. Setze in einer vorhandenen .devcontainer/devcontainer.json den Wert von postCreateCommand auf bash .devcontainer/setup.sh. Die Development-Containers-Referenz legt fest, wann dieser Befehl ausgeführt wird.

Übertrage geheime Werte über die Secret-Einstellungen des neuen Werkzeugs. Kopiere env-variables.json nicht in Projektanweisungen und committe die Datei nicht zusammen mit einem Setup-Skript.

Führe abschließend den wiederhergestellten Testbefehl in einer frischen Umgebung aus. Behebe Einrichtungsfehler, bevor du den Agenten Anwendungscode ändern lässt.

Lege geplante Aufgaben nach einem manuellen Test neu an

Erstelle jede wiederkehrende Aufgabe anhand ihres exportierten Prompts und Zeitplans neu. Übernimm Repository, vorgesehenen Branch, Zeitzone, Anforderungen an die Umgebung und erwartetes Ergebnis.

Bei Claude Code sind geplante Cloud-Aufgaben mit Stand 2026-11-01 als experimentelle Vorschau (research preview) verfügbar. Sie stehen in den Plänen Pro, Max, Ultra, Team und Enterprise zur Verfügung. Dabei gelten die Vorgaben der Organisation.

Öffne die Seite für geplante Claude-Aufgaben und wähle New task; manche Konten zeigen New routine. Gib den Prompt ein, wähle Repository und Cloud-Umgebung und lege den Zeitplan fest. Starte mit Run now und prüfe anschließend History, wie in der Anleitung für geplante Aufgaben beschrieben.

Verwende für lokale Aufgaben mit Codex den Bereich Scheduled in der ChatGPT-Desktop-App. Laut aktueller Dokumentation zur Zeitplanung müssen Computer und App weiterlaufen, wenn eine geplante Aufgabe lokale Dateien benötigt. Die Codex-CLI bietet die Scheduled-Verwaltungsoberfläche nicht. Unterscheide diese Voraussetzung von der gehosteten Ausführung in Codex Cloud.

Für OpenCode 2 nutzt das offizielle CI-Beispiel den Standalone-Modus mit Anbieter-Zugangsdaten aus CI-Secrets. Sobald OpenCode 2 und der gewünschte Anbieter samt Modell eingerichtet sind, kannst du diese erste Prüfung ausführen:

opencode run --standalone "Read AGENTS.md and identify the setup and test commands. Do not edit files."

Der Prompt fordert den Agenten auf, die Anweisungen zu lesen und Setup- sowie Testbefehle zu nennen, ohne Dateien zu bearbeiten. Prüfe die Antwort in der Workflow-Ausgabe. Beginne in GitHub Actions mit workflow_dispatch für einen manuellen Start und ergänze danach einen schedule-Trigger. Beide beschreibt GitHub in der Referenz für Workflow-Ereignisse. Geplante Workflows laufen vom Standardbranch.

Prüfe die geänderten Berechtigungen in OpenCode 2, bevor du unbeaufsichtigte Änderungen erlaubst. Stelle sicher, dass der Job alle erforderlichen Aktionen ausführen kann, ohne unerwartet auf eine interaktive Bestätigung zu warten.

Deaktiviere die alte wiederkehrende Aufgabe, sobald ihre Nachfolgerin die Prüfungen besteht. Lass nicht beide Zeitpläne dieselbe Arbeit bearbeiten. Prüfe die ersten Durchläufe auf doppelte Änderungen, wiederkehrende Fehler und unerwarteten Verbrauch.

Welche Alternative zu Jules passt zu deinem Einsatz?

Beginne mit einem gehosteten Agenten, wenn die Arbeit nach dem Zuklappen deines Laptops weiterlaufen muss. Wähle einen CI-basierten Ansatz, wenn Kontrolle über Laufzeit und Modellanbieter wichtiger ist als eine verwaltete Oberfläche.

Diese Empfehlungen beruhen auf den mit Stand 2026-11-01 dokumentierten Funktionen:

Deine Anforderung	Zuerst ausprobieren	Wann sich die Empfehlung ändert
Gehostete Repository-Aufgaben mit wiederverwendbarer Umgebung	Codex Cloud	Wenn die Umgebung erforderliche Dienste nicht erreicht oder den Build nicht reproduziert, prüfe einen selbst kontrollierten Runner
Verwaltete, wiederkehrende Programmieraufgaben	Claude-Code-Cloud-Sitzungen mit geplanten Cloud-Aufgaben	Wenn Preview-Zugang oder Organisationsvorgaben die Zeitplanung verhindern, nutze einen genehmigten CI-Ansatz
Kontrolle über Modellzugriff und Ausführung	OpenCode 2 auf deinem CI-Runner	Wähle einen gehosteten Agenten, wenn du Workflows, Zugangsdaten und Berechtigungen nicht selbst pflegen möchtest
Fernzugriff auf einen vorhandenen Entwicklungsrechner mit Google-Werkzeugen	Antigravity Remote Control	Der dokumentierte Hintergrunddienst benötigt einen eingeschalteten Host. Wähle gehostete Ausführung, wenn das nicht passt

Der dokumentierte Remote-Control-Ansatz von Antigravity läuft auf deinem Rechner. Prüfe dieses konkrete Ausführungsmodell, bevor du Googles angekündigte Richtung als Ersatz für die gehostete Jules-Umgebung betrachtest.

Für den CLI-Betrieb dokumentiert BetterToken API-Anbindungen für Claude Code und OpenCode. Betrachte diesen Modellzugriff getrennt von den Anforderungen des jeweiligen Werkzeugs an Konto, gehostete Ausführung und Zeitplanung.

Vergleiche die Kosten anhand derselben Testaufgabe. Berücksichtige Modellnutzung, gegebenenfalls erforderliche Abonnements und die Runner-Kosten deines gewählten Ansatzes. Ein Export zeigt nicht, welche Alternative am günstigsten ist.

Prüfe eine Aufgabe, bevor du die Migration abschließt

Wähle eine klar begrenzte Änderung mit einem eindeutig erwarteten Ergebnis. Verwende beim Vergleich dieselbe Repository-Revision, dieselben Einrichtungsanforderungen und denselben Testbefehl.

Prüfe, ob der Agent die Anweisungen lädt, die Umgebung vorbereitet, die Aufgabe abschließt und ein überprüfbares Ergebnis hinterlässt. Kontrolliere bei gehosteten Aufgaben, ob die Ausführung ohne deine lokale Sitzung weitergeht. Prüfe bei geplanten Aufgaben nach dem manuellen Test auch einen echten geplanten Durchlauf.

Nutze die Checkliste für abgeschlossene Agentenaufgaben, um Änderungen und Testergebnisse direkt in den maßgeblichen Systemen zu überprüfen.

Erstelle nach deinen letzten Jules-Sitzungen einen frischen Export und prüfe ihn erneut. Bewahre das private Archiv, die geprüften Projektanweisungen und die Nachweise der neuen Aufgabe gemeinsam in deiner Migrationsdokumentation auf.