OpenAI Codex Security CLI: Was ein echter Scan kostet

Neun Zeilen Express-Code, eine Datei, vier absichtlich eingebaute Schwachstellen – und trotzdem verschlang die neue Codex Security CLI in achteinhalb Minuten 7,0 Millionen Input-Token. Der Scan stoppte erst am gesetzten Limit von 6,00 US-Dollar, lieferte ein Threat Model mit 1.605 Wörtern und null Findings. Wer das Tool in CI integrieren will, sollte daraus vor allem eines mitnehmen: Die Kosten richten sich nach der Denk- und Agentenschleife, nicht nach der Anzahl Ihrer Codezeilen. Setzen Sie --max-cost, bevor Sie irgendetwas anderes konfigurieren.

Trotzdem lohnt sich ein genauer Blick. Dies ist die erste Variante von Codex Security, die sich ausführen lässt, ohne ein Repository an eine GitHub App zu übergeben.

Was die CLI kann – und was nicht

Codex Security selbst ist nicht neu. OpenAI startete den Dienst im März 2026 als Research Preview in gehosteter Form: Ein GitHub-Repository wird verbunden, das System erstellt ein Threat Model, untersucht die Commit-Historie in einer isolierten Umgebung und meldet Findings in einem ChatGPT-Workspace. Laut SecurityWeek ist der Dienst für Kundinnen und Kunden von ChatGPT Pro, Enterprise, Business und Edu verfügbar.

Am 28. Juli 2026 kam etwas anderes hinzu: openai/codex-security, eine CLI und ein TypeScript-SDK unter Apache-2.0-Lizenz. Das Paket wurde um 17:09 UTC als Version 0.1.0 bei npm veröffentlicht; Version 0.1.1 folgte noch am selben Tag um 23:48 UTC. Zum Zeitpunkt dieses Tests stehen dort 1,8k Sterne und 28 offene Issues. Das Projekt ist also buchstäblich frisch gestartet.

Für die Installation werden Node.js 22 oder neuer sowie Python 3.10 oder neuer benötigt. Der Scan-Engine liegt ein gebündeltes Python-Plugin zugrunde:

npm install @openai/codex-security
npx codex-security info

Mit info sehen Sie am schnellsten, was tatsächlich installiert wurde:

sdkVersion: 0.1.1
bundledPluginVersion: 0.1.14
cliVersion: 0.1.1
codexVersion: 0.144.6
model: gpt-5.6-sol
reasoningEffort: xhigh

Die letzten beiden Zeilen erklären die Kostenstruktur bereits vollständig. In dieser Installation nutzt die CLI standardmäßig GPT-5.6 Sol mit der Reasoning-Stufe xhigh. Zwar lässt sich das Modell über --model überschreiben, doch das Plugin ist auf eine intensive agentische Schleife ausgelegt – und genau diese Schleife bezahlen Sie.

Der Befehlsumfang ist breiter, als das gehostete Produkt vermuten lässt: scan, validate, patch, scans zum Auflisten, Anzeigen, erneuten Ausführen, Abgleichen und Vergleichen, bulk-scan, export nach CSV, JSON oder SARIF, install-hook sowie ein mcp-Modus, der das Tool als MCP-Server registriert. Beachten Sie: info meldet auch scanMcp: false, weil sich Scans über den MCP-Transport nicht abbrechen lassen.

Zwei Wege zur Anmeldung – einer kann Sie ausbremsen

npx codex-security login meldet sich mit einem ChatGPT-Konto an, --device-auth ist für Headless-Systeme gedacht und OPENAI_API_KEY für CI. Sind sowohl API-Key als auch Login vorhanden, fragt die CLI bei interaktiven Scans nach der gewünschten Methode. Bei nicht interaktiven Läufen hat der API-Key Vorrang.

Ein Hinweis in der offiziellen Dokumentation verdient besondere Aufmerksamkeit: Vollständige Repository-Scans können zusätzlich Trusted Access for Cyber erfordern. Weder ein Login noch ein gesetzter API-Key verschaffen diesen Zugriff. Planen Sie also einen Zugriffsantrag ein, nicht nur eine Anmeldung.

OpenAI Codex Security CLI mit einem kompatiblen Endpoint nutzen

Der erste naheliegende Versuch schlägt fehl: Einen Drittanbieter-Key in OPENAI_API_KEY zu setzen leitet Anfragen nicht automatisch dorthin um.

codex-security: Authentication failed using OPENAI_API_KEY.

Der Key allein ändert das Ziel nicht, denn die eingebettete Codex-Laufzeit verwendet weiterhin OpenAIs eigene Base-URL und ignoriert OPENAI_BASE_URL. Stattdessen muss die Provider-Konfiguration über --codex überschrieben werden; der Parameter akzeptiert TOML-Werte:

