Omnigent 0.18.0 bringt Code-Reviews für GitLab und Azure DevOps
Das Session Panel deckt nun drei Code-Plattformen ab, eigene Agenten lassen sich hostübergreifend installieren und eine neue Inbox sortiert ausstehende Unterhaltungen.
Omnigent erweitert mit Version 0.18.0 seine Review-Oberfläche über GitHub hinaus. Seit dem 13. Oktober 2026 kann das Session Panel auch GitLab Merge Requests und Azure-DevOps-Pull-Requests darstellen. Checks, Kommentare und Diffs stehen dabei direkt neben der Agentenunterhaltung, aus der die jeweilige Codeänderung entstanden ist.
Damit adressiert das Update einen sehr konkreten Fall: Ein Unternehmen kann seine Repositories auf mehrere Plattformen verteilen, ohne für die Prüfung agentengenerierter Änderungen drei grundsätzlich verschiedene Ansichten zusammensetzen zu müssen. Die Repositories bleiben bei ihren jeweiligen Hosts; Omnigent führt die für eine Sitzung relevanten Review-Informationen an einer gemeinsamen Stelle zusammen.
GitLab und Azure DevOps erhalten dieselbe Review-Sicht wie GitHub
Vor Version 0.18.0 erfasste der Review-Bereich des Session Panels nur einen Teil gemischter Repository-Landschaften: GitHub Pull Requests waren abgedeckt, Änderungen auf GitLab oder Azure DevOps dagegen nicht in derselben Ansicht verfügbar. Das Release ergänzt nun GitLab Merge Requests und Azure-DevOps-Pull-Requests ausdrücklich mit derselben Behandlung, die GitHub Pull Requests erhalten.
Zu dieser Behandlung gehören drei zentrale Bestandteile: die Ergebnisse von Checks, die Kommentare am Änderungsvorschlag und der eigentliche Diff. Omnigent stellt sie neben die Konversation, die zur Änderung geführt hat. Dadurch liegen nicht nur das Resultat und seine technische Prüfung zusammen, sondern auch der Kontext der Agentensitzung.
Ein Beispiel: Ein Agent bearbeitet eine Aufgabe in einem GitLab-Repository und erzeugt daraus einen Merge Request. Im Session Panel lässt sich anschließend nachvollziehen, welche Unterhaltung zu der Änderung geführt hat, wie der Diff aussieht, welche Checks gelaufen sind und welche Kommentare am Merge Request stehen. Dasselbe Muster gilt nun für einen Pull Request in Azure DevOps sowie weiterhin für GitHub.
Gemischte Repository-Landschaften werden leichter lesbar
Der praktische Gewinn zeigt sich vor allem dort, wo Teams nicht ausschließlich einen Code-Host verwenden. Ein Produktbereich kann auf GitHub liegen, interne Dienste können in GitLab verwaltet werden und ein weiteres Projekt kann Azure DevOps nutzen. Ohne eine gemeinsame Sicht wechselt die prüfende Person zwischen Agentenunterhaltung und den jeweiligen Oberflächen der Hosts, um Ursache, Änderung und Rückmeldung zusammenzubringen.
Omnigent 0.18.0 ersetzt die Code-Plattformen dabei nicht. GitHub Pull Requests, GitLab Merge Requests und Azure-DevOps-Pull-Requests bleiben die jeweiligen Änderungseinheiten. Neu ist die verbindende Perspektive im Session Panel: Die Review-Daten werden dort an die Unterhaltung angelegt, die den Code hervorgebracht hat.
Das ist besonders nützlich, wenn eine Änderung erklärungsbedürftig ist. Ein Diff zeigt, was verändert wurde. Die benachbarte Sitzung liefert den Entstehungskontext. Checks zeigen, ob automatisierte Prüfungen erfolgreich waren, und Kommentare machen Rückfragen oder Korrekturwünsche sichtbar. Die Kombination verringert die Distanz zwischen der Anweisung an einen Agenten und dem daraus entstandenen Änderungsvorschlag.
Ein Review beginnt bei der Sitzung, nicht erst beim Diff
Mit der neuen Plattformabdeckung lässt sich die Prüfung an der Stelle beginnen, an der die Änderung entstanden ist. Wer eine Sitzung öffnet, sieht neben der Unterhaltung die Informationen des zugehörigen Pull beziehungsweise Merge Requests. Das bietet sich für Änderungen an, bei denen der Auftrag ebenso wichtig ist wie der Code selbst.
Angenommen, ein eigener Agent soll eine Konfigurationsdatei vereinheitlichen. Der Auftrag kann Einschränkungen enthalten, etwa nur eine bestimmte Gruppe von Dateien zu verändern. Im Review lässt sich die Unterhaltung mit dem Diff abgleichen: Entspricht die tatsächliche Änderung dem erteilten Auftrag? Die Checks ergänzen die technische Rückmeldung, während Kommentare zeigen, welche Punkte bereits diskutiert werden.
Bei einer Azure-DevOps-Änderung funktioniert die Betrachtung nun nach demselben Grundprinzip wie bei GitHub. Bei GitLab gilt das entsprechend für Merge Requests. Menschen, die mehrere Repository-Plattformen betreuen, müssen ihre Prüflogik dadurch weniger stark an den Host anpassen: Auftrag, Änderung, Checks und Diskussion erscheinen in einer wiederkehrenden Anordnung.
Diese gemeinsame Darstellung darf nicht mit einer Zusammenlegung der Plattformfunktionen verwechselt werden. Das Release beschreibt eine Review-Ansicht innerhalb des Session Panels. Ihr Wert liegt gerade darin, die vorhandenen Pull- und Merge-Request-Daten neben der Agentensitzung lesbar zu machen.
Eigene Agenten folgen mit omnigent agent add über Hosts hinweg
Die zweite größere Neuerung betrifft nicht den Review selbst, sondern die Wiederverwendung eigener Agenten. Der neue CLI-Befehl omnigent agent add installiert benutzerdefinierte Agenten so, dass sie über verschiedene Hosts hinweg verfügbar sind. Eine einmal definierte Agentenkonfiguration muss damit nicht für jeden Einsatzort separat neu angelegt werden.
Das lässt sich mit einem spezialisierten Review-Agenten nutzen. Eine Organisation kann beispielsweise einen eigenen Agenten für die Prüfung bestimmter Konventionen bereitstellen und ihn anschließend in Umgebungen einsetzen, die mit unterschiedlichen Code-Hosts verbunden sind. Entscheidend ist nicht, dass GitHub, GitLab und Azure DevOps identisch wären, sondern dass die wiederverwendbare Agentendefinition nicht an einen einzigen Host gebunden bleibt.
Der Befehl stärkt damit die Verbindung zwischen den beiden Hauptthemen des Releases: Einerseits erweitert Omnigent die Sicht auf Codeänderungen über mehrere Plattformen. Andererseits können eigene Agenten denselben Plattformwechsel mitvollziehen. Für Betriebe mit verteilten Repositories entsteht so eine konsistentere Basis, ohne alle Projekte zu einem Anbieter verschieben zu müssen.
Omnigent bezeichnet sich im eigenen Repository als quelloffenes Agenten-Framework und Meta-Harness. Es kann Claude Code, Codex, Cursor, Pi und eigene Agenten orchestrieren. Der neue Installationsbefehl ordnet sich in dieses Konzept ein: Agenten sollen nicht nur wiederverwendbar sein, sondern unabhängig vom gewählten Host bereitstehen.
Settings zeigt, was ein Harness beim Start lädt
Version 0.18.0 ergänzt außerdem die Ansicht Settings → Harnesses. Dort zeigt Omnigent, welche Bestandteile ein Harness beim Start lädt. Das ist für eigene und wechselnde Agentenkonfigurationen eine sinnvolle Ergänzung, weil die aktive Startkonfiguration sichtbar wird.
Ein Harness bildet in Omnigent die Umgebung, in der ein Agent ausgeführt wird. Das Projekt beschreibt die Möglichkeit, unter anderem zwischen Claude Code, Codex, Cursor und Pi zu wechseln, ohne die Orchestrierung vollständig neu zu schreiben. Wenn mehrere Harnesses und eigene Agenten zusammenkommen, ist die Startbelegung eine wichtige Information: Sie zeigt, welche Grundlage eine konkrete Sitzung tatsächlich erhält.
Die neue Ansicht hilft somit bei einer präzisen Zuordnung. Wird ein Agent hostübergreifend installiert, lässt sich in den Einstellungen erkennen, was das ausgewählte Harness beim Start einbindet. Das macht Unterschiede zwischen Ausführungsumgebungen sichtbarer und ergänzt die gemeinsame Review-Sicht um den technischen Kontext vor Beginn einer Sitzung.
Die Inbox trennt ungelesene Sitzungen von erwarteten Antworten
Neben Code-Reviews und Agenteninstallation überarbeitet das Release die Inbox. Sie besitzt nun die drei Ansichten All, Unread und Awaiting response. All zeigt den gesamten Bestand, Unread konzentriert sich auf noch nicht gelesene Inhalte und Awaiting response sammelt Sitzungen, in denen eine Antwort aussteht.
Diese Trennung ist vor allem bei parallel laufenden Agentensitzungen relevant. Eine ungelesene Nachricht ist nicht automatisch dasselbe wie eine Unterhaltung, die eine Entscheidung oder Rückmeldung verlangt. Die neue Navigation bildet diesen Unterschied direkt ab. So lässt sich zunächst auf jene Sitzungen fokussieren, die noch eine Reaktion benötigen, und anschließend der übrige ungelesene Bestand bearbeiten.
In Verbindung mit den erweiterten Reviews entsteht ein nachvollziehbares Nutzungsmuster: Die Inbox weist auf eine wartende Sitzung hin; im Session Panel stehen Unterhaltung, Diff, Checks und Kommentare beieinander. Die Inbox priorisiert damit die Kommunikation, während das Panel den technischen Gegenstand der Sitzung zeigt. Beide Neuerungen greifen ineinander, ohne dieselbe Aufgabe zu übernehmen.
Drei konkrete Anwendungen des Updates
Die erste Anwendung ist ein plattformübergreifender Review-Bereich für eine gemischte Codebasis. Eine verantwortliche Person kann Sitzungen zu einem GitHub Pull Request, einem GitLab Merge Request und einem Azure-DevOps-Pull-Request nach demselben Muster öffnen. Das reduziert nicht die Zahl der Plattformen, vereinheitlicht aber die Sicht auf agentengenerierte Änderungen.
Die zweite Anwendung ist die Verteilung eines spezialisierten eigenen Agenten. Mit omnigent agent add kann eine bestehende Agentendefinition hostübergreifend installiert werden. Ein Agent für Dokumentationsänderungen, Abhängigkeitsaktualisierungen oder interne Codekonventionen lässt sich dadurch in mehreren verbundenen Umgebungen einsetzen, statt pro Host als getrennte Variante gepflegt zu werden.
Die dritte Anwendung verbindet Inbox und Review. Awaiting response dient als Auswahl jener Sitzungen, in denen eine Reaktion erforderlich ist. Nach dem Öffnen zeigt das Session Panel den dazugehörigen Änderungsvorschlag mit Diff, Checks und Kommentaren. Das ist kein automatisches Freigabesystem, sondern eine fokussierte Oberfläche für die menschliche Prüfung und Antwort.
Warum Version 0.18.0 mehr als zwei zusätzliche Integrationen liefert
Die auffälligste Neuerung sind GitLab und Azure DevOps. Die eigentliche Produktidee des Releases reicht jedoch weiter: Omnigent positioniert sich als gemeinsame Basis für Agentenarbeit, auch wenn Code-Hosts und ausführende Harnesses wechseln. Die zusätzlichen Review-Integrationen, der neue Agentenbefehl, die sichtbare Harness-Startkonfiguration und die sortierte Inbox bearbeiten unterschiedliche Teile dieser Idee.
Für Unternehmen mit nur einer Plattform bleibt vor allem die neue Inbox interessant. Bei mehreren Hosts wächst der Nutzen deutlicher: Der Kontext einer Agentensitzung lässt sich mit den Review-Daten von drei verbreiteten Code-Plattformen verbinden, und eigene Agenten können über diese Umgebungen hinweg wiederverwendet werden.
Die Veröffentlichung nennt keine neue Modellgeneration und keine isolierte KI-Funktion. Omnigent 0.18.0 verbessert vielmehr die Fläche, auf der verschiedene Agenten, Harnesses und Code-Plattformen zusammenkommen. Genau darin liegt der praktische Sprung: GitHub ist nicht länger die einzige vollständig eingebundene Review-Quelle des Session Panels.
Die Details zu Version 0.18.0 stehen in den offiziellen Release Notes. Das Omnigent-Repository beschreibt das quelloffene Framework, die unterstützten Harnesses sowie den übergeordneten Ansatz zur Orchestrierung von Agenten.