Codex CLI: Kurscode nach Änderungen prüfen – Studenten-Checkliste 2026

git diff --check kann auf bestimmte Leerzeichenfehler in Änderungen hinweisen; es bestätigt aber nicht, dass Ihr Programm die Aufgabe erfüllt (Git-Dokumentation zu git diff). Für die Codex-CLI-Abnahme von Kurscode gilt deshalb diese Reihenfolge: Sichern Sie zuerst den Ausgangsstand, prüfen Sie dann die tatsächlichen Änderungen, führen Sie die vorgeschriebenen Tests aus und gleichen Sie das Verhalten mit der Aufgabenstellung ab. Erst danach entscheiden Sie über die Abgabe. Ist Xcode oder ein iOS-Simulator ausdrücklich Teil der Anforderungen, prüfen Sie diesen Teil in einer kompatiblen Mac-Umgebung.

Dieser Ablauf ist für Sie gedacht, wenn Sie Codex CLI zum ersten Mal an einem Kursprojekt arbeiten lassen und unsicher sind, was Sie vor der Abgabe kontrollieren müssen.
Er hilft Ihnen auch, wenn Sie bereits Code ausführen können, aber Git-Diffs und Testergebnisse noch nicht sicher einordnen.
Wenn Sie nur einen Windows-Rechner haben, erfahren Sie außerdem, welche Prüfungen dort möglich sind und wofür Sie tatsächlich einen Mac benötigen.

Zuletzt geprüft am 13.10.2026. Angaben zu Codex CLI gleichen Sie mit den offiziellen Einstiegsinformationen und der offiziellen Projektdokumentation ab. Kursregeln und Testbefehle richten sich weiterhin nach Ihrer konkreten Aufgabenstellung und den Dateien Ihres Projekts.

SECTION 01 Vor der Änderung: Ausgangspunkt und Auftrag festhalten

Beginnen Sie nicht mit der Frage, ob Codex CLI „fertig“ meldet. Legen Sie zuerst fest, woran Sie später erkennen, ob die Änderung gelungen ist. Dafür brauchen Sie einen bekannten Ausgangsstand, eine verständliche Aufgabenbeschreibung und einen klaren Ort, an dem Sie das Projekt ausführen.

Arbeiten Sie im richtigen Projektordner. Prüfen Sie den Ordnernamen und öffnen Sie die Dateien, die zur Aufgabe gehören. Bei mehreren Übungsprojekten oder ähnlichen Dateinamen ist das keine Nebensache: Eine Änderung im falschen Ordner kann plausibel aussehen und trotzdem am abgegebenen Projekt vorbeigehen.

Lesen Sie die Aufgabenstellung noch einmal und markieren Sie die konkreten Anforderungen. Fragen Sie sich: Welche Eingabe soll das Programm verarbeiten? Welches Ergebnis muss es liefern? Gibt es Vorgaben für Dateinamen, Bibliotheken, Benutzeroberfläche oder Abgabeformat? Schreiben Sie diese Anforderungen in eigenen Worten auf. So lässt sich später unterscheiden, ob eine Änderung die Aufgabe löst oder nur zusätzlichen, nicht verlangten Code erzeugt.

Sichern Sie den ursprünglichen Stand, bevor das Werkzeug Dateien bearbeitet. Wenn das Projekt bereits mit Git verwaltet wird, prüfen Sie zunächst den Status und erstellen Sie bei Bedarf einen nachvollziehbaren Sicherungspunkt. Alternativ können Sie eine Kopie des Projektordners anlegen. Entscheidend ist nicht die Methode, sondern dass Sie zum bekannten Zustand zurückkehren können, ohne wichtige eigene Arbeit zu verlieren.

Geben Sie Codex CLI anschließend einen begrenzten Auftrag: Beschreiben Sie die gewünschte Änderung, nennen Sie die betroffenen Dateien, sofern Sie sie kennen, und bitten Sie darum, keine nicht relevanten Teile des Projekts anzupassen. Die offizielle Codex-CLI-Einführung und die Dokumentation des offiziellen Repositorys sind die passenden Stellen, um veränderliche Angaben zur aktuellen Bedienung und zu Funktionen nachzuschlagen. Eine gut eingegrenzte Aufgabe macht die spätere Prüfung leichter; sie ersetzt sie nicht.

SECTION 02 Direkt nach der Änderung: Dateiliste und Diff prüfen

