Wie verbinden Sie die Atlassian Teamwork Graph CLI mit Codex? Tutorial 2026

Für Codex-CLI-Entwickler: Sie möchten Jira-, Confluence- oder andere Atlassian-Arbeitskontexte in Codex-Aufgaben einbeziehen.
Für Plattformteams und Administratoren: Sie müssen Identität, Berechtigungsgrenzen und mögliche Zugriffsänderungen nachvollziehen.
Für AI-Coding-Teams: Sie wollen die Kontextübergabe prüfen, ohne CLI-Zugriff mit erfolgreicher Codeänderung oder einem fertigen Build gleichzusetzen.

Zuletzt aktualisiert am 08.10.2026; geprüft anhand der OpenAI-Ankündigung, der Atlassian-Installationsdokumentation, des öffentlichen Plugin-Repositorys sowie der aktuellen Dokumentation zu Authentifizierung und Berechtigungen.

1Vor der Einrichtung: Ankündigung und verfügbare Funktion trennen

Die Partnerschaftsmeldung beschreibt unter anderem die Einbindung der GPT-6-Modellreihe in Atlassian-Plattformen, Projektkontext für Codex-Nutzer über zugehörige Plugins und die Erkundung einer tieferen Jira-Integration. Diese Aussagen haben nicht denselben Status. Eine angekündigte Zusammenarbeit sagt für sich genommen weder, dass Ihre Organisation eine bestimmte Funktion freigeschaltet hat, noch dass sich die Rechte der Teamwork Graph CLI geändert haben.

Für Ihre Einsatzplanung ist diese Unterscheidung wichtig:

• Bestätigte Ankündigung: Sie beschreibt die von den Unternehmen kommunizierten Kooperationsthemen. Prüfen Sie für jedes konkrete Produktmerkmal, ob es zusätzlich in der aktuellen Produkt- oder Einrichtungsdokumentation beschrieben ist.
• Erkundete Integration: Eine als Erkundung bezeichnete Jira-Integration ist keine Zusage, dass diese Funktion bereits allgemein verfügbar ist. Planen Sie deshalb keinen produktiven Ablauf um eine noch nicht freigegebene Fähigkeit.
• CLI-Zugriff: Die Teamwork Graph CLI ist ein eigener Zugangsweg. Ihr Status, ihre Installation, die Authentifizierung und die Berechtigungen sind anhand der entsprechenden Atlassian-Dokumentation zu beurteilen, nicht aus einer allgemeinen Kooperationsmeldung abzuleiten.
• Codex skill oder Plugin: Eine Agent-Anweisung kann einem AI Coding Agent beschreiben, wie er ein Werkzeug einsetzen soll. Sie ist weder das CLI-Programm selbst noch ein Ersatz für Anmeldung oder Atlassian-Berechtigungen.

Diese Grenze verhindert einen verbreiteten Planungsfehler: Ein Agent kann im Gespräch überzeugend über ein Projekt sprechen, obwohl die nötige Integration in Ihrer Umgebung gar nicht eingerichtet ist. Umgekehrt bedeutet eine erfolgreiche Installation nicht, dass der Agent automatisch sämtliche Projektinhalte erreicht. Behandeln Sie die Ankündigung als Anlass, die verfügbaren offiziellen Einrichtungswege zu prüfen, nicht als Abnahmebericht Ihrer Organisation.

Für die Einführung heißt das: Halten Sie bestätigte Funktionen und mögliche spätere Erweiterungen in Ihrer Planung getrennt. Dokumentieren Sie, welche Fähigkeit Sie heute tatsächlich getestet haben und welche lediglich in der Ankündigung als gemeinsames Vorhaben oder Erkundung auftaucht. So vermeiden Sie, dass eine Roadmap-Annahme in interne Betriebsanleitungen oder Sicherheitsfreigaben rutscht.

2Vor dem ersten Aufruf: Konto, Umgebung und Testziel festlegen

Klären Sie zuerst, welcher Codex-Ablauf in Ihrem Team tatsächlich verwendet wird. Ein Terminal-Workflow, eine lokale Entwicklungsumgebung und ein automatisierter Agentenlauf können unterschiedliche Konten, Umgebungsvariablen und Freigabeprozesse verwenden. Notieren Sie, in welcher Umgebung Sie die Installation vornehmen und unter welcher Identität die spätere Abfrage laufen soll. Gehen Sie nicht davon aus, dass ein persönliches Konto, ein Organisationskonto und ein Ausführungskonto dieselben Inhalte sehen.

