Wie ein Entwickler mit Codex einen GitLab-Codeprüfungsbot selbst baute

Ein kleines Entwicklerteam stand vor einem einfachen Problem mit teuren Folgen: Jede automatisierte Codeprüfung in GitLab Duo Code Review kostete etwa 20 Cent. Bei fünf Merge-Requests pro Tag summierten sich die Kosten schnell auf einen Euro – ein Betrag, der für ein kleines Team spürbar ins Gewicht fällt. Die naheliegende Lösung, einen bestehenden ChatGPT-Account für die Codeprüfungen zu nutzen, scheiterte an den technischen Einschränkungen von GitLab Duo: Das Tool akzeptiert nur pay-per-token-Anbieter, arbeitet mit veralteten Modellversionen und lässt keine individuellen Anpassungen zu.

Doch statt auf die proprietäre Lösung zu setzen, entschied sich ein Entwickler für einen pragmatischen Ansatz: Er baute einen eigenen Codeprüfungsbot mit OpenAIs Codex-SDK. Das Projekt entwickelte sich schneller als erwartet und war in nur drei Tagen umsetzbar – inklusive Sicherheitskonzept und Feinjustierung. Besonders herausfordernd gestaltete sich die Integration in die bestehende OpenShift-Umgebung, wo strikte Sicherheitsvorgaben zunächst ein Hindernis darstellten.

Warum ein selbstgebauter Lösungsansatz notwendig war

GitLab Duo Code Review basiert auf einem Closed-Source-Modell und einem proprietären Abrechnungssystem. Die Kosten entstehen pro Token, und die Modellversionen hinken hinter den aktuellen OpenAI-Standards her. Zudem erlaubt das Tool keine tiefgreifenden Anpassungen an den Prüfprozessen – etwa die Möglichkeit, auf Follow-up-Kommentare von Entwicklern zu reagieren. Diese Einschränkungen machten es für das Team unattraktiv.

Eine kostengünstigere Alternative wäre gewesen, die Prüfungen über die OpenAI-API direkt abzuwickeln. Doch auch hier stießen die Entwickler auf Grenzen: Die verfügbaren Codebeispiele aus der OpenAI-Community – wie der Ansatz secure_quality_gitlab oder build_code_review_with_codex_sdk – waren zwar technisch sauber umgesetzt, aber nicht auf die spezifischen Anforderungen des Teams zugeschnitten. Beide Lösungen setzen auf einmalige Prüfungen im CI-Pipeline-Kontext und bieten keine Möglichkeit, Gesprächsverläufe fortzusetzen oder auf Rückfragen einzugehen. Zudem fehlt die nahtlose Integration in die bestehende Infrastruktur.

Das Team benötigte stattdessen eine Lösung mit folgenden Eigenschaften:

• Laufzeit als dauerhafter Service, um Gesprächsverläufe zu speichern
• Nutzung des bereits vorhandenen ChatGPT-Accounts ohne zusätzliche Kosten
• Selbsthosting auf dem bestehenden OpenShift-Cluster
• Sofortiger Zugriff auf neue Codex-Modelle bei deren Veröffentlichung

Die Konsequenz: Ein maßgeschneiderter Bot musste her.

Technische Architektur: Vom Webhook zum Codekommentar

Die Architektur des Bots ist bewusst simpel gehalten, um Wartbarkeit und Skalierbarkeit zu gewährleisten. Der Prozess beginnt mit einem Webhook von GitLab, der über eine Fastify-API entgegengenommen wird. Nach einer Validierung des Tokens wird die Anfrage in eine Redis-basierte BullMQ-Warteschlange eingereiht. Ein einzelner Worker-Prozess übernimmt die eigentliche Prüfung und kommuniziert über die GitBeaker-Bibliothek mit GitLab zurück.

GitLab ──webhook──▶ Fastify ──▶ BullMQ (Redis) ──▶ Worker ──▶ codex-sdk
  │                 │                    │            │
  │                 ├── validiert        ├── gitbeaker REST
  │                 ├── X-Gitlab-Token    ├── MariaDB
  │                 └── Klassifizierung   └── git worktree

Die Concurrency ist auf einen einzigen Prozess beschränkt – ein bewusster Schutz gegen mögliche Abuse-Erkennungen von OpenAI. Ein Single-Flight-Mechanismus im Codex-SDK stellt sicher, dass keine doppelten Anfragen an die API gesendet werden. Die Zustandsverwaltung erfolgt über drei separate Speicherorte:

• Redis speichert die BullMQ-Warteschlange. Job-IDs sind deterministisch formatiert, sodass doppelte Webhooks ignoriert werden. Bei einem Ausfall von Redis gehen nur laufende Jobs verloren – diese werden bei einem erneuten Webhook automatisch neu eingereiht.