Nach der Bearbeitung vergleichen Sie zuerst den tatsächlichen Projektzustand mit Ihrem Ausgangspunkt. Die Erklärung von Codex CLI kann dabei eine Orientierung sein, ist aber kein Nachweis dafür, dass genau die beschriebenen Dateien geändert wurden. Maßgeblich sind die Dateien selbst.

Prüfen Sie zunächst die Liste der geänderten Dateien. Fragen Sie bei jeder Datei: Gehört sie zu meiner Aufgabe? Ist eine Konfigurationsdatei, ein Abgabedokument oder ein anderer Projektteil hinzugekommen, den ich nicht erwartet habe? Gibt es eine Datei, die laut Aufgabenstellung geändert werden sollte, aber unverändert blieb? Eine überraschende Änderung ist nicht automatisch falsch; sie muss aber verständlich und begründet sein.

Öffnen Sie danach den zeilenweisen Vergleich. Ein Diff zeigt, welche Zeilen gegenüber dem vorherigen Stand hinzugefügt, entfernt oder verändert wurden. Mit Git lässt sich ein normaler Vergleich der Änderungen im Arbeitsverzeichnis über git diff aufrufen; bereits zum nächsten Versionsstand vorgemerkte Änderungen werden mit einer eigenen Diff-Ansicht geprüft. Die genaue Bedeutung der Vergleichsvarianten steht im Git-Handbuch zu git diff.

Gehen Sie den Diff nicht nur überfliegend durch. Lesen Sie den Zusammenhang um jede Änderung herum. Eine Zeile kann einzeln vernünftig aussehen und dennoch eine bestehende Funktion außer Kraft setzen. Achten Sie besonders auf geänderte Bedingungen, Standardwerte, Pfade, Abhängigkeiten, Startskripte und Namen, die in mehreren Dateien vorkommen.

Neue, noch nicht von Git erfasste Dateien erfordern eine eigene Kontrolle: Sie tauchen nicht zwingend in einem gewöhnlichen Diff zwischen bekannten Versionen auf. Öffnen Sie deshalb den Projektordner zusätzlich in der Dateiansicht und prüfen Sie, ob neue Dateien zur Lösung gehören. Speichern oder markieren Sie nichts als endgültige Abgabe, bevor Sie wissen, welche Dateien tatsächlich dazugehören.

Wenn Sie eine Änderung nicht zuordnen können, halten Sie an. Fragen Sie gezielt nach ihrem Zweck oder vergleichen Sie sie mit dem vorher gesicherten Stand. Nehmen Sie nicht vorsorglich alle Zusatzänderungen an, nur weil sie zusammen mit der gewünschten Lösung entstanden sind.

SECTION 03 Vor dem Test: Änderung selbst erklären können

Ein plausibler Diff ist noch keine verständliche Lösung. Bevor Sie Tests starten, sollten Sie den wesentlichen Ablauf mit eigenen Worten erklären können: Welche Eingabe kommt an? Welche Verarbeitung findet statt? Wo entsteht das erwartete Ergebnis? Das ist keine Prüfung auf professionelle Formulierungen, sondern ein Schutz gegen Änderungen, die Sie nicht beurteilen oder später nicht bearbeiten können.

Prüfen Sie zuerst den Bezug zur Unterrichtseinheit. Wenn die Aufgabe gerade Bedingungen, Schleifen oder Funktionen üben soll, fragen Sie sich, ob die Änderung diese Lernziele tatsächlich verwendet oder ob ein unerwarteter Umweg eingeführt wurde. Ein technisch funktionierendes Ergebnis kann an einer Kursvorgabe vorbeigehen, wenn es eine verlangte Methode auslässt oder zusätzliche Hilfsmittel verwendet, die nicht erlaubt sind.

Suchen Sie im Diff und im Projektordner nach neuen Abhängigkeiten und Konfigurationsdateien. Eine Bibliothek kann die Lösung erleichtern, aber die Installation, erlaubte Nutzung und spätere Ausführung beeinflussen. Prüfen Sie außerdem, ob sich Anweisungen zum Starten des Projekts geändert haben. Folgen Sie den Kursregeln; installieren oder verändern Sie auf einem verwalteten Schulgerät keine Software, wenn Ihnen dafür die Berechtigung fehlt.

Für jede unerklärte Änderung gilt eine klare Abzweigung:

