Vom Code-Fix bis zum Merge – mit Codex und GitLab

Codex macht als Coding-Agent im Terminal viel Spaß. Auf ein Repository gerichtet, bekommt es eine fokussierte Aufgabe und legt sofort los: Code lesen, einen Fix vorschlagen, Befehle ausführen – vom Problem zur Implementierung, ohne den Flow zu verlassen. Das ist ein wesentlicher Teil des Reizes agentischer Coding-Werkzeuge, und genau das hat auch unser Claude-Code-Tutorial so gut funktionieren lassen.

Code schreiben ist aber nur der erste Schritt. Issue, Merge Request, CI/CD-Pipeline, Review und die finale menschliche Entscheidung zum Ausliefern kommen danach. Code schreiben und Software ausliefern sind nicht dasselbe – und diese Lücke wird deutlicher, je schneller Coding-Agenten werden.

Genau hier kommt GitLab ins Spiel. Dieses Tutorial zeigt drei Anwendungsfälle mit Codex und GitLab Duo Agent Platform:

1. Rust-WebSocket-Bug lokal beheben, um mit Codex zu starten
2. Kontext mit GitLab MCP anreichern, um den Rust-Bug gemäß Issue-Anforderungen zu lösen
3. Codex in GitLab Duo Agent Platform als externen Agenten nutzen, um Review-Feedback im Merge Request zu adressieren

Was dieses Tutorial zeigt

Die drei Anwendungsfälle bauen aufeinander auf – und verdeutlichen dabei einen größeren Zusammenhang.

Codex ist ausgezeichnet darin, schnell von einer Problemstellung zu Code zu gelangen. GitLab fügt den Software-Delivery-Kontext hinzu, der aus diesem Code eine Änderung macht, die verstanden, geprüft, reviewed und mit Zuversicht ausgeliefert werden kann.

Im ersten Anwendungsfall bleibt der Fokus nah am Code – Codex arbeitet mit dem Repository und lokalen Agenten-Anweisungen. Im zweiten bringt GitLab MCP das Issue, die Anforderungen und den Merge-Request-Workflow direkt in die Terminal-Session. Im dritten wechselt Codex in den Merge Request selbst und hilft dabei, die Lücke zwischen Review-Feedback und der nächsten Revision zu schließen.

Genau diese Abfolge macht die Kombination überzeugend: nicht die Wahl zwischen einem Coding-Werkzeug und einer DevSecOps-Plattform – sondern agentisches Coding-Tempo auf den gesamten Software-Lifecycle ausgedehnt.

Voraussetzungen

1. Codex im Terminal, konfiguriert und gestartet.
2. Ein GitLab-Projekt mit Bug-Reports und Feature-Proposal-Issues, zum Beispiel das Tanuki-IoT-Platform-Projekt.
3. Für bestimmte Anwendungsfälle: GitLab-MCP-Server und GitLab Duo Agent Platform mit externen Agenten.
4. Zum Bauen von Code: Cargo und Rust-Compiler, zum Beispiel rustup.

GitLab-Projekt vorbereiten

Um den Workflow in der eigenen Umgebung nachzuvollziehen: Projekt importieren, klonen und Codex im Repository-Root öffnen:

1. Das Tanuki-IoT-Platform-Projekt in die eigene GitLab-Umgebung importieren, einschließlich aller offenen Issues.
2. Das Projekt in die lokale Umgebung klonen und in das Verzeichnis navigieren.
3. Ein Terminal öffnen und Codex mit codex starten.

      git clone https://gitlab.example.com/examplegroup/tanuki-iot-platform.git
cd tanuki-iot-platform

codex

    

Im Prompt nach dem Zweck des Projekts fragen:

      What is this project about?

    

Der relevante Teil für dieses Tutorial ist der Rust-Metrics-Store im backend/-Verzeichnis. Sensoren senden Messwerte über eine REST-API, und Dashboards konsumieren Live-Daten über WebSocket-Streams. Problem und Fix sind damit gut nachvollziehbar.

Einstieg mit Codex und GitLab: Rust-Backend-Bug beheben

In diesem Szenario liegt ein Bug im Live-WebSocket-Stream vor. Das Backend unterstützt bereits Metric-Filtering auf der REST-API-Seite, aber der WebSocket-Stream filtert nicht korrekt nach Metric. Als Test: Bei einem Abonnement für einen Sensor und eine Metric kommen trotzdem andere Metrics zurück. Ein schneller Test im Terminal bestätigt das Problem.

Backend in einem Terminal starten, Port 9090:

      PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml

    

WebSocket-Client in einem zweiten Terminal öffnen. Auf macOS ist websocat über Homebrew verfügbar: brew install websocat.

      websocat 'ws://localhost:9090/ws?sensor=arduino-iot-collector&metric=temperature_celsius'

    