• MariaDB verwaltet zwei Tabellen: reviews für die Zuordnung von Projekten, Merge-Requests und Commit-Hashes sowie threads für die Verknüpfung von GitLab-Diskussions-IDs mit Codex-Sitzungen. Sensible Daten wie Diffs oder Code-Inhalte werden hier bewusst nicht gespeichert.

• Codex-Sitzungen werden als JSONL-Dateien auf einem persistenten Volume gespeichert. Die Sitzungsdaten sind durch Namespaces und RBAC geschützt. Der Bot speichert lediglich die Thread-ID, während die vollständigen Gesprächsverläufe in den Dateien verbleiben.

Follow-up-Kommentare: Kontext bleibt erhalten

Eine der größten Stärken des selbstgebauten Bots ist die Fähigkeit, auf Follow-up-Kommentare von Entwicklern zu reagieren. Wird in einem Kommentar @mr-codex erwähnt, erkennt der Bot die zugehörige Diskussion und setzt den Codex-Thread fort. Der Worker ruft die gespeicherte Sitzungs-ID ab und führt codex.resumeThread(id).run(prompt) aus. Die Modellantwort berücksichtigt dann den vollständigen Kontext der vorherigen Interaktion.

Kommentare ohne den spezifischen Befehl werden ignoriert. Diese Regel verhindert unnötige Bot-Antworten und vermeidet endlose Schleifen zwischen Entwicklern und Bot. Selbst wenn ein Entwickler @mr-codex in einer neuen Diskussion erwähnt, wird eine neue Sitzung gestartet – die dann jedoch ebenfalls mit der Diskussion verknüpft wird, um spätere Antworten korrekt zuzuordnen.

Sicherheitsherausforderungen: Warum danger-full-access die einzige Option war

Die größte technische Hürde bestand in der Integration von Codex in die bestehende OpenShift-Umgebung. Codex bietet drei Sicherheitsmodi: read-only, workspace-write (beide basierend auf bwrap) und danger-full-access (ohne Sandbox). Die Entwickler strebten zunächst die Nutzung von bwrap an, da es eine sichere Ausführungsumgebung bietet.

Doch hier stieß das Team auf eine unerwartete Einschränkung: bwrap erfordert unprivilegierte Benutzernamensbereiche (unshare(CLONE_NEWUSER)), die standardmäßig von Docker-Seccomp-Profilen blockiert werden. Auf einem regulären Linux-Host ließe sich dieses Problem durch die Deaktivierung des Seccomp-Profils lösen (seccomp=unconfined). In OpenShift ist dies jedoch nicht möglich, da die Cluster-Richtlinie restricted-v2 die Nutzung von seccompProfile: Unconfined explizit verbietet – und ein Wechsel zu einer weniger restriktiven Richtlinie war nicht ohne Weiteres umsetzbar.

Nach mehreren Versuchen mit alternativen Ansätzen, darunter Landlock-basierte Sicherheitsmechanismen, blieb nur eine Lösung übrig: die Nutzung des danger-full-access-Modus. Dieser Modus bietet zwar keine Sandbox, doch in Kombination mit den bestehenden Sicherheitsmechanismen des OpenShift-Clusters – wie Namespaces, RBAC und Netzwerkrichtlinien – konnte ein ausreichendes Maß an Sicherheit gewährleistet werden.

Die Entscheidung für danger-full-access war nicht trivial, unterstreicht aber, wie wichtig es ist, Sicherheitskonzepte an die spezifischen Umgebungen anzupassen. Der Bot läuft nun in einem isolierten Pod innerhalb des OpenShift-Clusters, was zusätzliche Schutzebenen durch die Kubernetes-spezifischen Sicherheitsfeatures bietet.

Fazit: Ein kostengünstiger, anpassbarer und zukunftssicherer Ansatz

Der selbstgebaute Codex-Codeprüfungsbot hat sich als pragmatische und wirtschaftliche Lösung erwiesen. Innerhalb von nur drei Tagen entstand ein Tool, das nicht nur die Kosten für Codeprüfungen drastisch reduzierte, sondern auch mehr Flexibilität und Kontrolle bot als kommerzielle Alternativen. Besonders die Fähigkeit, Gesprächsverläufe fortzusetzen und auf Follow-up-Fragen zu reagieren, macht den Bot zu einer wertvollen Ergänzung für das Entwicklerteam.

Die technische Umsetzung zeigte zudem, wie wichtig es ist, Sicherheitsanforderungen und technische Gegebenheiten in Einklang zu bringen. Die Nutzung von danger-full-access in Kombination mit den OpenShift-spezifischen Sicherheitsmechanismen bewies, dass auch ohne Sandbox ein hohes Maß an Sicherheit erreicht werden kann.

Für Teams, die ähnliche Anforderungen haben, lohnt es sich, den Aufwand für einen maßgeschneiderten Bot in Betracht zu ziehen. Die Investition in Entwicklung und Anpassung zahlt sich oft schneller aus als die laufenden Kosten für proprietäre Lösungen – und bietet gleichzeitig mehr Kontrolle und Transparenz.