Lesen Sie anschließend die aktuelle Atlassian-Anleitung zum Einstieg mit der Teamwork Graph CLI. Folgen Sie den dort dokumentierten Voraussetzungen und Befehlen. Ältere Blogbeiträge oder kopierte Shell-Beispiele können einen früheren Installationsstand beschreiben. Da die genaue Befehlsfolge und die verfügbaren Optionen von der aktuellen Dokumentation abhängen, sollten Sie keine ungeprüften Befehle aus einem älteren Tutorial in eine Teamumgebung übernehmen.

Legen Sie vor der Installation ein eng begrenztes Testziel fest. Ein geeignetes Ziel ist eine lesende Abfrage zu einem bekannten Vorgang oder Dokument, das Sie mit demselben Konto bereits in Atlassian öffnen können. Schreiben Sie auf, welche Quelle Codex finden soll, welche Information aus dieser Quelle erwartet wird und welche Inhalte ausdrücklich außerhalb des Tests liegen. So können Sie später unterscheiden, ob ein fehlender Treffer an einer falschen Anfrage, einer nicht eingerichteten Funktion oder einer Berechtigungsgrenze liegt.

Prüfen Sie vorab auch, wer Anmeldeinformationen verwaltet, wo sie gespeichert werden dürfen und wie Ihr Team den Zugriff wieder entzieht. Das betrifft nicht nur die lokale Installation: Auch ein späterer unbeaufsichtigter Agentenlauf muss mit einer nachvollziehbaren Identität und einer genehmigten Umgebung ausgeführt werden. Wenn Ihr Unternehmen zentrale Richtlinien für Zugangsdaten oder verwaltete Geräte hat, muss der Test zu diesen Richtlinien passen. Vermeiden Sie es, Geheimnisse in Prompts, Projektdateien oder gemeinsam zugänglichen Protokollen abzulegen.

Wichtig: Eine CLI-Verbindung ist kein Berechtigungs-Upgrade. Der Teamwork Graph kann nur im Rahmen der dafür geltenden Identität und Zugriffsregeln ausgewertet werden. Bestätigen Sie jede unerwartete Sichtbarkeit anhand der Atlassian-Quelle und der Administratorvorgaben, statt sie als normale Folge des Agentenbetriebs hinzunehmen.

Ein zweiter Vorabpunkt ist die Abgrenzung zwischen Arbeitskontext und Ausführungsumgebung. Die CLI kann Projektinformationen für Codex verfügbar machen, aber sie legt nicht fest, wo der Agent den Code ausführt. Prüfen Sie daher bereits bei der Aufgabenwahl, ob der Repository-Test auf Ihrer vorhandenen Entwicklungsumgebung laufen kann oder ob bestimmte Werkzeuge eine separate Umgebung erfordern. Diese Trennung verhindert, dass ein erfolgreicher Zugriff auf Atlassian fälschlich als Freigabe für den gesamten Entwicklungsablauf interpretiert wird.

3Einrichtung: CLI und Codex skills getrennt konfigurieren

Die Installation besteht aus mehreren Ebenen, die Sie einzeln kontrollieren sollten. Erstens benötigen Sie das CLI-Programm gemäß den aktuellen Atlassian-Anweisungen. Zweitens müssen Sie die für Codex vorgesehenen Agent skills oder das zugehörige Plugin aus dem öffentlichen Repository auswählen und nach dessen aktueller Anleitung einrichten. Drittens müssen Sie sich mit dem vorgesehenen Atlassian-Konto authentifizieren. Diese Ebenen hängen zusammen, sind aber nicht austauschbar.

Das öffentliche Repository der Teamwork-Graph-Plugins ist die Anlaufstelle, um verfügbare Agent-Integrationen und deren jeweilige Einrichtung zu kontrollieren. Atlassian erläutert in der Dokumentation zu Agent skills, welche Rolle solche Fähigkeiten bei der Anbindung von Agenten spielen. Prüfen Sie dort, ob eine Anleitung tatsächlich für Ihren Codex-Ablauf gedacht ist, statt einen ähnlich benannten Eintrag für einen anderen Agenten zu übernehmen.