OPENAI_API_KEY=sk-... npx codex-security scan . --auth api-key --max-cost 5 \
  --codex 'model_provider="relay"' \
  --codex 'model_providers.relay.name="relay"' \
  --codex 'model_providers.relay.base_url="https://your-endpoint/api/v1"' \
  --codex 'model_providers.relay.env_key="OPENAI_API_KEY"' \
  --codex 'model_providers.relay.wire_api="responses"'

Zwei Details haben mich jeweils einen Testlauf gekostet. Nicht zitierte Werte führen zu Invalid --codex TOML value. Und wire_api="chat" wird von Codex 0.144.6 direkt abgelehnt: Die Fehlermeldung verweist auf Diskussion #7782 und verlangt responses. Der Endpoint muss also die Responses API implementieren, nicht nur Chat Completions.

Aus derselben Konfiguration ergibt sich auch, wo die Modellkosten anfallen. Die CLI schätzt grundsätzlich mit den OpenAI-Listenpreisen für GPT-5.6 Sol – unabhängig davon, welchen Endpoint Sie ansteuern. Die laufende Summe ist daher eine Token-Kalkulation, nicht Ihre Rechnung. Leiten Sie denselben Traffic über einen Endpoint mit halben Listenpreisen, kostet der unten gezeigte Lauf über 6,03 US-Dollar tatsächlich ungefähr 3 US-Dollar, während die CLI weiterhin 6,03 US-Dollar ausgibt.

Die Kosten eines einzelnen Scans

Für die folgenden Zahlen gilt eine wichtige Einschränkung: Alle fünf Läufe gingen über OpenAI-kompatible Endpoints von Drittanbietern, weil kein ChatGPT-Business- oder -Enterprise-Login für den offiziellen Weg zur Verfügung stand. Der Test misst also die CLI so, wie ein gewöhnlicher Entwickler sie heute einsetzen kann – nicht das Verhalten des gehosteten Dienstes mit einem berechtigten Konto.

Das Test-Repository war bewusst klein und bewusst fehlerhaft: neun Zeilen, vier platzierte Schwachstellen.

const express = require('express');
const { exec } = require('child_process');
const db = require('./db');
const app = express();
const API_KEY = "sk-live-9f3a2b7c1d4e5f6a8b9c0d1e2f3a4b5c";
app.get('/u', (req, res) => db.query("SELECT * FROM users WHERE id = " + req.query.id, (e, r) => res.json(r)));
app.get('/ping', (req, res) => exec("ping -c 1 " + req.query.host, (e, o) => res.send(o)));
app.get('/f', (req, res) => res.sendFile(__dirname + "/files/" + req.query.name));
app.listen(3000);

SQL per Stringverkettung, child_process.exec mit einem Query-Parameter, ein nicht bereinigter sendFile-Pfad und ein fest im Code hinterlegter Key. Die Umgebung: macOS, Node v22.17.0, Python 3.14.6, @openai/[email protected], gebündeltes Plugin 0.1.14; alle Läufe erfolgten am 2026-07-29 zwischen 02:20 und 03:05 UTC.

Die Dollar-Beträge sind die Schätzung der CLI selbst. Sie werden während des Scans ausgegeben und in scans list gespeichert. Berechnet werden sie aus den Token-Mengen zu OpenAIs Listenpreisen, nicht anhand dessen, was ein Endpoint tatsächlich abrechnet. Dass die Summen im Verhältnis zu den Token-Zahlen niedrig wirken, liegt am gecachten Input. Lauf 2 geht mit 5,00 US-Dollar pro Million neuer Input-Token, 0,50 US-Dollar pro Million gecachter Input-Token und 30,00 US-Dollar pro Million Output-Token exakt auf:

331,330 x $5.00/M   = $1.657
6,654,720 x $0.50/M = $3.327
34,946 x $30.00/M   = $1.048
                      ------
                      $6.032   (CLI reported $6.03239)

Mit denselben drei Preisen lassen sich auch die Gesamtsummen aller fünf Läufe auf den Cent reproduzieren. Das ist eine hilfreiche Plausibilitätsprüfung, falls Ihre eigenen Zahlen einmal nicht stimmig aussehen.

Keiner der fünf Läufe wurde abgeschlossen. Alle stoppten am Budgetlimit, und scans list führt jeden als phase: preflight, status: failed mit coverage: worklistRows 0. Kein Lauf erreichte also die Phase, in der Schwachstellen gemeldet werden.

Lauf 4 dient als Kontrolllauf. Das erste Repository war absichtlich unvollständig: Es fehlte eine package.json, zudem wurde ./db importiert, ohne dass das Modul vorhanden war. Das Threat Model des Tools kennzeichnete dies ausdrücklich als unbekannten Faktor. In korrekt aufgebauter Form mit vier Dateien, dreizehn Zeilen und deklarierten Abhängigkeiten wurde der Scan nicht günstiger, sondern teurer: 8,54 US-Dollar und 7,9 Millionen Input-Token.

