OpenAI Codex im bestehenden Repository einführen — Aufgaben sicher delegieren

Wo eine Aufgabe laufen soll

Codex gibt es als Kommandozeilen-Tool, als IDE-Erweiterung, als Desktop-App, als Cloud-Aufgaben, die aus ChatGPT gestartet werden, und als GitHub-Integration. Entscheidend ist die Wahl nach Aufgabe, nicht nach Vorliebe: Arbeit, die Ihre lokale Umgebung braucht oder die Sie Schritt für Schritt steuern wollen, passt zu den lokalen Oberflächen. Eine gut spezifizierte Änderung, die sich aus einem sauberen Checkout bauen und testen lässt, passt zu einer Cloud-Aufgabe. Wir halten das in einer kurzen Entscheidungshilfe fest, damit Ihr Team es nicht jedes Mal neu entscheiden muss.

AGENTS.md als gemeinsame Anweisungsdatei

Codex baut seine Anweisungen aus AGENTS.md-Dateien auf: eine globale im Codex-Home-Verzeichnis, danach Dateien vom Repository-Stamm bis in das Verzeichnis, in dem gearbeitet wird, in dieser Reihenfolge zusammengefügt. Eine AGENTS.override.md hat im jeweiligen Verzeichnis Vorrang, alternative Dateinamen lassen sich konfigurieren, und es gilt eine Gesamtgrößenbegrenzung (standardmäßig 32 KiB) — die Anweisungen müssen also knapp sein. Ein Befehl erzeugt einen ersten Entwurf; wir behandeln ihn als Ausgangspunkt.

Da AGENTS.md eine schlichte Konvention ist, kann sie die eine gemeinsame Quelle für ein Team sein, das zusätzlich Claude Code nutzt, dessen CLAUDE.md sie importieren kann. Wie jede Anweisungsdatei ist sie Orientierung. Was verbindlich gelten muss, wird an anderer Stelle durchgesetzt.

Sandbox und Freigaben: zwei getrennte Stellschrauben

Codex trennt, was der Agent technisch tun kann, davon, wann er nachfragen muss. Der Sandbox-Modus legt die Fähigkeit fest: schreibgeschützt, workspace-write (in versionierten Ordnern der Standard) oder voller Zugriff. Die Freigaberichtlinie legt fest, wann ein Mensch gefragt wird: auf Anfrage (Standard), gar nicht oder in einer granularen Einstellung. Beides wird kombiniert; eine Workspace-write-Sandbox mit Freigabe auf Anfrage ist etwas völlig anderes als voller Zugriff ohne Freigaben. Wir wählen je nach Aufgabentyp.

• Netzwerkzugriff ist standardmäßig aus und lässt sich gezielt öffnen, auch über Erlaubnis- und Sperrregeln für Domains
• Im Workspace sind die Ordner .git, .codex und .agents als schreibgeschützt geschützt
• Die Websuche wird standardmäßig aus einem Cache bedient
• Wir dokumentieren, welche Kombination für welche Art von Aufgabe gilt und wer sie lockern darf

Befehlsregeln und Vertrauen in die Projektkonfiguration

Codex liest Befehlsregeln aus .rules-Dateien; jede Präfixregel ist als allow, prompt oder forbidden markiert, und die restriktivste passende Regel gewinnt. Mit einem Prüfbefehl testen wir eine Regel an einem Beispielbefehl, bevor wir uns auf sie verlassen. Die Konfiguration liegt in einer benutzerbezogenen config.toml und kann zusätzlich im Repository liegen; die Projektebene wird nur für Projekte angewendet, die Sie als vertrauenswürdig markiert haben — Vertrauen ist also eine bewusste Entscheidung, keine Voreinstellung. Hooks können eine Aktion an bestimmten Punkten ebenfalls blockieren. Eine Regel erfasst die Form eines Befehls und kann eine ungewöhnliche Variante derselben Aktion übersehen; deshalb ist sie nur eine Schicht unter mehreren.

Cloud-Aufgaben gestalten

Eine Cloud-Aufgabe läuft in einem Container, in dem Ihr Repository ausgecheckt ist. Zuerst läuft ein Setup-Skript mit Internetzugang, das Abhängigkeiten installiert. Die Agentenphase läuft danach standardmäßig ohne Internet. Für die Umgebung hinterlegte Secrets stehen während des Setups zur Verfügung und werden vor der Agentenphase entfernt; das Ergebnis kommt als Diff und danach als Pull Request zurück.