Ein kontrollierter Ablauf sieht folgendermaßen aus:

1. Codex-Umgebung bestimmen. Legen Sie fest, in welcher Entwicklungsumgebung Codex CLI läuft und ob dort die Installation von Werkzeugen erlaubt ist. Installieren Sie nicht ungeprüft in einer gemeinsam genutzten oder produktiven Umgebung.
2. CLI-Anleitung abrufen. Öffnen Sie die aktuelle Atlassian-Einstiegsdokumentation und verwenden Sie die dort aufgeführten Installationsschritte. Kontrollieren Sie vor der Ausführung, ob Sie im richtigen Benutzerkontext arbeiten.
3. Plugin oder skill auswählen. Prüfen Sie im öffentlichen Repository, welcher Eintrag für Ihren Codex-Ablauf vorgesehen ist. Übernehmen Sie keine Anleitung allein aufgrund ähnlicher Namen.
4. Skill-Anweisungen einrichten. Folgen Sie der dazugehörigen Dokumentation für Codex. Kontrollieren Sie, welche Dateien oder Konfigurationen geändert werden und ob die Agent-Anweisungen in Ihrem Projekt oder nur in Ihrer Benutzerumgebung gelten.
5. Authentifizierung separat abschließen. Verwenden Sie die von Atlassian dokumentierte Anmeldung und überprüfen Sie, welches Konto anschließend aktiv ist. Eine erfolgreich erkannte skill beweist nicht, dass die CLI angemeldet ist.
6. Mit einer lesenden Anfrage testen. Verwenden Sie einen bekannten Vorgang oder ein bekanntes Dokument und vergleichen Sie die Antwort mit der Originalquelle. Führen Sie dabei noch keine Änderungen an Atlassian-Daten oder im Repository als Folgeaktion aus.
7. Einrichtung dokumentieren. Halten Sie fest, welcher Installationsweg verwendet wurde, welches Konto aktiv war, welche Quelle geprüft wurde und welches Ergebnis Sie tatsächlich gesehen haben. Dokumentieren Sie keine Zugangsdaten.

Die Schritte sind absichtlich so formuliert, dass Sie die aktuellen Befehle der offiziellen Quelle entnehmen, statt eine möglicherweise veraltete Befehlszeile zu kopieren. Bei einer Teaminstallation sollten Sie vor einer breiteren Freigabe auch klären, wie die skill verteilt und aktualisiert wird. Ein lokal erfolgreicher Test reicht nicht als Nachweis, dass jede Entwicklerumgebung dieselbe Konfiguration oder dieselben Rechte besitzt.

4Nach der Anmeldung: Identität, Datenzugriff und MCP abgleichen

Die Anmeldung entscheidet, unter welcher Identität der Zugriff stattfindet. Atlassian erklärt in der Dokumentation zur Authentifizierung, wie die Authentifizierung der CLI funktioniert. Lesen Sie diese Beschreibung für den tatsächlich genutzten Ablauf und prüfen Sie anschließend, welches Konto und welche Atlassian-Site aktiv sind. Eine Anzeige „angemeldet“ ist noch kein ausreichender Beleg dafür, dass die Identität der vorgesehenen Team- oder Testidentität entspricht.

Danach folgt die Berechtigungsprüfung. Richten Sie sich nach Atlassians Anleitung zur Konfiguration der CLI-Berechtigungen. Fragen Sie gezielt nach einem Inhalt, den das angemeldete Konto in der Atlassian-Oberfläche sehen darf. Prüfen Sie außerdem einen bewusst nicht zugänglichen oder nicht freigegebenen Bereich anhand der Organisationsregeln, ohne vertrauliche Daten in einen Testprompt zu kopieren. Wenn Codex eine Quelle nennt, öffnen Sie sie mit demselben Konto und kontrollieren Sie, ob die zusammengefasste Information tatsächlich dort steht.

