OpenAI Codex Ende 2026: Goal Mode, Dots und wie man es absichert

Ich nutze Codex in meiner eigenen Arbeit neben Claude Code, und es hat sich dieses Jahr stärker verändert als jedes andere Werkzeug auf meinem Tisch. Es ist Teil der bezahlten ChatGPT-Pläne, es verfolgt ein Ziel über Stunden, seit September gibt es Dots, immer aktive Agenten mit eigenem Cloud-Computer, und Ende Oktober kam ein günstigeres Modell. Das ist viel Autonomie, die man einem Team auf einmal gibt. Das meiste Risiko kommt dabei nicht vom Modell, sondern von Voreinstellungen, die niemand angeschaut hat: eine Sandbox, die weiter ist als nötig, abgeschaltete Freigaben auf einem Laptop mit Produktionszugang. Das hier lohnt sich heute, und das sind die genauen Einstellungen, die ich setze, bevor ein Team startet.

Dominik Heinrich

7. November 202610 Min. Lesezeit

1. Wo Codex läuft und was es kostet

Codex ist kein separates Produkt mehr, das man kauft. OpenAIs Preisseite führt es innerhalb der ChatGPT-Pläne: Plus für 20 Dollar im Monat für „ein paar fokussierte Coding-Sessions pro Woche“, Pro ab 100 Dollar mit Stufen zu 100, 200 und 500, und Business für 20 Dollar pro Nutzer und Monat bei jährlicher Abrechnung (25 monatlich) mit eigenem Workspace, Admin-Kontrollen, SAML-SSO und standardmässig keinem Training auf Geschäftsdaten. Enterprise und Edu gibt es auf Anfrage. Es läuft in der ChatGPT-Desktop-App, in der Codex CLI, in der IDE-Erweiterung, auf iOS und als Cloud-Tasks, die auf einer Kopie Ihres Repositorys arbeiten, und ChatGPT Work und Codex teilen sich Nutzung und Guthaben. Für CI gibt es einen eigenen Weg: Codex mit API-Key, abgerechnet zu API-Preisen und ohne Cloud-Funktionen wie das GitHub-Code-Review. Für einen Team-Pilot starte ich meist mit Business, weil es die Admin-Kontrollen aus den nächsten Schritten nur dort gibt.

2. Die Modelle darunter: Sol, Terra und das abgelöste GPT-5.5

OpenAI hat GPT-6.1 Terra am 26. Oktober veröffentlicht und für Plus, Pro, Enterprise und Edu in ChatGPT Work und Codex freigeschaltet. In der Ankündigung schreibt OpenAI, dass Terras Standard-API-Preise 50 % unter denen von GPT-5.6 Terra und GPT-6.1 Sol liegen, bei 1 Dollar pro Million Input-Tokens und 5 Dollar pro Million Output-Tokens. Für lange Agentenläufe zählt das mehr als ein paar Benchmark-Punkte, denn die Kosten pro Aufgabe entscheiden, wie oft man einen Agenten iterieren lassen kann. Gleichzeitig wurde GPT-5.5 am 14. Oktober aus Codex mit ChatGPT-Anmeldung entfernt; Sessions mit API-Key waren nicht betroffen. Meine Regel in Projekten: das günstigere Modell für viel, gut getestete Arbeit wie Dependency-Updates und Testkorrekturen, das stärkste Modell für Refactorings über viele Module. Pinnen Sie das Modell für CI in der config.toml, damit eine geänderte Voreinstellung Sie nie mitten im Sprint überrascht.

Introducing dots, always-on agents built to handle everything, OpenAI (YouTube). Wird erst nach Ihrem Klick von YouTube geladen.

3. Goal Mode: ein dauerhaftes Ziel

Goal Mode begann im Frühjahr als experimenteller Slash-Befehl in der CLI und ist seit Mai in App, IDE-Erweiterung und CLI allgemein verfügbar. Die Referenz der Developer-Befehle beschreibt es schlicht: /goal mit dem Ziel dahinter setzt es, /goal allein zeigt es an, und /goal edit, pause, resume und clear steuern es, während die Aufgabe läuft. Ziele dürfen bis zu 4'000 Zeichen lang sein; für längere Anweisungen empfiehlt die Doku, die Details in eine Datei zu schreiben und das Ziel darauf zeigen zu lassen. Es gilt dieselbe Regel wie bei jeder Agentenschleife: Schreiben Sie eine Ziellinie, die Befehle beweisen können, keinen Wunsch. „Schliesse die Migration ab und halte die Tests grün“ ist das Beispiel der Doku selbst, und ich schärfe es weiter mit dem genauen Testbefehl, den Dateien, die sich nicht ändern dürfen, und einer Stopp-Klausel. Ein Ziel, das sich nicht prüfen lässt, endet nicht, es wird nur teuer.

