Symptom: Nach einem Aufgabenwechsel sehen Sie Ihre vorherigen Codeänderungen nicht mehr.
Schnellste Lösung: Öffnen Sie zuerst die ursprüngliche Aufgabe und prüfen Sie dort den Arbeitsbereich und den Diff. Codex Cloud verwendet für jede Aufgabe einen eigenen Arbeitsbereich; eine neue Aufgabe übernimmt nicht automatisch ungesicherte Änderungen aus einer anderen. Sichern Sie wichtige Ergebnisse deshalb nach Prüfung und Tests im Versionskontrollsystem. OpenAI beschreibt diese Trennung und das Fortsetzen einer bestehenden Aufgabe in der offiziellen Dokumentation.

Für Sie ist dieser Leitfaden gedacht, wenn Sie Codex Cloud unterwegs für Entwicklungsaufgaben nutzen und Änderungen nach einer Unterbrechung wiederfinden müssen.
Er hilft Ihnen, vor dem Wechsel vom Laptop zum iPad oder Telefon einen überprüfbaren Sicherungsstand herzustellen.
Wenn Sie an einem iOS-Projekt arbeiten, erfahren Sie außerdem, wann nach der Codearbeit noch eine Prüfung in einer macOS-Umgebung nötig ist.

Zuletzt aktualisiert am 08.11.2026. Geprüft anhand der offiziellen Codex-Cloud-Dokumentation von OpenAI und der verlinkten offiziellen Dokumentation zu GitHub und Xcode.

Zuerst die vier Zustände auseinanderhalten

Wenn eine Änderung scheinbar verschwunden ist, heißt das nicht automatisch, dass sie gelöscht wurde. Prüfen Sie zunächst, an welcher Stelle Sie nachsehen. Im Alltag werden vier verschiedene Dinge leicht miteinander verwechselt:

  • Aufgabenverlauf: die Unterhaltung und die Anweisungen, die zu einer Aufgabe gehören.
  • Aufgabenarbeitsbereich: die Dateien und Änderungen in der isolierten Umgebung dieser Aufgabe.
  • Gespeicherter VM-Zustand: ein gespeicherter Zustand der virtuellen Umgebung, dessen Wiederherstellung laut Dokumentation einem begrenzten Zeitfenster unterliegt.
  • Git-Repository: die Versionierung, in der Sie Änderungen nach einem Commit nachvollziehbar festhalten können.

Dass Sie eine Unterhaltung noch sehen, beweist nicht, dass alle Dateien weiterhin in einer wiederherstellbaren Umgebung vorliegen. Ebenso bedeutet eine Änderung im Arbeitsbereich nicht, dass sie bereits in GitHub angekommen ist. OpenAI unterscheidet in seiner Dokumentation zwischen Aufgabe, Umgebung und gespeicherten VM-Zuständen. Behandeln Sie diese deshalb als getrennte Prüfstellen und nicht als eine einzige, dauerhaft gesicherte Ablage.

Auf Reisen wird die Unterscheidung besonders wichtig: Sie wechseln das Gerät, öffnen aus Gewohnheit eine neue Aufgabe oder verlieren die Verbindung, während ein Lauf noch nicht vollständig geprüft ist. Wenn Sie dann nur in der Aufgabenliste oder im Repository suchen, übersehen Sie womöglich die ursprüngliche Arbeitsumgebung.

Warum sehe ich den Chat, aber nicht die Änderung im Repository?
Weil eine sichtbare Aufgabe und ein Git-Commit verschiedene Nachweise sind. Öffnen Sie die ursprüngliche Aufgabe, prüfen Sie dort die Dateien und den Diff und kontrollieren Sie separat, ob die Änderung tatsächlich im Repository gespeichert wurde.

Bei fehlenden Änderungen die ursprüngliche Aufgabe öffnen

Beginnen Sie nicht mit einer neuen Aufgabe. Suchen Sie zuerst in der Aufgabenübersicht den ursprünglichen Lauf und öffnen Sie ihn. Prüfen Sie anschließend, ob Sie die Aufgabe fortsetzen können und ob die erwarteten Dateien im zugehörigen Arbeitsbereich sichtbar sind. Vergleichen Sie den Diff mit dem Zustand, den Sie erwartet haben.