Das ist auch der Punkt, an dem Sie Teamwork Graph CLI und Atlassian MCP vergleichen sollten. Die CLI ist für einen dokumentierten Befehls- und Agentenpfad relevant; MCP beschreibt einen anderen Ansatz, Werkzeuge für Agenten bereitzustellen. Die passende Wahl hängt davon ab, welche Agenten und Integrationen Ihr Team betreibt, wie Sie Identitäten verwalten und welche Werkzeuge Ihre Plattform freigibt. Atlassian stellt dazu einen Entscheidungsleitfaden zu Teamwork Graph CLI und Atlassian MCP bereit. Verwenden Sie ihn, statt anzunehmen, dass eine der Varianten grundsätzlich umfassender oder sicherer ist.

Entscheidung nach Einsatzfall:

• Codex CLI mit einem dokumentierten Atlassian-Zugriffspfad: Prüfen Sie zuerst die Teamwork Graph CLI und die dafür beschriebenen Codex skills. Das ist der naheliegende Prüfpfad, wenn genau diese Kombination Ihr Ziel ist.
• Agentenübergreifende Werkzeugbereitstellung: Bewerten Sie den MCP-Weg, wenn Ihr Team Werkzeuge in einer MCP-Architektur bereitstellen und nach deren Regeln verwalten möchte. Prüfen Sie dabei die konkrete Atlassian-Unterstützung und die Vorgaben Ihrer Plattform.
• Nur ein einzelner Projektkontext: Wenn Sie lediglich einen Vorgang oder eine Entscheidung berücksichtigen müssen, kann eine manuell ausgewählte, freigegebene Quelle für den Test ausreichen. Das ist kein Ersatz für eine dauerhafte Integration, begrenzt aber den Umfang des ersten Versuchs.
• Unklare Organisationsfreigabe: Stoppen Sie die Einrichtung, bis Administratoren Identität und zulässigen Datenzugriff bestätigt haben. Eine technische Möglichkeit zum Abfragen ist keine betriebliche Genehmigung.

5FAQ zur Konfiguration und Abnahme

Wie richten Sie die Teamwork Graph CLI für Codex ein?
Prüfen Sie zuerst die aktuelle Atlassian-Anleitung für Installation und Authentifizierung sowie das öffentliche Plugin-Repository. Richten Sie CLI und passende Codex skill getrennt ein: Die CLI stellt den Zugriffspfad bereit, während die skill dem Agenten beschreibt, wie er ihn verwenden soll. Melden Sie sich anschließend mit dem vorgesehenen Arbeitskonto an und beginnen Sie mit einer lesenden Abfrage.

Welche Atlassian-Inhalte kann Codex über die CLI sehen?
Das hängt von den über die CLI verfügbaren Funktionen, der Konfiguration Ihrer Organisation und den Rechten des angemeldeten Kontos ab. Prüfen Sie die aktuelle Dokumentation und testen Sie gezielt mit bekannten Jira-Vorgängen, Confluence-Inhalten oder Projektbezügen, die dieses Konto bereits öffnen darf. Behandeln Sie eine gefundene Antwort erst dann als verlässlich, wenn Sie sie zur Originalquelle zurückverfolgt haben.

Wann passt die Teamwork Graph CLI besser als Atlassian MCP?
Wählen Sie nicht allein nach dem Namen der Schnittstelle. Vergleichen Sie die von Atlassian dokumentierten Einsatzwege mit Ihrem Agenten, den verfügbaren Werkzeugen, der Anmeldung und den organisatorischen Vorgaben. Wenn Ihr Ziel ausdrücklich die Nutzung aus Codex ist, prüfen Sie den dokumentierten CLI- und skill-Pfad. Für andere Agenten oder eine MCP-basierte Werkzeuganbindung kann der offizielle Entscheidungsleitfaden die passendere Orientierung geben.

Wie prüfen Sie, ob Codex vorhandene Atlassian-Rechte einhält?
Melden Sie sich mit dem vorgesehenen Arbeitskonto an und vergleichen Sie die Ergebnisse einer lesenden Abfrage mit dem, was dieses Konto in der jeweiligen Atlassian-Oberfläche öffnen kann. Prüfen Sie auch, ob der Agent Originalquellen nennt und ob gesperrte Inhalte ausgeschlossen bleiben. Testen Sie die Sperrung oder Entziehung des Zugriffs separat nach den Organisationsregeln; schließen Sie aus einer erfolgreichen Abfrage nicht auf weitergehende Rechte.