Zwei verschiedene Metrics für den arduino-iot-collector-Sensor senden:

      curl -s -X POST http://localhost:9090/api/metrics \
  -H 'Content-Type: application/json' \
  -d '{"sensor":"arduino-iot-collector","metric":"temperature_celsius","value":23.5}'

curl -s -X POST http://localhost:9090/api/metrics \
  -H 'Content-Type: application/json' \
  -d '{"sensor":"arduino-iot-collector","metric":"humidity_percent","value":61.2}'

    

Erwartet wird nur temperature_celsius – aber der Stream zeigt auch humidity_percent, was den Bug bestätigt.

Terminal mit drei Sessions: Metrics-Backend starten, WebSocket-Stream mit `websocat` lesen und Test-Metrics mit curl senden.

Das Problem wird nun in einem neuen Prompt an Codex übergeben:

      I need help with a backend change to add metric filtering to /ws so live streams can be narrowed to one metric.

    

Dank der AGENTS.md-Datei im GitLab-Projekt weiß Codex, wie das Rust-Backend strukturiert ist, welche Befehle ausgeführt werden sollen und wie die Code-Qualitätsanforderungen aussehen.

`AGENTS.md` mit Rust-Toolchain-Setup und Build-Befehlen für Agenten.

Codex analysiert den Rust-Quellcode und findet das fehlende Element: Der /ws-Endpunkt versteht bereits einen sensor-Query-Parameter, braucht aber auch einen optionalen metric-Parameter. Codex aktualisiert die Handler-Logik, fügt Tests hinzu und hält die Dokumentation mit der Code-Änderung synchron.

Nach den Code-Änderungen führt Codex Formatierung, Tests und Build aus und macht einen abschließenden Check vor dem Git-Commit. Von dort aus kann ein Branch, Commit und Push angefordert werden.

Codex beim Beheben des Bugs mit dem Diff-Edit.

Sobald der Merge Request existiert, übernimmt GitLab die nächsten Phasen des Software-Lifecycles. CI/CD-Pipelines starten, Security Scanning läuft, und GitLab Duo Code Review überprüft die Änderungen gegen die Rust-Code-Style-Anforderungen.

GitLab Duo Code Review-Anweisungen für Rust.

Nach dem Deployment wird der lokale Test erneut ausgeführt und bestätigt, dass der WebSocket-Stream jetzt nur noch die angeforderte Metric ausgibt, wenn Sensor und Metric angegeben werden. Das Ergebnis wird in den Merge Request gepostet.

MR-Kommentare mit GitLab Duo Code Review-Feedback und Entwickler, der lokale Testergebnisse teilt.

Dieser erste Anwendungsfall ist die Ausgangsbasis: Codex ist nah am Code, GitLab übernimmt die Arbeit, sobald der Patch in den Merge-Request-Lifecycle eintritt.

Eine Aufzeichnung von Codex, GitLab CI/CD und GitLab Duo Agent Platform in Aktion:

WebSocket-Metric-Filter mit GitLab MCP und Development-Lifecycle-Kontext beheben

Im ersten Anwendungsfall konnte Codex das lokale Code-Repository sehen, hatte aber keinen Zugriff auf das GitLab-Issue, die vereinbarten Anforderungen, die Implementierungsnotizen oder den Merge-Request- und Pipeline-Status. Dieser Kontext lebt in GitLab, nicht in den lokalen Dateien.

Hier kommt der GitLab-MCP-Server ins Spiel.

In diesem Anwendungsfall existiert das Issue bereits und ist bewusst detailliert: Es beschreibt das Problem, enthält funktionale und nicht-funktionale Anforderungen und nennt explizit Tests sowie Updates für README.md und AGENTS.md. Codex muss diese Informationen nicht in den Prompt eingefügt bekommen – es kann das Issue direkt abrufen und von derselben Informationsquelle ausgehen wie ein Entwickler.

GitLab-Issue mit Proposal, funktionalen Anforderungen, Verhalten, nicht-funktionalen Anforderungen und Implementierungsnotizen.

GitLab MCP Server konfigurieren

Den GitLab-MCP-Server zu Codex hinzufügen. Sicherstellen, dass er auf der Instanz oder Top-Level-Group aktiviert ist.

Ein neues Terminal öffnen und den GitLab-MCP-Server mit dem http-Transport-Typ zu Codex hinzufügen.

gitlab.example.com durch die eigene GitLab-Instanz ersetzen:

      codex mcp add --url "https://<gitlab.example.com>/api/v4/mcp" GitLab

    

Der Codex-MCP-Client benötigt möglicherweise ein Feature-Flag für den Rust rmcp_client. ~/.codex/config.toml öffnen und den [features]-Abschnitt hinzufügen. Dort lässt sich auch der hinzugefügte GitLab-MCP-Server im Abschnitt mcp_servers. überprüfen.

      vim ~/.codex/config.toml

    

      [features]