Codex Cloud weist Aufgaben jeweils einen eigenen Arbeitsbereich zu. Eine neue Aufgabe stellt daher keine automatische Fortsetzung des Arbeitsbereichs einer älteren Aufgabe dar. Wenn Sie eine neue Aufgabe mit ähnlichen Anweisungen starten, kann sie zwar erneut Änderungen erzeugen, aber das ist nicht dasselbe, wie die ungesicherten Dateien aus der vorherigen Umgebung zurückzuholen. Für die Abgrenzung zwischen neuer und fortgesetzter Aufgabe ist die OpenAI-Dokumentation zu Codex Cloud maßgeblich.

Übernimmt eine neu erstellte Codex-Cloud-Aufgabe die Änderungen der vorherigen Aufgabe?
Nein, verlassen Sie sich nicht darauf. Öffnen Sie für vorhandene, noch nicht übernommene Änderungen die ursprüngliche Aufgabe. Nutzen Sie eine neue Aufgabe erst dann, wenn Sie den benötigten Code in ein Repository übernommen oder auf andere Weise überprüfbar gesichert haben.

Ein häufiger Fehlgriff ist, aus dem neuen Arbeitsbereich heraus erneut dieselbe Änderung anzufordern. Das kann zu doppelten oder widersprüchlichen Bearbeitungen führen. Halten Sie stattdessen fest, welche Aufgabe die betreffende Änderung enthält, und bearbeiten Sie diese weiter. Wenn Sie bewusst eine neue Aufgabe brauchen, geben Sie ihr einen klaren Auftrag und stellen Sie den aktuellen Repository-Stand bereit.

So gehen Sie vor, wenn eine Datei fehlt

  1. Öffnen Sie die ursprüngliche Aufgabe, nicht nur den zuletzt verwendeten Chat.
  2. Prüfen Sie den Aufgabenstatus und ob die Umgebung dieser Aufgabe erreichbar ist.
  3. Suchen Sie die erwartete Datei im Arbeitsbereich und öffnen Sie den Diff.
  4. Vergleichen Sie die Änderung mit dem aktuellen Stand des zugehörigen Repositorys.
  5. Wenn die Datei im Arbeitsbereich fehlt, prüfen Sie, ob die Aufgabe tatsächlich die Datei bearbeitet hat oder ob die Änderung bereits in einem anderen Commit gelandet ist.
  6. Starten Sie erst danach eine neue Aufgabe oder ändern Sie den Auftrag.

Dokumentieren Sie bei einem unerwarteten Ergebnis kurz den Aufgabennamen, die betroffene Datei und den zuletzt sichtbaren Zustand. Diese Notiz ersetzt keinen Commit. Sie verhindert aber, dass Sie beim Wiederaufnehmen des Projekts eine zweite, abweichende Bearbeitung für dieselbe Änderung beginnen.

Unterbrechungen über den Zustand der Aufgabe prüfen

Eine unterbrochene Verbindung sagt für sich genommen nicht aus, ob der Code erhalten blieb. Sie kann lediglich bedeuten, dass Ihr Gerät den Dienst vorübergehend nicht erreicht. Auch ein späterer Blick auf den Aufgabenverlauf verrät nicht automatisch, ob die virtuelle Umgebung wiederherstellbar ist.

Gehen Sie deshalb in dieser Reihenfolge vor: Öffnen Sie die ursprüngliche Aufgabe, prüfen Sie den angezeigten Status und versuchen Sie, die zugehörige Umgebung aufzurufen. Wenn die Dateien erreichbar sind, sichern Sie die Änderung zuerst im Repository. Wenn die Umgebung nicht erreichbar ist, unterscheiden Sie zwischen einem Zugriffsproblem, einem nicht verfügbaren Aufgabenstatus und einer fehlenden Git-Übernahme. Das sind verschiedene Fehlerbilder und brauchen unterschiedliche nächste Schritte.

Wie setzen Sie eine pausierte Codex-Cloud-Aufgabe fort?
Öffnen Sie den ursprünglichen Aufgabenverlauf und verwenden Sie die dort angebotene Fortsetzung, sofern sie verfügbar ist. Beginnen Sie nicht vorschnell mit einer neuen Aufgabe: Diese erhält nicht automatisch den ungesicherten Arbeitsbereich der pausierten Aufgabe.