Das bestimmt, was wir bauen: ein Setup-Skript, das eine funktionierende, testbare Umgebung erzeugt, Aufgaben, die sich ohne externe Dienste überprüfen lassen, und die Entscheidung, was der Agent gar nicht erst benötigen darf. Wir unterstellen nicht, dass andere Tools denselben Mechanismus für Secrets haben.

Isolation und Worktrees

Für lokale parallele Arbeit kann Codex Worktrees verwalten, die im Detached-Zustand ausgecheckt werden, damit sich Aufgaben nicht in die Quere kommen. Eine Include-Datei für Worktrees listet ignorierte Dateien auf, die hineinkopiert werden; diese Bequemlichkeit kann auch Secret-Dateien wie lokale Umgebungsdateien kopieren, weshalb wir sie Zeile für Zeile prüfen. Wir vereinbaren mit Ihnen, wie aus losgelöster Arbeit Branches entstehen und wie fertige Worktrees aufgeräumt werden.

Review und CI

Codex kann Pull Requests reviewen, wenn er per Kommentar aufgerufen wird oder automatisch über den GitHub-Connector; außerdem lässt er sich nicht-interaktiv aus Skripten starten, standardmäßig mit schreibgeschützter Sandbox, und über eine offizielle GitHub Action. Wir entscheiden, ob und wo das in Ihre Pipeline gehört, und halten die Berechtigungen des Jobs schmal. Ein automatisches Review ist ein zusätzlicher Leser, kein Ersatz für Ihre Reviewer.

Vorgaben auf Organisationsebene

Für größere Teams können Administratoren Vorgaben durchsetzen, die Nutzer nicht überschreiben können — über eine Requirements-Datei, cloudverwaltete Konfiguration oder Geräteverwaltung. Was davon bei Ihnen gilt, hängt davon ab, wie Ihre Organisation Codex einsetzt; das prüfen wir beim Assessment, statt es vorauszusetzen.

Was passiert mit unserem Code und unseren Daten?

Beim Assessment prüfen wir für Codex, wie das Werkzeug zu Ihren Anforderungen passt: Datenumgang des Anbieters, Authentifizierung und Zugriff, Repository-Berechtigungen, Secrets und Umgebungsvariablen sowie welcher Code und Kontext dem Werkzeug zugänglich wird — bei Cloud-Aufgaben auch, was in die Umgebung gelangt. Das ist keine Rechtsberatung und keine DSGVO-Zertifizierung, und wir geben keine Garantie.

Onboarding und Übergabe

Ihr Team erhält eine schriftliche Anleitung: welche Aufgaben delegiert werden, wie man sie formuliert, was im zurückgelieferten Diff zu prüfen ist und wann eine Aufgabe lokal bleibt. Eine benannte Person auf Ihrer Seite pflegt AGENTS.md, Regeln und die Cloud-Umgebung.

Abgrenzung

KI-gestützte Softwareentwicklung einführen beschreibt den werkzeugneutralen Workflow, und Claude Code für Entwicklungsteams einführen behandelt das Gegenstück für dieses Tool. Die ChatGPT-Einführung richtet sich an Mitarbeitende ohne Entwicklerrolle, die ChatGPT in einem Workspace nutzen — nicht an Entwicklerinnen und Entwickler, die Repository-Aufgaben delegieren. Die Basis aus Repositories, CI und Releases legt die Entwicklungsinfrastruktur-Einrichtung.

Grenzen

Wir versprechen keine Produktivitätsprozente, keine autonome Entwicklung und keinen Wegfall des Code-Reviews. Wir sagen keine Kompatibilität mit jedem Repository zu und treffen keine Aussagen zu Tarifen, Preisen, Datenspeicherung oder Compliance des Tools. Der Umfang wird nach dem Blick auf Ihr Repository festgelegt; der Zeitrahmen hängt von der Komplexität des Repositorys und der vorhandenen CI/CD ab.

Was Umfang und Aufwand bestimmt

Zuerst das Assessment, dann ein abgegrenzter Umsetzungsplan, dann Angebot und Zeitrahmen. Bitte nennen Sie in der Anfrage: Art des Repositorys, Sprache und Framework, Monorepo oder mehrere Repositories, Teamgröße, Branching-Strategie, CI/CD, Test-, Build- und Lint-Setup, bereits genutzte KI-Tools, Schmerzpunkte, Sicherheitsvorgaben, den Umgang mit Secrets und welche Aufgaben Sie delegieren möchten.