6Erster Codierungsauftrag: Kontextbezug und Ausführung getrennt abnehmen

Wählen Sie nach erfolgreicher Rechteprüfung eine kleine, reversible Aufgabe. Geeignet ist eine Änderung, deren fachliche Anforderung aus einem bekannten Jira-Vorgang oder einer freigegebenen Confluence-Entscheidung hervorgeht und deren Ergebnis Sie anhand des Repositorys kontrollieren können. Bitten Sie Codex, die verwendeten Quellen kenntlich zu machen und vor einer Änderung die relevante Anforderung zusammenzufassen. So erkennen Sie, ob der Agent den richtigen Kontext gefunden hat, statt nur eine plausible, aber unbelegte Beschreibung zu erzeugen.

Prüfen Sie die Antwort gegen die Originalquellen: Stimmen Vorgang, Entscheidung und Bezug zum Code überein? Wurden offene Fragen als offen benannt? Hat Codex Informationen ergänzt, die in den genannten Quellen nicht enthalten sind? Wenn die Antwort nur einen Teil der Projektbezüge findet, suchen Sie die Ursache zuerst in Anfrage, verfügbarer CLI-Funktion, skill-Konfiguration oder Kontorechten. Ändern Sie nicht gleichzeitig Berechtigungen und Prompt, denn dann lässt sich ein verbessertes Ergebnis nicht mehr eindeutig erklären.

Trennen Sie bei der Abnahme vier Ergebnisse:

• Kontextabruf: Die relevanten Atlassian-Quellen wurden gefunden und korrekt wiedergegeben.
• Codeänderung: Die Änderungen passen zur Anforderung und sind im Diff nachvollziehbar.
• Testausführung: Die vorgesehenen Prüfungen liefen in der passenden Umgebung durch.
• Lieferfreigabe: Ein zuständiger Mensch hat Ergebnis, Quellen und Risiken geprüft und die Änderung freigegeben.

Ein Erfolg auf einer Ebene beweist nicht den Erfolg der nächsten. Insbesondere ist die Verbindung der Teamwork Graph CLI mit Codex kein Nachweis, dass ein Build tatsächlich ausgeführt wurde. Bei iOS- oder macOS-Projekten müssen Sie separat feststellen, ob die Aufgabe Apples Werkzeugkette und damit eine echte macOS-Umgebung mit Xcode benötigt. Eine Kontextabfrage kann in einer anderen Umgebung funktionieren, während Kompilierung, Signierung oder ein reproduzierbarer Apple-Plattformtest dort nicht verfügbar sind. Planen Sie die Ausführungsumgebung anhand der Lieferanforderung, nicht anhand der Tatsache, dass die CLI bereits antwortet.

Auch ein plausibles Ergebnis ist noch kein Sicherheitsnachweis. Lassen Sie den Agenten bei einem kontrollierten Test die Referenzen nennen und gleichen Sie die relevanten Aussagen mit den Originalseiten ab. Wenn eine Antwort Inhalte aus mehreren Quellen zusammenzieht, prüfen Sie, ob die Zuordnung erhalten blieb und ob unterschiedliche Aktualitätsstände kenntlich sind. Ein zusammengefasster Projektkontext kann nützlich sein, aber er darf nicht als Ersatz für die Prüfung einer verbindlichen Anforderung dienen.

7Freigabe vor dem Teamrollout: prüfbare Kriterien statt Annahmen

Bevor Sie die Einrichtung für ein Team freigeben, verwenden Sie diese abhakbare Prüfung. Sie ist auf konkrete Nachweise ausgerichtet und nicht auf einen einmalig erfolgreichen Agentenlauf.