OpenAI beschreibt für gespeicherte VM-Zustände ein begrenztes Wiederherstellungsfenster. Diese Aussage bezieht sich auf den gespeicherten Zustand der virtuellen Umgebung, nicht auf eine Garantie, dass jede Datei, jeder Aufgabenverlauf oder jedes Konto dauerhaft wiederherstellbar bleibt. Die Grenze ist wichtig: Eine noch sichtbare Unterhaltung ist kein Beleg dafür, dass der gespeicherte VM-Zustand weiterhin verfügbar ist. Prüfen Sie für die aktuell geltende Frist und deren Anwendungsbedingungen die offizielle Dokumentation zu Codex Cloud, bevor Sie eine Wiederherstellung einplanen.

Wie lange bleibt ein gespeicherter Arbeitsbereich wiederherstellbar?
Die offizielle Dokumentation nennt ein begrenztes Fenster für gespeicherte VM-Zustände. Wenden Sie dieses Fenster nur auf den dort beschriebenen VM-Zustand an und lesen Sie die aktuelle Angabe direkt in der Dokumentation nach. Leiten Sie daraus keine unbegrenzte Aufbewahrung von Aufgabenverlauf oder Dateien ab.

Für die Reiseplanung bedeutet das: Verschieben Sie wichtige Änderungen nicht auf einen späteren Zeitpunkt, an dem Sie wieder Zugang zu einem bestimmten Gerät haben. Sobald ein Ergebnis geprüft ist, gehört es in eine nachvollziehbare Versionskontrolle. Der gespeicherte Zustand einer VM ist eine Möglichkeit zur Wiederaufnahme, aber kein Ersatz für einen Commit.

Änderungen vor dem Gerätewechsel überprüfen und sichern

Ein belastbarer Ablauf trennt die Prüfung vom Speichern. Ein grüner Abschlussstatus oder eine Antwort in der Unterhaltung ist kein Ersatz dafür, den Code anzusehen. Lesen Sie den Diff, prüfen Sie betroffene Dateien und führen Sie die passenden Projekttests aus. Erst dann entscheiden Sie, ob die Änderung in den gemeinsamen Branch übernommen werden soll.

Nutzen Sie vor dem Wechsel auf ein anderes Gerät diese kurze Abnahme:

  1. Aufgabe zuordnen: Stellen Sie sicher, dass Sie die Aufgabe geöffnet haben, in der die Änderung entstanden ist.
  2. Diff prüfen: Kontrollieren Sie, welche Dateien geändert, hinzugefügt oder entfernt wurden.
  3. Tests ausführen: Verwenden Sie die zum Projekt passenden Prüfungen. Notieren Sie, was erfolgreich war und was nicht ausgeführt werden konnte.
  4. Änderung übernehmen: Erstellen Sie einen Commit, wenn der Stand geprüft und für die Versionskontrolle geeignet ist.
  5. Repository kontrollieren: Prüfen Sie, ob der Commit tatsächlich im erwarteten Repository und Branch sichtbar ist.
  6. Fortsetzung festhalten: Notieren Sie offene Punkte, Testergebnisse und die nächste geplante Arbeit.

GitHub beschreibt das Hinzufügen und Committen von Dateien als einen eigenen Schritt. Das ist nicht mit dem Zustand einer Codex-Cloud-Aufgabe gleichzusetzen. Wenn Sie mit GitHub Desktop arbeiten, erläutert die offizielle Anleitung das Pushen von Änderungen an GitHub. Die GitHub-Anleitung zum Hinzufügen und Committen einer Datei hilft, den Unterschied zwischen lokaler Änderung und Repository-Eintrag nachzuvollziehen.

Wie übernehmen Sie Codex-Cloud-Änderungen nach GitHub?
Prüfen Sie zuerst den Diff und die Tests. Committen Sie die Änderung im vorgesehenen Repository und Branch. Prüfen Sie danach, ob der Push erfolgreich war und der Commit auf GitHub sichtbar ist. Eine Änderung, die nur im Arbeitsbereich der Aufgabe liegt, ist noch kein Nachweis für eine erfolgreiche Übernahme in GitHub.