"rmcp_client" = true

[mcp_servers.GitLab]
url = "https://<gitlab.example.com>/api/v4/mcp"

    

codex in einer neuen Terminal-Session starten und /mcp eingeben, um sich mit dem GitLab-MCP-Server zu authentifizieren, falls das nicht automatisch beim Hinzufügen passiert ist.

      codex

/mcp

    

Zur Überprüfung der Verbindung Codex fragen:

      Which GitLab MCP tools are available to you?

Show the GitLab MCP Server version.

    

Codex zur Implementierung des WebSocket-Filter-Issues auffordern

Codex öffnen und im Prompt um Hilfe mit dem Issue bitten:

      Can you help me implement issue 32?

    

Hier ändert sich der Workflow. Codex verwendet das MCP-Werkzeug get_issue und lädt die Issue-Details in die Session, bevor es den Code ändert. Es sieht jetzt die Anforderungen, Labels, Notizen und den größeren Arbeitsumfang, bevor es die Implementierung angeht.

Codex ruft das GitLab-MCP-Server-Werkzeug `get_issue` auf und zeigt die Issue-Details im Terminal.

Der Fix selbst ist vertraut: optionalen metric-Parameter hinzufügen, Matching-Logik aktualisieren, Tests ergänzen und Dokumentation aktualisieren. Der Unterschied liegt in der Informationsquelle: Im ersten Anwendungsfall waren das Repository und der Prompt die Quelle. Hier sind es Issue und Repository gemeinsam.

Nach lokaler Validierung erstellt Codex einen Branch, committed die Arbeit und erstellt den Merge Request über MCP-Werkzeugaufrufe – ohne Browser-Wechsel.

Codex erstellt einen MR über das GitLab-MCP-Server-Werkzeug `create_merge_request`.

Da Codex den Issue-Kontext kennt, fügt es closes 32 in die Merge-Request-Beschreibung ein, sodass das Issue beim Merge automatisch geschlossen wird.

Codex hat `Closes #32` in die Beschreibung eingefügt und zeigt damit an, dass es beim Merge geschlossen wird.

Das ist bedeutsamer als es klingt: Der Agent schreibt nicht nur Code, er beteiligt sich an der Software-Delivery mit Issue-, Merge-Request- und Pipeline-Kontext in der Schleife. Das ist der Mehrwert, den GitLab MCP dem End-to-End-Entwicklungsworkflow hinzufügt.

Sobald GitLab Duo Code Review und Tests grünes Licht geben, ist der finale Review und Merge bereit.

Merge-Request-Kommentare mit GitLab Duo Code Review und Screenshot lokaler Tests.

Eine Aufzeichnung zeigt, wie Codex das Problem mit dem GitLab-MCP-Server löst:

Review-Feedback und Anforderungen mit Codex als externem Agenten verifizieren

Der dritte Anwendungsfall ist besonders interessant. Statt zu fragen, ob Codex einen Merge Request öffnen kann, stellt sich die praktischere Frage: Kann es nach der MR-Erstellung helfen und Review-Feedback direkt im Merge Request bearbeiten?

Für diesen Anwendungsfall wird ein anderer REST-API-Validierungs-Bug verwendet. Das simulierte Problem: POST /api/metrics akzeptiert ungültige Eingaben und gibt trotzdem 201 Created zurück, statt 400 Bad Request für ungültige Payload-Werte wie leere Metrics.

Test in zwei Terminals: In Terminal 1 den Metrics-Store-Server auf Port 9090 starten:

      PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml

    

In Terminal 2 mit curl eine REST-API-Anfrage mit einem leeren Metric-Wert senden:

      curl -w "\nHTTP %{http_code}\n" -X POST http://localhost:9090/api/metrics \
  -H "Content-Type: application/json" \
  -d '{"sensor": "sensor-a", "metric": "  ", "value": 23.5, "labels": {}}'

    

Codex hat bereits einen ersten Draft-Merge-Request mit dem Haupt-Fix erstellt. Ein schneller lokaler Retest zeigt: Das Kernverhalten hat sich verbessert, ungültige Eingaben geben jetzt 400 zurück.

Zwei curl-Aufrufe – einer mit dem Bug-Verhalten, der andere mit dem laufenden Fix.

Gut, aber noch nicht fertig. GitLab Duo Code Review weist auf zwei fehlende Punkte hin, basierend auf den Rust-Code-Style-Anforderungen:

1. Öffentliche Elemente brauchen Dokumentationskommentare.
2. API-Änderungen brauchen Handler-Tests für Erfolgs- und Fehlerpfade, ein Validierungstest fehlt noch.