text

/goal Migrate src/payments from the v1 client to the v2 client.
Done when: "npm test -- payments" exits 0, "npm run typecheck" exits 0,
no file under src/legacy or test/fixtures is changed, and no test is skipped.
Work on a branch and summarise the diff when done.
If blocked for more than 3 attempts on the same error, stop and explain.

4. Dots: immer aktive Agenten, die an Codex delegieren

OpenAI hat Dots am 29. September an der DevDay vorgestellt. Ein Dot ist ein immer aktiver Agent mit eigenem Cloud-Computer und Browser, der weiterarbeitet, wenn Ihr Laptop aus ist, sich über Plugins mit mehr als 4'000 Apps verbindet und in ChatGPT, Slack und Teams erreichbar ist, auch per Sprachanruf. Der Teil, der für Engineering-Teams zählt, steht in OpenAIs Dots-Dokumentation: Ein Dot kann Work- oder Codex-Tasks anlegen, bestehende lokale Codex-Tasks fortsetzen und für Repository-Arbeit eine von Ihnen angelegte Codex-Cloud-Umgebung nutzen. OpenAIs eigenes Beispiel ist ein Dot, der Kundenfeedback beobachtet, kleine Korrekturen zuschneidet, sie baut und testet und Ihnen fertige Pull Requests mit Videos der Änderung bringt. Ihr eigener Rechner bleibt getrennt, solange Sie ihn nicht verbinden, Custom Rules erlauben bestimmte Aktionen, verlangen eine Freigabe oder blockieren sie, und ein Auto-Review prüft riskante Aktionen gegen Ihre Anweisungen. Die Verfügbarkeit ist ungleich: Pro 100, 200 und 500 gibt es nicht im EWR, im Vereinigten Königreich und in der Schweiz, Business Premium dagegen in den unterstützten ChatGPT-Regionen, und am 3. November hat OpenAI GPT-6.1 Terra zu den Modellen hinter den Dots hinzugefügt.

Tipp aus der Praxis

Gespräche mit Ihrem Dot zählen nicht gegen die ChatGPT-Limits, Tasks, die er in Codex oder Work startet, aber schon. Beobachten Sie die Nutzung in den ersten Wochen, vor allem wenn ein Dot von sich aus viele kleine Pull Requests öffnet.

5. Sandbox und Freigaben: die Einstellung nach Risiko wählen

Die Sandbox-Doku beschreibt zwei getrennte Kontrollen. Die Sandbox ist die technische Grenze für jeden Befehl, den Codex startet, auch git, Paketmanager und Test-Runner: read-only lässt Dateien lesen, aber ohne Freigabe nichts bearbeiten oder ausführen, workspace-write erlaubt Änderungen im Workspace und dort übliche Befehle, und danger-full-access hebt Dateisystem- und Netzwerkgrenzen auf. Die Approval Policy bestimmt, wann Codex anhält und fragt, bevor es diese Grenze überschreitet: on-request fragt, wenn es über die Sandbox hinaus muss, never fragt nicht. „untrusted“ ist keine unterstützte Approval Policy mehr und „on-failure“ veraltet, prüfen Sie also alte Konfigurationen. Meine Empfehlung nach Risiko: ein unbekanntes Repository erkunden, read-only mit on-request. Normale Feature-Arbeit auf einem Branch, workspace-write mit on-request und ohne Netzwerkzugriff, was die Doku das risikoärmere Preset für lokale Automatisierung nennt. Unbeaufsichtigte Läufe in einem Wegwerf-Container ohne Secrets, workspace-write mit never; die Doku betont, dass „never“ nur die Rückfragen abstellt und keine uneingeschränkte Ausführung erlaubt. danger-full-access mit never gehört nur in eine Wegwerf-VM, nie auf einen Laptop, der Produktion erreicht.

toml

# ~/.codex/config.toml (or .codex/config.toml in a trusted project)
# Everyday feature work: edits inside the workspace, asks before anything beyond it.
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"   # or "auto_review" to let the reviewer agent handle eligible prompts

[sandbox_workspace_write]
network_access = false        # turn on only for tasks that really need the internet

Tipp aus der Praxis

Wenn eine Freigabe „einmal“ oder „für diese Session“ anbietet, wählen Sie den engsten Umfang, mit dem die Aufgabe weiterläuft, und nutzen Sie getrennte Worktrees, statt den Zugriff über Repositories hinweg auszuweiten.

Interaktiv

Welche Codex-Einstellungen passen zu Ihrer Aufgabe?

Wählen Sie die Situation. Sie bekommen Sandbox-Modus, Freigabe-Policy und die Konfiguration zum Kopieren, mit den Namen aus der Codex-Doku (November 2026).

workspace-write

sandbox_mode

on-request

approval_policy