• Können Sie den Zweck erklären und ist die Änderung von der Aufgabe gedeckt, behalten Sie sie für die anschließende Prüfung.
• Gehört die Änderung nicht zur Aufgabe oder widerspricht sie einer Kursvorgabe, halten Sie die Abgabe an und vergleichen Sie mit dem Sicherungsstand.
• Können Sie nicht beurteilen, ob sie nötig ist, fragen Sie nach einer Erklärung und prüfen Sie die betroffenen Stellen selbst, statt die Änderung blind zu übernehmen.
• Scheitert die Erklärung auch nach einer gezielten Nachfrage, gehen Sie auf den letzten nachvollziehbaren Stand zurück und bearbeiten Sie nur den klaren Aufgabenteil erneut.

So bleibt die Verantwortung für die Abgabe bei Ihnen. Die offiziellen Codex-CLI-Unterlagen erklären das Werkzeug und seine aktuelle Bedienung; ob eine Lösung den Erwartungen Ihrer Lehrkraft entspricht, ergibt sich dagegen aus der Aufgabenstellung und dem Kursmaterial.

SECTION 04 Testphase: Kursvorgaben zuerst ausführen

Führen Sie die Tests aus, die Ihre Lehrkraft oder die Projektbeschreibung verlangt. Verwenden Sie nicht einfach einen beliebigen Befehl aus einem fremden Tutorial: Je nach Projekt können Start, Testausführung und benötigte Abhängigkeiten unterschiedlich sein. Lesen Sie zuerst die vorhandene Dokumentation und halten Sie den tatsächlich verwendeten Befehl sowie das beobachtete Ergebnis fest.

Bei einem Python-Projekt kann eine Aufgabe beispielsweise eigene Tests oder einen ausdrücklich vorgegebenen Startablauf enthalten. Wenn das Projekt unittest verwendet, beschreibt die Python-Dokumentation zu unittest, wie Tests organisiert und ausgeführt werden. Daraus folgt nicht, dass jedes Python-Projekt denselben Aufruf verwenden muss: Entscheidend bleiben die Projektdateien und die Kursanleitung.

Bei einer Webseite starten Sie das Projekt nach den vorhandenen Anweisungen und prüfen Sie die verlangten Seiten und Abläufe im Browser. Kontrollieren Sie nicht nur, ob sich eine Seite öffnet. Testen Sie die Eingaben, Schaltflächen oder Zustandswechsel, die in der Aufgabenstellung genannt sind. Falls die Aufgabe ein bestimmtes Verhalten bei ungültigen oder fehlenden Eingaben verlangt, prüfen Sie auch diesen Fall, statt ausschließlich den einfachsten Ablauf zu verwenden.

Notieren Sie Ergebnisse so, dass Sie sie später nachvollziehen können: Welcher Test oder Ablauf wurde ausgeführt? Was sollte geschehen? Was ist tatsächlich geschehen? Bei einem Fehler unterscheiden Sie zunächst zwischen einem Fehler im Programm, einer fehlenden Abhängigkeit, einem Startproblem und einer unklaren Kursvorgabe. Diese Ursachen verlangen unterschiedliche nächste Schritte. Eine Fehlermeldung allein beweist noch nicht, dass Codex CLI den Code falsch geändert hat.

Ein erfolgreiches Testergebnis gilt nur für den geprüften Bereich. Es belegt nicht automatisch, dass alle Seiten, Eingaben, Sonderfälle oder Abgabeanforderungen erfüllt sind. Auch die offizielle Dokumentation zum Ausführen von Tests und Interpretieren von Ergebnissen in Xcode trennt Testausführung und die Auswertung ihrer konkreten Ergebnisse. Für Ihre Kursabgabe heißt das: Prüfen Sie, was der Test abdeckt, und ergänzen Sie fehlende Aufgabenanforderungen durch gezielte eigene Kontrollen.

SECTION 05 Vor der Abgabe: Ergebnis gegen Anforderungen entscheiden

Legen Sie Aufgabenstellung, tatsächliches Verhalten und einzureichende Dateien nebeneinander. Prüfen Sie jede Anforderung einzeln, anstatt aus einem gelungenen Start oder einer grünen Testanzeige auf vollständige Abgabereife zu schließen. Bei jeder Vorgabe sollten Sie eine konkrete Beobachtung oder einen passenden Test benennen können.

Kontrollieren Sie außerdem, ob das Projekt nach der Änderung weiterhin startbar ist. Schließen Sie es nicht unmittelbar nach einem einzelnen erfolgreichen Test als „erledigt“ ab: Starten Sie es nach den Projektanweisungen erneut und prüfen Sie den zentralen Ablauf noch einmal. Das ist besonders hilfreich, wenn sich Startdateien, Abhängigkeiten oder Konfigurationen geändert haben.