Ein fehlgeschlagener Push ist nicht automatisch ein verlorener Arbeitsbereich. Prüfen Sie getrennt, ob die Dateien noch in der ursprünglichen Aufgabe vorhanden sind und ob Ihr Konto die nötigen Rechte zum Repository hat. GitHub erläutert, wie die Authentifizierung für den Repository-Zugriff funktioniert. Ist der Zielbranch geschützt, können außerdem Regeln für direkte Änderungen gelten; dazu finden Sie die Dokumentation zu geschützten Branches.

Entscheidungshilfe: Arbeitsbereich, Repository oder Abnahme?

Gehen Sie die Punkte der Reihe nach durch. Markieren Sie jeden zutreffenden Zustand und folgen Sie der angegebenen Entscheidung, statt vorschnell eine neue Aufgabe zu starten.

  • [ ] Die Dateien sind im ursprünglichen Arbeitsbereich sichtbar. Öffnen Sie den Diff, führen Sie die passenden Tests aus und sichern Sie den geprüften Stand durch einen Commit.
  • [ ] Die Dateien sind sichtbar, aber der Push schlägt fehl. Lassen Sie die ursprüngliche Aufgabe geöffnet und prüfen Sie Anmeldung, Repository-Berechtigungen und Branch-Regeln. Behandeln Sie den Push-Fehler nicht als Verlust des Arbeitsbereichs.
  • [ ] Der Aufgabenverlauf ist sichtbar, die Umgebung jedoch nicht erreichbar. Prüfen Sie den Aufgabenstatus und die offizielle Information zum Wiederherstellungsfenster für VM-Zustände. Leiten Sie aus der sichtbaren Unterhaltung keine Dateisicherung ab.
  • [ ] Der Commit ist im erwarteten Repository und Branch sichtbar. Arbeiten Sie auf diesem überprüfbaren Stand weiter und notieren Sie noch offene Tests.
  • [ ] Es gibt weder einen sichtbaren Diff noch einen Commit. Prüfen Sie zuerst die ursprüngliche Aufgabe und ihren Verlauf. Fordern Sie die Arbeit erst erneut an, wenn Sie die vorhandene Umgebung kontrolliert haben.
  • [ ] Der Code ist gesichert, aber die iOS-Abnahme fehlt. Lassen Sie den Commit im Repository und planen Sie den nötigen macOS- oder Xcode-Schritt separat.

Diese Abnahme trennt drei Fragen, die unterwegs leicht zusammenfallen: Sind die Dateien noch in der Aufgabe erreichbar? Ist ein nachvollziehbarer Stand im Repository gespeichert? Sind alle für die Auslieferung nötigen Tests tatsächlich gelaufen? Ein positives Ergebnis bei einer Frage beantwortet die beiden anderen nicht automatisch.

Nach dem Gerätewechsel mit einem Beleg weiterarbeiten

Wenn Sie am Reisetag vom Laptop auf ein iPad wechseln, brauchen Sie keine Vermutung, welcher Arbeitsstand aktuell ist. Sie brauchen einen Nachweis, den Sie auf dem nächsten Gerät kontrollieren können: den ursprünglichen Aufgabenverlauf, einen geprüften Diff oder einen Commit im Repository.

Nehmen Sie für eine kurze Unterbrechung die ursprüngliche Aufgabe wieder auf und kontrollieren Sie den Status. Bei einer längeren Pause beginnen Sie mit dem Repository-Stand und vergleichen ihn mit den Änderungen der Aufgabe. Stimmen die Dateien überein und ist der Commit sichtbar, fahren Sie auf dieser Basis fort. Ist nur die Unterhaltung sichtbar, suchen Sie nach dem Arbeitsbereich und prüfen Sie, ob die Umgebung noch erreichbar ist. Erstellen Sie keine neue Aufgabe, solange unklar ist, ob Sie dadurch eine zweite Bearbeitung neben der ursprünglichen beginnen.

