Google Jules vor dem Nur-Lese-Modus am 11. November migrieren? 2026

Beste Vorgehensweise: Exportieren Sie sofort die Jules-Konfiguration und den Sitzungsverlauf und schließen Sie alle Sitzungen ab, die noch Interaktion benötigen, bevor der Nur-Lese-Modus beginnt. Das gilt besonders, wenn Jules für geplante Aufgaben oder wiederkehrende Arbeiten an GitHub-Repositories eingesetzt wird: Bereits in GitHub gespeicherter Code bleibt dort, doch daraus folgt keine automatische Übernahme von Jules-Einstellungen und Arbeitsabläufen nach Google Antigravity oder in einen anderen Agenten.

Dieser Beitrag ist für unabhängige Entwickler gedacht, die persönliche Einstellungen, Umgebungsvariablen und offene Sitzungen sichern müssen.
Kleine Entwicklungsteams erhalten einen Ablauf für Export, Berechtigungsprüfung und Abnahme eines Ersatz-Workflows.
CI- und Plattformteams können damit Aufgaben, Testverantwortung und macOS-spezifische Build-Schritte geordnet übergeben.

Zuletzt geprüft am 05.11.2026 anhand der Jules-Migrationsankündigung und der Jules-Tools-CLI-Referenz. Stichtage und Exportumfang sollten vor der Ausführung nochmals mit diesen offiziellen Angaben abgeglichen werden.

Vor dem Stichtag: Sitzungen sichern, die noch Interaktion brauchen

Google bestätigt, dass Jules-Sitzungen bis zum 11.11.2026 abgeschlossen werden können. Danach wechselt der Dienst in einen Nur-Lese-Modus; am 31.12.2026 endet der Dienst. Prüfen Sie deshalb den aktuellen offiziellen Stand, bevor Sie interne Fristen oder die letzte Gelegenheit zum Abschließen einer Aufgabe festlegen. Die Migrationsankündigung von Google Jules ist die maßgebliche Quelle für diese Termine.

Die wichtigste Unterscheidung lautet: Ein auf GitHub gespeicherter Commit ist nicht dasselbe wie eine vollständig übergebene Jules-Aufgabe. Code, Branches und Pull Requests liegen weiterhin im Repository. Gesprächsverlauf, persönliche Einstellungen, geplante Aufgaben oder andere im Dienst gespeicherte Angaben müssen dagegen im Rahmen des offiziellen Exports gesichert und anschließend auf Vollständigkeit geprüft werden.

Für eine laufende Aufgabe reicht es nicht, nur den Branch-Namen in eine Liste zu schreiben. Halten Sie für jede Sitzung fest, was Jules ändern sollte, welcher Stand tatsächlich vorliegt und welche Prüfung noch offen ist. Besonders riskant sind Aufgaben, deren Ergebnis nicht allein im Repository sichtbar ist, sowie Sitzungen, bei denen noch eine Freigabe, Rückfrage oder Korrekturrunde aussteht.

Alle drei Termine und Zustandsänderungen stammen aus der offiziellen Jules-Ankündigung. Der genaue Zeitpunkt innerhalb des Stichtags und eine mögliche spätere Änderung sollten nicht aus einer Zeitzone abgeleitet werden, die Google in einer Aktualisierung nicht ausdrücklich nennt.

Welche Sitzungen zuerst abgeschlossen oder übergeben werden sollten

Beginnen Sie mit Aufgaben, die einen festen Liefertermin haben, auf weitere Eingaben warten oder regelmäßig automatisch ausgelöst werden. Danach folgen Sitzungen, deren erwartetes Ergebnis oder Abnahmekriterium nur im Gesprächsverlauf nachvollziehbar ist. Eine einfache Priorisierung kann so aussehen:

• Zuerst: Aufgaben mit externem Termin, offenen Rückfragen oder noch nicht geprüften Änderungen.
• Danach: geplante oder wiederkehrende Aufgaben, deren Ausführung künftig von einem anderen Mechanismus übernommen werden muss.
• Anschließend: abgeschlossene Sitzungen, deren Verlauf, verwendete Vorgaben oder wichtige Entscheidungen für spätere Wartung gebraucht werden.
• Zuletzt: nicht mehr relevante Sitzungen, sofern ihre Entfernung nach den Regeln des Teams zulässig ist und die erforderlichen Aufzeichnungen bereits gesichert sind.

Für jede noch offene Sitzung sollte ein Übergabevermerk mindestens Repository, Branch oder Pull Request, erwartetes Ergebnis, tatsächlich erreichten Stand, Prüfkommando und zuständige Person für die manuelle Freigabe nennen. Damit wird verhindert, dass ein vorhandener Code-Stand irrtümlich als abgeschlossene Migration gilt.