Sehen Sie sich die Dateiliste ein letztes Mal an. Stimmen die verlangten Abgabedateien? Sind versehentliche Kopien, temporäre Dateien oder private Zugangsdaten hinzugekommen? Enthält das Projekt Dateien, die Sie für die Abgabe nicht einreichen dürfen? Diese Prüfung richtet sich nach den Regeln Ihrer Lehrkraft und dem Abgabeportal; es gibt keine universelle Dateiliste für alle Kurse.

Entscheidungspfad für die Abgabe

Gehen Sie die Bedingungen in dieser Reihenfolge durch. Sobald eine Bedingung nicht erfüllt ist, verwenden Sie den angegebenen Rückweg, statt die Prüfung als bestanden abzuhaken.

1. Sind die tatsächlichen Änderungen im Diff nachvollziehbar und auf die Aufgabe bezogen? - Ja: Fahren Sie mit der Erklärbarkeit fort. - Nein: Geben Sie nicht ab. Prüfen Sie die betroffenen Dateien und vergleichen Sie sie mit dem gesicherten Ausgangsstand.

2. Können Sie die wesentlichen Änderungen in eigenen Worten erklären und sind zusätzliche Abhängigkeiten oder Dateien erlaubt? - Ja: Führen Sie die vorgeschriebenen Tests aus. - Nein: Halten Sie die Abgabe an. Fragen Sie nach dem Zweck der Änderung oder kehren Sie zum letzten nachvollziehbaren Stand zurück.

3. Wurden die Kurs- oder Projekttests tatsächlich ausgeführt und ist das Ergebnis erfolgreich? - Ja: Gleichen Sie das geprüfte Verhalten mit jeder einzelnen Aufgabenanforderung ab. - Nein: Unterscheiden Sie zwischen Codefehler, Umgebungsproblem und unklarer Kursvorgabe. Melden Sie einen nicht ausgeführten Test nicht als bestanden.

4. Sind alle Anforderungen geprüft, ist das Projekt erneut startbar und sind die verlangten Abgabedateien vollständig? - Ja: Bereiten Sie die Abgabe nach den Kursregeln vor. - Nein: Ergänzen Sie den fehlenden Test, korrigieren Sie den konkret festgestellten Fehler oder klären Sie die offene Vorgabe, bevor Sie abgeben.

5. Verlangt der Kurs Xcode, einen iOS-Simulator oder einen Lauf auf einem Apple-Gerät? - Ja: Planen Sie zusätzlich die passende Prüfung in einer kompatiblen Mac-Umgebung und halten Sie sie getrennt von den bereits erledigten allgemeinen Codeprüfungen fest. - Nein: Sie brauchen für die Abnahme keinen Mac allein deshalb, weil Codex CLI den Code geändert hat.

Dieser Entscheidungspfad verhindert, dass ein erfolgreicher Einzeltest als pauschale Freigabe verstanden wird. Wenn ein Test wegen eines fehlenden Werkzeugs nicht startet, vermerken Sie genau diese Einschränkung. Schreiben Sie nicht „bestanden“, wenn der Test gar nicht ausgeführt wurde.

SECTION 06 Xcode-Sonderfall: Mac-Prüfung nur bei Kursanforderung

Allgemeine Codeprüfung und Xcode-Abnahme sind nicht dasselbe. Den Diff können Sie in einer passenden Git-Umgebung prüfen; viele sprach- und projektbezogene Tests lassen sich ebenfalls auf dem vorhandenen Gerät ausführen. Ein Xcode-Build, ein Lauf im iOS-Simulator oder eine ausdrücklich verlangte Prüfung auf einem Apple-Gerät setzt dagegen eine geeignete macOS- und Xcode-Umgebung voraus.

Lesen Sie zunächst genau, was der Kurs verlangt. Bedeutet „iOS-Projekt“ nur, dass Sie den Quellcode bearbeiten sollen, oder müssen Sie die App tatsächlich in Xcode bauen und im Simulator ausführen? Ist ein Screenshot, ein Testergebnis oder eine bestimmte Laufumgebung als Nachweis gefordert? Klären Sie dies anhand der Kursbeschreibung, bevor Sie Zeit in eine Umgebung investieren, die für die Abgabe gar nicht benötigt wird.