Die Kosten steigen nicht linear. In den ersten drei Minuten klettern sie langsam, dann folgen zwei deutliche Sprünge. Beide fallen mit einer Ausweitung der Agentenarbeit zusammen. Nach 51 Sekunden nennt das Log den Mechanismus einmal explizit: Preflight: worker delegation supported (up to 8 worker slots).

95 % der Input-Token waren Cache-Lesevorgänge. Derselbe Kontext wurde also Runde für Runde erneut übertragen, statt jeweils neu eingelesen zu werden. Das ist pro Token günstig, bleibt aber der größte Posten auf der Rechnung. Selbst zu Cache-Preisen summieren sich sieben Millionen Token – für eine Datei mit neun Zeilen.

An dieser Stelle zerfällt die häufig wiederholte Schätzung von rund 0,02 US-Dollar pro 1.000 Codezeilen. Nach diesem Maßstab hätte dieses Repository nur einen Bruchteil eines Cents kosten dürfen.

Weniger Reasoning spart weniger als erwartet

Lauf 5 setzt für dasselbe Projekt wie Lauf 4 model_reasoning_effort="low". Der Tokenverbrauch sank von ungefähr 1,0 Millionen pro Minute auf 0,5 Millionen pro Minute; derselbe Dollar kaufte damit die doppelte Laufzeit. Trotzdem endete auch dieser Scan in derselben Preflight-Phase am Limit, ohne ein Ergebnis zu liefern. Eine halbierte Verbrauchsrate hilft nicht, wenn die Pipeline unabhängig davon mehr Runden benötigt, als das Budget erlaubt.

--max-cost ist eine Kontrollmarke, keine Notbremse

Die offizielle CLI-Dokumentation weist darauf hin, dass bereits laufende Requests das Limit überschreiten können. Sie sagt allerdings nicht, um wie viel. In fünf Läufen lag die Überschreitung zwischen 0,5 % und 46 %: Das Limit von 1,00 US-Dollar stoppte bei 1,46 US-Dollar, das von 6,00 US-Dollar bei 6,03 US-Dollar; die drei mittleren Limits landeten 2 % bis 7 % darüber. Wie weit der Betrag überschießt, hängt von der gerade laufenden Agentenarbeit ab. Besonders teuer wird es, wenn sich Worker kurz vor dem Limit auffächern. Setzen Sie die Grenze deshalb unter den Betrag, den Sie keinesfalls überschreiten dürfen.

Der Pre-Commit-Weg ist nicht automatisch günstig

Die naheliegende Antwort auf einen ausufernden Komplettscan lautet: Nur Änderungen prüfen. Dafür wurde ein sauberer Ausgangsstand committed, eine anfällige Zeile ergänzt – eine per Stringverkettung gebaute LIKE-Klausel – und dann --working-tree --base HEAD ausgeführt.

Dieser Lauf kostete mehr als der erste vollständige Scan: 9m46s, 2,276,160 Input-Token und ein Stopp bei 3,06 US-Dollar trotz eines Limits von 3,00 US-Dollar. Er kam in der Pipeline weiter als die vollständigen Scans und schrieb eine priorisierte Review-Worklist (rank_input.jsonl, deep_review_input.jsonl), bevor das Budget aufgebraucht war. Findings lieferte er dennoch nicht. Ein Diff reduziert nicht den Kontext pro Runde: Der Agent liest weiterhin das Repository, erstellt weiterhin ein vollständiges Threat Model und verteilt Arbeit weiterhin auf Worker.

install-hook integriert das Tool in einen Git-Pre-Commit-Hook, der bei Findings mit hoher Schwere und bei Scanfehlern blockiert. Bevor Sie das teamweit installieren, sollten Sie einen einzelnen Diff-Scan auf Ihrer eigenen Codebasis bepreisen. Dieser Hook kann jeden Commit um Minuten und Dollar verteuern.

Wo das Tool nicht weiterkommt

Das Threat Model, das die CLI für neun Zeilen erstellt hat, ist gute Arbeit. Es benennt alle vier Vertrauensgrenzen, führt das fehlende Modul ./db ausdrücklich als unbekannt auf und schreibt Express keine Schutzmechanismen zu, die sich nicht verifizieren lassen. Die Grenze formuliert es selbst klar: "Controls not present in the repository must not be assumed."