Vor dem Nur-Lese-Modus: Jules Tools für den Export einsetzen

Für den lokalen Export sieht Google Jules Tools vor. Nutzen Sie die offizielle CLI-Referenz für Installation, Anmeldung und den dokumentierten Exportablauf; schreiben Sie keine Befehle aus einer alten Anleitung ab, ohne sie mit der aktuell veröffentlichten Dokumentation abzugleichen. Die Jules-Tools-CLI-Referenz ist die Quelle für die verfügbare Bedienung. Da dieser Beitrag keine ungeprüften Befehlszeilen oder versionsabhängigen Optionen wiedergibt, sollte die dort dokumentierte Syntax unmittelbar vor dem Lauf übernommen werden.

Vor dem Export ist entscheidend, dass die Anmeldung zum richtigen Konto und zum richtigen Arbeitsbereich erfolgt. Bei Teams mit mehreren Personen oder Google-Konten sollte eine zweite Person die Identität und den Umfang prüfen. Ein erfolgreich beendeter CLI-Prozess belegt zunächst nur, dass der Exportlauf beendet wurde; er beweist nicht, dass alle benötigten Informationen enthalten und lesbar abgelegt wurden.

Welche Informationen enthält der Export – und was bleibt in GitHub?

Die offizielle Ankündigung nennt Jules-Daten wie Einstellungen, Umgebungsvariablen, geplante Aufgaben, verbundene Repositories, Erinnerungen, Einrichtungsskripte und Sitzungsaktivitäten. Die genaue Form der Dateien sollte anhand des tatsächlichen Ergebnisses geprüft werden: Entscheidend ist nicht, ob ein Dateiname erwartet wurde, sondern ob die für den Betrieb benötigten Angaben im Export lesbar vorliegen. Die Ankündigung zum Exportumfang beschreibt zugleich die Grenze, dass bereits in GitHub gespeicherter Code, Branches und Pull Requests nicht Teil dieses Jules-Exports sind.

Ein Export ist kein standardisiertes Importpaket für einen anderen Agenten. Selbst wenn eine neue Lösung ähnliche Funktionen anbietet, müssen Eingaben, Berechtigungen, Trigger, Laufzeitumgebung und Freigabeschritte in der Regel einzeln neu eingerichtet und getestet werden. Die offizielle Produktseite von Google Antigravity beschreibt dieses Produkt, bestätigt aber keine automatische Übernahme von Jules-Daten oder Funktionsgleichheit. Behandeln Sie Antigravity daher nicht als bereits migrierten Ersatz, solange keine konkrete, offizielle Importzusage vorliegt.

Sicherheitshinweis: Exportdateien mit Umgebungsvariablen können geheime Werte enthalten. Begrenzen Sie den Zugriff auf den Export, übertragen Sie ihn nur über freigegebene Wege und legen Sie keine Geheimnisse in ein Repository. Die Dokumentation zu Geheimnissen in GitHub Actions erläutert den Umgang mit vertraulichen Werten in GitHub-Kontexten; die teaminternen Vorgaben zur Geheimnisverwaltung bleiben zusätzlich maßgeblich.

Nach dem Export: Vollständigkeit und Verantwortlichkeit nachweisen

Richten Sie die Prüfung nicht nur auf die Existenz eines Archivs. Ordnen Sie die exportierten Angaben den Aufgaben und Repositories zu, für die sie gebraucht werden. Ein kompakter Abgleich sollte mindestens diese Fragen beantworten:

• Sind die benötigten Repositories und deren Verknüpfungen dokumentiert?
• Sind die relevanten Einstellungen, Erinnerungen und Einrichtungsskripte vorhanden und verständlich?
• Lassen sich geplante Aufgaben einem Auslöser, einer Eingabe und einem erwarteten Ergebnis zuordnen?
• Sind wichtige Sitzungsentscheidungen nachvollziehbar, auch wenn der Agent sie nicht automatisch in Code umgesetzt hat?
• Sind sensible Werte geschützt und ist klar, wer auf das Exportarchiv zugreifen darf?
• Sind Code, Branches und Pull Requests separat in GitHub überprüft worden?

Für den GitHub-Code ist ein eigener Abgleich erforderlich. Prüfen Sie den letzten relevanten Commit, den Status offener Pull Requests und Änderungen, die in einer Jules-Sitzung vorgeschlagen, aber nicht übernommen wurden. Der Export sichert nicht automatisch alle Arbeitsstände, die bereits als Code in GitHub hätten landen müssen. Umgekehrt ist der GitHub-Stand kein Ersatz für die Begründungen, Aufgabenbeschreibungen oder Sitzungshistorie, die für spätere Wartung gebraucht werden.