Die Xcode-Dokumentation beschreibt die Entwicklungsumgebung; die Anleitung zum Ausführen einer App auf simulierten oder physischen Geräten behandelt den entsprechenden Laufweg. Prüfen Sie dort die aktuellen Voraussetzungen und folgen Sie den Anforderungen Ihrer konkreten Aufgabe. Eine allgemeine Codeprüfung kann einen vorgeschriebenen Simulatorlauf nicht ersetzen.

Wenn Sie keinen eigenen Mac haben, müssen Sie deshalb nicht die gesamte Arbeit aufschieben. Vergleichen Sie den Code, prüfen Sie verständliche Aufgabenbereiche und führen Sie die Tests aus, die Ihre vorhandene Umgebung unterstützt. Halten Sie aber offen fest, was noch nicht nachgewiesen ist. Für den Xcode-Teil wählen Sie erst dann eine kompatible Mac-Umgebung, wenn der Kurs ihn wirklich verlangt.

SECTION 07 Häufige Fragen zur Abnahme mit Codex CLI

Wie finde ich heraus, welche Dateien Codex CLI geändert hat?

Prüfen Sie zuerst im Projektordner den Versionskontrollstatus und danach den Diff. Die Dateiliste zeigt, wo Änderungen vorliegen; der zeilenweise Vergleich erklärt, was geändert wurde. Achten Sie zusätzlich auf neue, noch nicht erfasste Dateien, weil sie in einem gewöhnlichen Diff fehlen können. Öffnen Sie jede überraschende Datei und prüfen Sie, ob sie zur Aufgabenstellung gehört.

Muss ich Änderungen selbst testen, wenn Codex CLI eine Lösung erklärt?

Ja. Eine Erklärung beschreibt die beabsichtigte Änderung, weist aber nicht nach, dass sie in Ihrem Projekt funktioniert oder die Kursanforderungen erfüllt. Führen Sie die vorgesehenen Tests nach Projektanleitung aus und prüfen Sie die geforderten Abläufe selbst. Wenn Tests fehlen, dokumentieren Sie, welche Eingaben oder Funktionen Sie manuell geprüft haben und welche Bereiche ungeprüft bleiben.

Wann kann ich ein Kursprojekt nach erfolgreichen Tests abgeben?

Wenn alle Aufgabenanforderungen mit konkreten Ergebnissen abgeglichen sind, die Änderungen nachvollziehbar bleiben und die einzureichenden Dateien stimmen. Ein erfolgreicher Test allein ist kein allgemeiner Freigabestempel: Er deckt nur die geprüften Fälle ab. Prüfen Sie deshalb auch Start, zentrale Programmabläufe und besondere Vorgaben Ihrer Lehrkraft. Halten Sie bei offenen Punkten die Abgabe zurück, bis diese geklärt sind.

Welche iOS-Prüfung braucht einen Mac, wenn ich keinen eigenen besitze?

Ein gewöhnlicher Textvergleich kann auf Ihrem vorhandenen Rechner stattfinden. Wenn die Aufgabe jedoch ausdrücklich einen Xcode-Build, einen iOS-Simulator oder einen Lauf auf einem Apple-Gerät verlangt, benötigen Sie dafür eine kompatible Mac-Umgebung. Fragen Sie bei unklarer Formulierung nach, welcher Nachweis erwartet wird. Ein nicht ausgeführter Simulatorlauf darf nicht als bestandene Prüfung dokumentiert werden.

Wenn Ihr Kurs mit allgemeinen Codeänderungen und Tests auskommt, erledigen Sie die Abnahme am besten auf dem Gerät, das Sie bereits nutzen; zusätzliche Umgebungskosten bringen für diesen Zweck keinen belegbaren Vorteil. Verlangt die Aufgabe dagegen einen Xcode-Build oder Simulatornachweis, sind ein vorhandener Mac, der Zugriff auf einen geeigneten Mac in Schule oder Hochschule oder eine zeitweise Mac-Nutzung die passenden Wege. Ein eigener Rechner ist für eine einmalige Prüfung nicht zwingend nötig, während eine zeitlich begrenzte Remote-Umgebung nicht zu jedem Kurs passt und die verlangten Funktionen vorab geprüft werden müssen. Wenn Sie diesen Mac-Teil benötigen, sehen Sie sich die Mac-Lernumgebung von VPSNIX an und gleichen Sie die Nutzung mit den Kursanforderungen ab; Angaben zu verfügbaren Optionen finden Sie auf der VPSNIX-Seite zu den Mietangeboten.