• [ ] Die verwendete Installationsanleitung stammt aus der aktuell erreichbaren offiziellen Atlassian-Dokumentation.
• [ ] Die Codex skill oder das Plugin wurde anhand des öffentlichen Repositorys dem richtigen Agentenablauf zugeordnet.
• [ ] Die aktive Identität und die Atlassian-Site entsprechen dem genehmigten Testkonto.
• [ ] Eine lesende Abfrage zu einer bekannten Quelle lieferte einen Inhalt, den Sie in der Originalquelle verifizieren konnten.
• [ ] Das Ergebnis wurde nicht als Beleg für Inhalte behandelt, auf die das Konto keinen Zugriff haben sollte.
• [ ] Administratoren wissen, wie die verwendete Identität und der Zugriff gemäß den Organisationsregeln geändert oder entzogen werden.
• [ ] Codeänderung, Testausführung und Freigabe wurden getrennt von der Kontextsuche bewertet.
• [ ] Bei Apple-Plattformaufgaben wurde die Notwendigkeit einer macOS- und Xcode-Umgebung separat geprüft.

Abnahmehinweis: Wenn eine dieser Prüfungen offen bleibt, begrenzen Sie den Einsatz auf den kontrollierten Test. Erweitern Sie nicht vorsorglich Zugriffsrechte, nur damit ein Agent eine unklare Abfrage beantworten kann. Klären Sie zuerst, welche Quelle benötigt wird und welches Konto dafür vorgesehen ist.

Ein Team-Rollout sollte erst folgen, wenn die Konfiguration wiederholbar ist und die Verantwortlichen wissen, wer sie pflegt. Halten Sie die geprüfte CLI-Anleitung, die ausgewählte skill, den Identitätstyp und den Umfang der getesteten Quellen in Ihrer internen Dokumentation fest. Speichern Sie dort keine Tokens oder andere Geheimnisse. Bei einer späteren Änderung an CLI, Plugin, Authentifizierung oder Atlassian-Berechtigungen ist die bisherige Abnahme nicht automatisch weiter gültig. Prüfen Sie dann gezielt die betroffenen Schritte erneut.

Für die Absicherung eines Agentenbetriebs sind außerdem Laufzeit und Datenzugriff getrennte Themen. Eine wiederholbare Umgebung hilft dabei, installierte Werkzeuge, Projektdateien und Testergebnisse nachvollziehbar zu halten; sie ersetzt aber weder eine Rechteprüfung noch eine Genehmigung durch die zuständige Administration. Wenn Sie den Test in eine dauerhafte Teamroutine überführen, dokumentieren Sie daher sowohl die technische Umgebung als auch den Identitäts- und Freigabeweg. Eine allgemeine Orientierung zu Ausführungsumgebungen und Zugriffsprüfungen finden Sie in unserem Leitfaden für AI-Agenten und Entwicklungsumgebungen.

Für Teams, die eine länger laufende Agentenausführung oder eine isolierte Umgebung planen, sollte die Wahl der Ausführungsumgebung unabhängig von der Atlassian-Anbindung erfolgen. Die Teamwork Graph CLI muss nicht allein deshalb auf einem Cloud-Mac laufen, weil Codex verwendet wird. Wenn Ihre vorhandene Entwicklungsumgebung stabile Ausführung, verwaltete Zugangsdaten und nachvollziehbare Wiederherstellung bereits erfüllt, kann sie ausreichen. Fehlen diese Eigenschaften, prüfen Sie zuerst, welche Aufgaben tatsächlich persistent oder von Apple-Werkzeugen abhängig sind. Hinweise zur Nutzung einer bereitgestellten Remote-Umgebung finden Sie in der Hilfe zur Remote-Umgebung.

Wenn Sie Codex derzeit auf wechselnden Entwicklerrechnern oder einem gemeinsam genutzten Runner betreiben, können uneinheitlich installierte Werkzeuge, liegengebliebene Anmeldedaten und schwer nachvollziehbare Laufzeitänderungen die Abnahme erschweren. Ein dedizierter Mac ist deshalb nicht für die Teamwork-Graph-Verbindung selbst nötig, kann aber bei länger laufenden Aufgaben oder bei echtem Bedarf an macOS und Xcode die Ausführungsumgebung besser abgrenzen. Wenn Sie nur Atlassian-Kontext abfragen und Code auf Ihrer bestehenden, freigegebenen Umgebung prüfen, ist eine Mac-Miete möglicherweise unnötig. Benötigen Sie dagegen vorübergehend eine separate Remote-Mac-Umgebung für Apple-Toolchain-Aufgaben, können Sie vpstix in Betracht ziehen; entscheiden Sie nach dem tatsächlichen Build- und Betriebsbedarf, nicht nach der CLI-Installation.