Diese Trennung ist auch für Datenschutz und interne Prüfungen relevant. Legen Sie fest, welche Personen das Archiv lesen dürfen, wie lange es aufbewahrt wird und ob vertrauliche Werte vor einer teamweiten Weitergabe entfernt werden müssen. Die Hinweise zu Datenschutz und Datenverarbeitung können bei der Bewertung eines extern gehosteten Entwicklungsumfelds als ergänzende Orientierung dienen; sie ersetzen nicht die Datenschutzprüfung des eigenen Unternehmens oder die Vorgaben für den Jules-Export.

Vor der Übernahme: Einen repräsentativen GitHub-Kodierworkflow neu aufbauen

Wählen Sie einen überschaubaren, aber realen Auftrag aus dem bisherigen Arbeitsalltag: etwa eine klar abgegrenzte Fehlerbehebung mit vorhandenem Test. Verwenden Sie denselben Repository-Stand, dieselben Anforderungen und möglichst dieselben Testbedingungen wie bei einer typischen Jules-Aufgabe. Die Übernahme ist erst belastbar, wenn nicht nur ein plausibler Änderungsvorschlag entsteht, sondern auch Projektprüfung, Berechtigungen und menschliche Freigabe funktionieren.

Konkreter Ablauf für die Wiederherstellung

1. Wählen Sie eine Aufgabe, die sich wiederholen lässt. Schreiben Sie Repository, Ausgangsstand, Eingabe, gewünschte Änderung und Abnahmekriterien in eine neue Aufgabenbeschreibung. Nehmen Sie keine Geheimnisse oder privaten Werte in den Beispielauftrag auf.
2. Richten Sie den Repository-Zugriff mit minimal nötigen Rechten ein. Kontrollieren Sie, ob der Ersatz-Agent Änderungen nur vorschlagen oder auch Branches beziehungsweise Pull Requests erstellen darf. Bewahren Sie die Rechte nicht allein deshalb unverändert auf, weil sie im alten Ablauf vorhanden waren.
3. Übertragen Sie Vorbereitungsschritte einzeln. Prüfen Sie jedes Einrichtungsskript auf Pfade, erwartete Werkzeuge, Umgebungsvariablen und externe Dienste. Unklare oder überholte Schritte sollten erst nach technischer Prüfung in den neuen Ablauf aufgenommen werden.
4. Legen Sie Trigger und Laufverhalten neu fest. Bei geplanten Aufgaben muss eindeutig sein, wodurch sie ausgelöst werden, welche Eingaben sie erhalten und wohin Fehler gemeldet werden. Ein Eintrag im Jules-Export ist noch kein aktiver Zeitplan in einem anderen System.
5. Führen Sie dieselben projektrelevanten Prüfungen aus. Verwenden Sie die Testkommandos des Projekts und sichern Sie deren Ausgabe. Wenn die Prüfungen nicht laufen, dokumentieren Sie, ob die Ursache in Abhängigkeiten, Berechtigungen oder einer fehlenden Plattform liegt.
6. Prüfen Sie Änderung und Pull Request manuell. Bewerten Sie, ob die Änderung dem Auftrag entspricht, ob Tests tatsächlich ausgeführt wurden und ob ein Mensch die Freigabe erteilt hat. Legen Sie fest, wer bei Fehlern oder unvollständigem Ergebnis übernimmt.
7. Vergleichen Sie den neuen Durchlauf mit dem Übergabevermerk. Erst wenn Ergebnis, Testnachweis und Freigabeschritt zusammenpassen, kann die ausgewählte Aufgabe als migriert gelten. Übernehmen Sie nicht automatisch alle übrigen Jules-Aufgaben aufgrund dieses Einzeltests.

Damit lässt sich auch der Suchbedarf rund um „Jules Tools“ und den „GitHub-Kodierworkflow“ praktisch abdecken, ohne einen allgemeinen Agentenvergleich daraus zu machen. Die entscheidende Frage lautet nicht, ob ein neues Werkzeug ähnliche Funktionen auflistet, sondern ob der konkrete Repository-Auftrag mit denselben Sicherheits- und Abnahmekriterien wiederholbar ist.

Für macOS-Aufgaben: Plattformabhängigkeiten getrennt abnehmen

Nicht jede Agent-Aufgabe braucht einen Mac. Änderungen an plattformunabhängigem Code können häufig in der vorhandenen Linux- oder Windows-Umgebung geprüft werden, sofern die Projektabhängigkeiten und Tests dort unterstützt werden. Anders sieht es aus, wenn der Ablauf Xcode, den macOS-Buildprozess oder ein ausschließlich unter macOS verfügbares Werkzeug voraussetzt. In diesem Fall muss der neue Workflow die Plattform explizit bereitstellen und die Prüfung auf dieser Plattform durchführen.