GitLab Duo Code Review-Feedback zu den Rust-Code-Änderungen.

Jetzt wechseln wir vom lokalen Terminal in die GitLab-UI, wo der Codex-Agent aus dem GitLab AI Catalog im Menü AI > Agents aktiviert werden kann. Das Service-Account-Handle beginnt mit @ai-codex-agent – den Agenten direkt in der Merge-Request-Diskussion erwähnen, damit er das Review-Feedback adressieren kann.

Codex Agent by GitLab im Projekt aktiviert.

Der Merge Request wird damit zur Arbeitsfläche für den Codex-Agenten: mit Code-Diff, Review-Kommentaren, CI/CD-Pipelines, Security-Scanner-Ergebnissen und Freigabe-Regeln. Codex kann die Folgearbeit genau dort erledigen, wo die Zusammenarbeit bereits stattfindet.

Einen neuen Kommentar mit Anweisungen hinzufügen, die Fixes direkt in den Merge Request zu pushen:

      Please help address the review feedback, and push a fix.

    

Codex-Agenten in einem Merge-Request-Feedback-Kommentar erwähnen.

Codex adressiert das Feedback, fügt den fehlenden Validierungstest hinzu, committed ihn, führt Checks in seinem eigenen Ausführungskontext in der Agent Session erneut aus und postet einen Zusammenfassungskommentar zurück in den Merge Request.

Die CI/CD-Pipelines werden automatisch durch den neuen Git-Commit ausgelöst.

Codex Agent by GitLab hat eine neue CI/CD-Pipeline ausgelöst.

Die neu hinzugefügte ingest_rejects_blank_metric-Testfunktion lässt sich im Job-Log überprüfen.

CI/CD-Job-Log-Suche nach `ingest_rejects_blank_metric`.

Das ist der Teil, der das External-Agent-Modell in der Praxis nützlich macht. Externe Agenten sind nicht interessant, weil sie Reviews ersetzen. Sie sind nützlich, weil sie die Lücke zwischen Review-Feedback und der nächsten Revision schließen helfen – während Merge Request, Freigaben und die finale menschliche Entscheidung genau dort bleiben, wo sie hingehören. Und sie lassen sich über Event-Trigger und Custom Flows weiter in GitLab Duo Agent Platform integrieren.

Eine Aufzeichnung zeigt, wie Codex als externer Agent in GitLab Duo Agent Platform bei Reviews helfen kann:

Tipps für Codex und GitLab

Benutzerdefinierte Anweisungen mit AGENTS.md

Agenten lassen sich anweisen, Code vor Commits zu bauen und zu testen, Änderungen minimal zu halten oder die Projektarchitektur besser zu verstehen – über einen Eintrag in AGENTS.md. Die Tanuki-IoT-Platform verwendet eine Datei auf Root-Ebene sowie spezifische Dateien und Anweisungen für Sensoren und das Backend.

      tree -P AGENTS.md --prune
.
├── AGENTS.md
├── backend
│   └── rust-metrics-store
│       └── AGENTS.md
└── sensors
    ├── arduino-iot-collector
    │   └── AGENTS.md
    ├── c-file-monitor
    │   └── AGENTS.md
    ├── cobol-mainframe-bridge
    │   └── AGENTS.md
    └── java-http-metrics-collector
        └── AGENTS.md

    

Für das Rust-Backend wird eine verzeichnisspezifische AGENTS.md in backend/rust-metric-store/AGENTS.md gepflegt. Sie definiert Code-Style und -Standards für Rust, Dokumentation, Dateiorganisation, Fehlerbehandlung, asynchrone Programmierung, Containerisierung und CI/CD sowie die Build- und Run-Befehle mit dem verfügbaren Toolchain (Cargo). Die verlinkte Datei im GitLab-Projekt enthält alle Details.

Diese benutzerdefinierten Anweisungen werden auch von Agents und Flows auf GitLab Duo Agent Platform verarbeitet.

Für bessere Ausgaben von Coding-Agenten: dort anfangen. Aufschreiben, wie das Repository funktioniert, welche Befehle wichtig sind, was nicht angefasst werden soll und wie eine gute Änderung aussieht. Diese eine Investition zahlt sich für lokale Coding-Werkzeuge, GitLab MCP und externe Agenten gleichermaßen aus.

Jetzt loslegen

GitLab Duo Agent Platform noch nicht im Einsatz? Mit einer kostenlosen Testversion starten.

Wer GitLab bereits im Free Tier nutzt, kann GitLab Duo Agent Platform in wenigen einfachen Schritten einrichten.

Für bestehende GitLab Premium- oder Ultimate-Abonnenten genügt es, Duo Agent Platform zu aktivieren und die enthaltenen GitLab Credits zu nutzen.