Das ist die strukturelle Einschränkung. Der Quellcode ist die einzige Eingabe. Alles, was erst beim Deployment festgelegt wird, bleibt damit unsichtbar: CORS-Policy, aktivierter Debug-Modus, schwaches TLS, fehlende Security Headers, Cache Poisoning und Autorisierung zwischen Services zur Laufzeit. Gerade Fehler bei der objektbezogenen Autorisierung lassen sich nur mit authentifizierten Requests zweier realer Identitäten bestätigen – das kann keine reine Quellcodeanalyse leisten.

Auch die Sprachabdeckung soll unterschiedlich tief sein. Ein Praxisbericht zum gehosteten Dienst sieht die stärkste Abdeckung bei Python, JavaScript, TypeScript, Go und Java; Ruby, PHP und Kotlin lägen dahinter. Getestet wurde hier ausschließlich JavaScript, daher ist diese Einschätzung nur aus zweiter Hand.

Lohnt sich der Einsatz?

Installieren Sie das Tool heute, wenn Sie das Threat Model wollen. Das war das einzige Artefakt, das jeder Lauf geliefert hat: ein Dokument mit 1.605 Wörtern, das Vertrauensgrenzen abbildet, Angreifer-Szenarien auflistet und für diesen konkreten Dienst definiert, was kritisch, hoch, mittel und niedrig bedeutet. Auch für andere Security-Tools kann es nützlicher Input sein, denn --knowledge-base akzeptiert eigene Architekturunterlagen und das erzeugte Modell lässt sich bearbeiten.

Warten Sie, wenn Sie planbare Ausgaben oder eine tatsächliche Liste von Findings benötigen. In fünf Konfigurationen gab es beides nicht – bei 1,46 bis 8,54 US-Dollar pro Lauf für ein Repository, das in zehn Sekunden gelesen ist. Die weiter hinten in der Pipeline dokumentierten Ausgaben findings.json, coverage.json und report.md wurden nie erreicht. Ob sich ein berechtigtes ChatGPT-Business-Konto anders verhält, bleibt eine offene Frage, die diese Tests nicht beantworten können.

Keiner der beiden offensichtlichen Kostenhebel funktionierte hier: Weder Diff-Scoping noch geringerer Reasoning-Aufwand durchbrachen dieselbe Grenze. Die Rechnung verändert dagegen die Modellrate, denn die Schätzung basiert auf Token-Mengen zum Listenpreis. Ein Endpoint zum halben Listenpreis halbiert somit die Kosten desselben Laufs. Planen Sie anhand gemessener Läufe statt anhand der Repository-Größe und setzen Sie das Limit unter Ihre tatsächliche Obergrenze – mindestens um die Größenordnung einer Worker-Runde. Die größte Überschreitung lag hier bei 46 % des Limits.

FAQ

Ist die Codex Security CLI kostenlos?

CLI und SDK stehen unter Apache-2.0 und kosten bei der Installation nichts. Scans sind jedoch nicht kostenlos. Sie verbrauchen GPT-5.6-Sol-Token über die verwendeten Zugangsdaten, und die CLI zeigt eine laufende Schätzung zu OpenAIs Listenpreisen an.

Brauche ich ChatGPT Business oder Enterprise?

Für die gehostete GitHub-Integration: ja. Dieser Weg ist auf Pro, Enterprise, Business und Edu beschränkt. Die CLI akzeptiert einen normalen OPENAI_API_KEY, doch die Dokumentation warnt, dass vollständige Repository-Scans weiterhin Trusted Access for Cyber erfordern können. Kein Tarif gewährt diesen Zugriff automatisch.

Läuft die CLI in CI?

Ja. Setzen Sie OPENAI_API_KEY, ergänzen Sie --fail-on-severity, damit Findings einen Exit-Code ungleich null auslösen, und legen Sie CODEX_SECURITY_STATE_DIR auf einen beschreibbaren Pfad außerhalb des Repositorys. Standardmäßig dienen Scans nur der Berichterstellung.

Funktioniert sie mit einem OpenAI-kompatiblen Endpoint eines Drittanbieters?

Ja, sofern der Endpoint die Responses API implementiert. Die Codex-Provider-Konfiguration muss über --codex-Flags überschrieben werden, denn allein das Setzen von OPENAI_API_KEY führt zu einem Authentifizierungsfehler.

Worin unterscheidet sich die CLI vom Codex Security Plugin?

Die Scan-Engine ist dieselbe, der Einstiegspunkt ein anderer. Das Plugin läuft in OpenAIs Infrastruktur gegen ein verbundenes GitHub-Repository. Die CLI läuft lokal gegen einen Pfad auf Ihrem Rechner, speichert die Scan-Historie in einem lokalen State-Verzeichnis und ergänzt Diff-begrenzte Scans, einen Pre-Commit-Hook, SARIF-Export und eine MCP-Registrierung.

Weiterführend: GPT-5.6 pricing guide · Codex auto mode