Wenn das Team macOS-Builds über eine lokale Maschine abwickelt, sollten Verfügbarkeit, Wartung, Zugriff und Ausfallsicherung in die Entscheidung einfließen. Eine dauerhaft verfügbare Mac-Umgebung ist nur dann sinnvoll, wenn der Workflow sie tatsächlich benötigt und Verantwortliche Betrieb sowie Sicherheitskonfiguration übernehmen können. Eine gemietete Remote-Mac-Umgebung kann für zeitlich begrenzte Tests oder eine Übergangsphase geeigneter sein als ein ungeprüfter Neuaufbau eigener Hardware; sie ist aber nicht automatisch die passende Lösung für jeden Agent-Wechsel.

Der Kosten- und Betriebsvergleich sollte deshalb die realen Anforderungen berücksichtigen: Wie häufig laufen Builds? Muss eine Person direkt auf die grafische Oberfläche zugreifen? Gibt es Anforderungen an physische Geräte oder lokale Schnittstellen? Wie werden Zugangsdaten und Repository-Rechte geschützt? Die Übersicht zu Mac-Kauf und Mietoptionen eignet sich als Orientierung, um eigene Hardware und Remote-Nutzung anhand des konkreten Einsatzes gegenüberzustellen, nicht als Ersatz für einen technischen Test.

Nach dem Stichtag: Archiv, Repository und Ersatz-Workflow betreuen

Mit dem Wechsel in den Nur-Lese-Modus endet die operative Arbeit nicht. Benennen Sie eine verantwortliche Person für das Exportarchiv, eine für die GitHub-Repositories und eine für den Ersatz-Workflow. In kleinen Teams kann dieselbe Person mehrere Rollen übernehmen; wichtig ist, dass jede Zuständigkeit ausdrücklich festgehalten ist und nicht stillschweigend bei der Person verbleibt, die Jules ursprünglich eingerichtet hat.

Führen Sie in der Übergabedokumentation außerdem eine Liste der Inhalte, die nicht direkt wiederhergestellt wurden. Dazu zählen etwa manuell rekonstruierte Trigger, geänderte Geheimnisnamen, fehlende Sitzungskontexte oder Tests, die erst auf einer macOS-Umgebung laufen. So bleibt sichtbar, welche Teile der Migration tatsächlich geprüft wurden und welche noch eine spätere Nacharbeit benötigen.

Google Antigravity sollte nur dann in die Migrationsplanung aufgenommen werden, wenn eine offizielle Ankündigung die jeweils benötigte Importfunktion oder Datenübernahme ausdrücklich bestätigt. Die Produktbeschreibung allein belegt weder einen automatischen Import noch eine Gleichwertigkeit mit Jules. Ändert Google die Termine, den Exportumfang oder die dokumentierten Importmöglichkeiten, muss die Planung anhand der aktualisierten offiziellen Informationen neu bewertet werden.

Entscheidung vor dem Abschluss: Export plus erfolgreicher Probelauf

Die Migration ist abnahmefähig, wenn die benötigten Jules-Daten lokal gesichert und geprüft sind, der GitHub-Stand separat verifiziert wurde und ein repräsentativer Auftrag im Ersatz-Workflow samt Tests und menschlicher Freigabe erfolgreich durchlaufen ist. Ein Export ohne Prüfung bleibt ein Archiv unbekannter Vollständigkeit; ein Ersatz-Agent ohne reproduzierbaren Test bleibt eine Annahme.

Für viele Aufgaben sind die vorhandene Entwicklungsumgebung und ein neuer Agent ausreichend. Enthält der Ablauf dagegen zwingend Xcode oder ein anderes macOS-spezifisches Werkzeug, sollte die Plattformfrage vor der Produktwahl geklärt werden. Lokale Macs bieten direkten Gerätezugriff, verursachen aber Anschaffungs- und Wartungsaufwand; allgemeine Cloud- oder Linux-Umgebungen können bei macOS-Werkzeugen ungeeignet sein; ein Remote Mac bringt wiederum Abhängigkeiten von Netzwerk, Zugangsverwaltung und externer Infrastruktur mit sich. Für einen zeitlich begrenzten Übergang oder eine gezielte Build-Abnahme kann das Mieten eines Mac daher die passendere Option sein, sofern die technischen und Datenschutzanforderungen erfüllt sind.

Schließen Sie die Jules-Migration erst ab, wenn Archiv, GitHub-Repository und Ersatz-Workflow jeweils einen benannten Verantwortlichen haben. Falls der Testaufbau tatsächlich eine macOS-Umgebung benötigt, prüfen Sie die passende Remote-Mac-Option anhand der Anforderungen und verifizieren Sie den Build dort mit demselben Projekt und denselben Abnahmekriterien.