Das risikoärmere Automatisierungs-Preset der Doku: Änderungen im Workspace, fragt vor allem anderen.

# ~/.codex/config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

Alle Rechner und Checklisten

6. Admin-Leitplanken: requirements.toml

Persönliche config.toml-Dateien sind Vorlieben; Nutzer können sie ändern. Auf Business und Enterprise gibt die Doku zur Managed Configuration Admins eine zweite Ebene. Unter Agent Security bearbeiten Sie Policy Guardrails, oder die entsprechende requirements.toml, die sicherheitsrelevante Einstellungen einschränkt: Approval Policy, Approvals Reviewer, Sandbox-Modus, Berechtigungsprofile, Websuche, verwaltete Hooks und welche MCP-Server und Plugin-Marktplätze Nutzer aktivieren dürfen. Requirements begrenzen die Auswahl; separate Defaults setzen den Startwert. Das Beispiel der Doku blockiert „--ask-for-approval never“ und „--sandbox danger-full-access“, inklusive der Abkürzung --yolo, indem es nur die sichereren Werte erlaubt. Zwei Details aus der Doku lohnen sich: Ab Codex 0.138 bevorzugt OpenAI Berechtigungsprofile mit allowed_permission_profiles statt des alten allowed_sandbox_modes, und allowed_web_search_modes = ['cached'] verhindert Live-Websuche selbst in Sessions mit vollem Zugriff. Eine nicht gesetzte Anforderung bedeutet keine Grenze, schreiben Sie also jeden Schlüssel auf, auf den Sie sich verlassen.

toml

# requirements.toml (Agent security > Edit as TOML), enforced for the workspace
# Users can still choose between these values, but nothing wider.
allowed_approval_policies = ["on-request"]                 # no "never" on managed devices
allowed_sandbox_modes     = ["read-only", "workspace-write"] # blocks danger-full-access and --yolo
allowed_web_search_modes  = ["cached"]                     # no live web search from agents

7. AGENTS.md, Rules und das Review-Tor

In AGENTS.md stehen die Konventionen: wie man die Tests startet, welche Ordner generiert sind, die Architekturregeln, die ein Reviewer sonst wiederholen würde. Das ist nützlich, aber es ist eine Anleitung, keine Sicherheitsgrenze, und alles im Repository kann die Datei ändern. Reviewen Sie Änderungen daran also wie Code und geben Sie dem Plattform-Team die Verantwortung dafür. Für echte Ausnahmen hat Codex Rules, die bestimmte Befehlspräfixe ausserhalb der Sandbox erlauben, nachfragen lassen oder verbieten, was die Sandbox-Doku einer breiten Erweiterung des Zugriffs vorzieht. Projektbezogene .codex/config.toml-Dateien werden erst geladen, wenn Sie dem Projekt vertrauen, ein geklontes Repository kann Ihre Einstellungen also nicht still lockern. Die letzte Ebene ist langweilig und unverzichtbar: Codex arbeitet auf einem Branch, die CI führt dieselben Prüfungen aus wie für einen Menschen, und ein Mensch gibt den Merge frei. Das Codex-Code-Review in GitHub ist ein guter zweiter Leser, ersetzt aber nicht die menschliche Freigabe, die Ihre Branch Protection verlangt.

8. Wie ich es in einem Team einführe

Woche eins: Business-Workspace, SSO, requirements.toml nur mit on-request und ohne vollen Zugriff, und pro Repository eine kurze AGENTS.md mit Test- und Lint-Befehlen. Woche zwei: Fünf Freiwillige nutzen Codex lokal in workspace-write an echten Tickets, und wir sammeln jede Rückfrage, die sie gestört hat; die meisten werden zu Rules oder Writable Roots statt zu weiteren Sandboxes. Wochen drei und vier: Goal Mode für gut getestete Arbeit wie Dependency-Upgrades und Testreparaturen, dazu Cloud-Tasks für kleine Issues, mit derselben CI und demselben Review wie bei menschlichen Änderungen. Dots kommen zuletzt, und nur mit einem namentlichen Owner und Custom Rules, denn ein Dot, der von sich aus Pull Requests öffnet, braucht jemanden, der sie liest. Wir messen Durchlaufzeit, Review-Aufwand und Kosten pro gemergter Änderung. Das Muster ist dasselbe wie bei jedem Agenten: zuerst Leitplanken, dann Tempo.

Fazit
Codex ist am stärksten mit einem prüfbaren Ziel, einer engen Sandbox und Dots, die ihm Arbeit übergeben, aber setzen Sie zuerst die Leitplanken zentral und geben Sie den Leuten danach das Tempo.

Echte Projekte dazu

Selbst ausprobieren

Codex-Sicherheitseinstellungen

Das für Ihr Unternehmen? Sprechen wir mail@dominikheinrich.ch

Quellen und offizielle Leitfäden