Beachten Sie auch, dass ein anderer Gerätetyp nicht dieselbe Zugriffssituation garantiert. Ein Telefon oder iPad kann für die Kontrolle eines Diffs und für kurze Anweisungen ausreichen, aber eine instabile Verbindung kann die Arbeit unterbrechen. Das ist ein Verfügbarkeitsproblem und nicht automatisch ein Beleg für verlorene Dateien. Wenn die Aufgabe erreichbar ist, setzen Sie am ursprünglichen Ort fort; wenn der Repository-Zugriff scheitert, prüfen Sie Anmeldung und Berechtigungen separat.

Für vertrauliche Projekte sollten Sie zusätzlich kontrollieren, welches Konto Zugriff auf das Repository und die Umgebung hat. Speichern Sie keine Zugangsdaten in einer Notiz, die Sie auf gemeinsam genutzten Geräten offenlassen. Für den Umgang mit Repository-Rechten sind die GitHub-Hinweise zur Authentifizierung und zu geschützten Branches maßgeblich; die Zugriffskontrolle ersetzt jedoch keine Codeprüfung und keinen Commit.

iOS-Codearbeit und Mac-Abnahme getrennt planen

Codex Cloud kann Ihnen bei Codeänderungen helfen. Daraus folgt nicht, dass die Aufgabe in einer macOS- oder Xcode-Umgebung ausgeführt wurde. Wenn Ihr iOS-Projekt für die Abnahme Werkzeuge oder einen Build benötigt, die an macOS gebunden sind, planen Sie diesen Arbeitsschritt gesondert ein. Prüfen Sie die Anforderungen des konkreten Projekts und die offizielle Xcode-Dokumentation von Apple.

Entscheiden Sie nach dem tatsächlichen Lieferumfang:

  • Wenn Sie lediglich Quelldateien ändern und den Code überprüfen müssen, kann der Cloud-Aufgabenarbeitsbereich für diesen Teil genügen.
  • Wenn Ihr Team einen nativen Build, einen Testlauf in Xcode oder eine andere macOS-gebundene Prüfung verlangt, verlagern Sie die Abnahme nicht stillschweigend auf Codex Cloud.
  • Wenn Sie mobil arbeiten, übernehmen Sie zunächst den geprüften Code in die Versionskontrolle. Führen Sie die noch ausstehenden macOS-Schritte anschließend in einer dafür geeigneten Umgebung aus.

Diese Trennung schützt auch die Fehlersuche. Ein nicht ausgeführter Xcode-Build ist kein Beleg dafür, dass die Codeänderung verloren ist. Umgekehrt beweist ein erfolgreicher Codex-Lauf nicht, dass ein iOS-Projekt nativ gebaut oder getestet wurde.

Wenn Sie für die zweite Phase einen Remote Mac erwägen, prüfen Sie zuerst, ob der Zugriff auf macOS tatsächlich Teil Ihrer Abnahme ist. Für einen zeitlich begrenzten Test kann eine gemietete Umgebung eine Alternative zum Mitführen eines zusätzlichen Rechners sein. Prüfen Sie vorab Netzwerkzugang, Repository-Rechte, Datenschutzvorgaben und die Übergabe des Projekts. Sie können sich zunächst in der MACCOME-Übersicht zu Remote-Mac-Optionen orientieren und anschließend die Mac-mini-Mietoptionen bei MACCOME mit Ihrem Bedarf an einer tatsächlichen Xcode- und macOS-Prüfung abgleichen. Für eine längerfristige, dauerhaft hohe Nutzung oder erforderliche physische Anschlüsse kann ein eigener Mac die passendere Wahl sein.

Vor dem nächsten Aufgabenwechsel: Öffnen Sie die ursprüngliche Aufgabe, prüfen Sie den Diff, führen Sie die passenden Tests aus und committen Sie wichtige Änderungen. So bleibt der Arbeitsstand auch dann nachvollziehbar, wenn Sie das Gerät wechseln oder die VM-Wiederherstellung nicht mehr verfügbar ist. Wenn Ihr iOS-Projekt anschließend macOS-Werkzeuge benötigt, können Sie mit einem Remote Mac von MACCOME die native Abnahme durchführen, ohne Codex Cloud mit einer Mac-Umgebung gleichzusetzen.