KI für Entwickler: Coding-Agenten, Kosten und sichere Übergaben

So geht's

1. 1Bevor du die Aufgabe übergibst, schreib den Check oder verweise darauf: den fehlschlagenden Test oder den Befehl und seine erwartete Ausgabe.
2. 2Gib dem Agenten die Aufgabe mit dem Prompt auf dieser Seite, einschließlich der Dateien, die er ändern darf, und derer, die er nicht ändern darf.
3. 3Lass ihn den Check selbst ausführen und die finale Ausgabe einfügen.
4. 4Prüfe den Diff wie den Pull Request eines Kollegen; ein bestandener Check beginnt das Review, er beendet es nicht.

Eingebaut

• ChatGPT · Codex
• Claude · Claude Code

Prompt zum Kopieren

Aufgabe: [Änderung].
Fertig heißt: [Test oder Befehl] läuft durch und gibt [erwartete Ausgabe] aus. Führ ihn aus, bevor du fertig bist, und füge das Ergebnis ein.
Du darfst ändern: [Pfade]. Nicht ändern: [Pfade], die Abhängigkeiten oder die Tests.
Wenn du ihn nicht zum Durchlaufen bringst, hör auf und erklär, warum, statt den Check zu umgehen.

Wo es schiefgeht

• Agenten bringen einen Test manchmal zum Bestehen, indem sie ihn abschwächen. Verbiete Änderungen an Tests und achte im Diff darauf.
• Eine Aufgabe, die für einen Check zu groß ist, ist für eine Übergabe zu groß. Teil sie auf.

So geht's

1. 1Nimm den, der dort läuft, wo dein Code liegt: Codex Cloud, den Copilot cloud agent auf GitHub oder Claude Code on the web.
2. 2Stell sicher, dass seine Umgebung deine Abhängigkeiten installieren und deine Tests ausführen kann; sonst rät der Agent.
3. 3Schick kleine, unabhängige Aufgaben, jede mit eigenem Check, wie in der Aufgabe oben.
4. 4Lass zuerst einen automatischen Reviewer jeden Pull Request lesen und prüfe ihn dann selbst.

Eingebaut

• Codex · Codex Cloud
• GitHub Copilot · Copilot cloud agent
• Claude Code · Claude Code on the web (cloud sessions)

Prompt zum Kopieren

In diesem Repository: [Aufgabe].
Kontext: [wo im Code, zugehöriges Issue].
Fertig, wenn: [Test oder Befehl] in deiner Umgebung durchläuft; füge die Ausgabe in die Beschreibung des Pull Requests ein.
Halte den Pull Request unter [n] geänderten Zeilen. Wenn mehr nötig ist, hör auf und schlag vor, wie er sich aufteilen lässt.

Wo es schiefgeht

• Tests, die Secrets oder Dienste brauchen, die du nicht eingerichtet hast, werden übersprungen oder schlagen fehl. Ein grüner Lauf ohne sie beweist wenig.
• Mehrere Agenten an zusammenhängendem Code erzeugen Pull Requests, die miteinander kollidieren. Halte parallele Aufgaben in getrennten Bereichen.

So geht's

1. 1Schreib deine Build-, Test- und Lint-Befehle in die Anweisungsdatei, die dein Agent zu Beginn jeder Session liest; welche Datei das ist, steht in der Dokumentation des jeweiligen Agenten.
2. 2Füge in Claude Code Hooks hinzu, die nach jeder Bearbeitung den Formatter und die Tests ausführen, damit der Agent Fehler sieht und behebt.
3. 3Lass einen Bot jeden Pull Request prüfen: Aktiviere „Automatic review“ in Codex oder fordere Copilot als Reviewer an.
4. 4Wenn der Agent einen Fehler zweimal macht, mach daraus einen Test oder eine Regel in der Anweisungsdatei.

Eingebaut

• Claude Code · Hooks
• Codex · Codex code review
• GitHub Copilot · Copilot code review

Prompt zum Kopieren

Lies dieses Repository und schreib die Anweisungsdatei für Coding-Agenten:
1. Die genauen Befehle zum Installieren, Bauen, Testen, Linten und Formatieren.
2. Der Projektaufbau in höchstens 10 Zeilen.
3. Konventionen, die Neulinge hier falsch machen, mit je einem Beispiel.
4. Was ein Agent hier nie tun darf, zum Beispiel Migrationen ändern oder generierte Dateien bearbeiten.
Liste nur Befehle auf, die du erfolgreich ausgeführt hast; markiere den Rest als „nicht verifiziert“.

Wo es schiefgeht

• Eine Anweisungsdatei mit Befehlen, die nicht mehr funktionieren, bringt dem Agenten bei, sie zu ignorieren. Führ die Befehle erneut aus, wenn sich das Setup ändert.
• Auch Review-Bots machen Fehler, und das mit voller Überzeugung. Behandle ihre Kommentare als Vorschläge.

So geht's

1. 1Notiere, was du am häufigsten in Chats einfügst, etwa Issues, Fehlerlogs, Dokumentation oder das Schema. Binde das zuerst an.
2. 2Füge für jede Quelle den offiziellen MCP-Server hinzu, mit einem Token, das nur lesen darf. In Gemini CLI kann eine Extension den MCP-Server und seine Einrichtung bündeln.
3. 3Gib dem Agenten eine Aufgabe, die diese Server braucht, und prüfe, ob er den richtigen aufgerufen hat.
4. 4Entferne alle paar Wochen die Server, die du nicht mehr nutzt.

Eingebaut

• Gemini CLI · Extensions

Prompt zum Kopieren

Bevor du irgendetwas änderst: Lies Issue [ID] im Tracker, finde den Fehler in den Logs und prüfe die Dokumentation zu [Bibliothek].
Sag, was dir jede Quelle gesagt hat und welche Datei du für fehlerhaft hältst.
Schreib in keines der verbundenen Tools.

Wo es schiefgeht

• Eine Webseite, ein Issue oder ein Dokument kann Text enthalten, der den Agenten steuern soll. Gib Tools, die Inhalte von außen lesen, keinen Schreibzugriff.
• Tokens in Konfigurationsdateien leaken. Nutze den Secret-Speicher des Clients oder Umgebungsvariablen, nie das Repository.

So geht's

1. 1Prüfe, wofür du schon bezahlst: ChatGPT-Tarife enthalten Codex, und die kostenpflichtigen Tarife von Claude enthalten Claude Code.
2. 2Notiere den Tokenverbrauch einiger typischer Sessions dort, wo dein Agent ihn anzeigt.
3. 3Berechne die Kosten dafür auf unserer API-Preisseite und vergleiche sie mit dem Abo.
4. 4Nutze für Automatisierung und CI API-Keys mit Ausgabenlimit, damit eine Schleife keine hohe Rechnung verursachen kann.

Eingebaut

• ChatGPT · Codex
• Claude · Claude Code

Prompt zum Kopieren

Hier ist meine Nutzung aus [n] typischen Sessions: [Input- und Output-Tokens]. Ich arbeite etwa [Tage] Tage pro Woche.
Schätze meine monatlichen Kosten bei Abrechnung pro Token zu diesen Preisen: [von der API-Preisseite einfügen].
Vergleiche sie mit einem Abo für [Preis] pro Monat. Zeig die Rechnung, damit ich sie prüfen kann.

Wo es schiefgeht

• Auch Abos haben Nutzungslimits. Stößt du mitten in einer Aufgabe an eines, kostet das Zeit; prüfe das Limit, nicht nur den Preis.
• Nichts beeinflusst die Rechnung so stark wie das Modell. Vergleiche mit dem Modell, das du tatsächlich nutzt.

So geht's

1. 1Führe /init im Repository aus: Der Befehl analysiert die Codebasis und schreibt eine erste CLAUDE.md oder schlägt Verbesserungen für deine bestehende vor.
2. 2Leg Teamregeln wie Build- und Testbefehle und Coding-Standards in ./CLAUDE.md ab und committe die Datei. Deine eigenen Vorlieben gehören in ~/.claude/CLAUDE.md für alle Projekte oder in CLAUDE.local.md für dieses eine.
3. 3Verweise auf längere Dokumente, statt sie einzufügen: @path/to/file importiert beim Start eine andere Datei.
4. 4Jedes Mal, wenn Claude dasselbe zweimal falsch macht, füge die eine Zeile hinzu, die es verhindert hätte.

Prompt zum Kopieren

Lies dieses Repository und verbessere CLAUDE.md. Bleib unter 60 Zeilen:
1. Die genauen Befehle zum Bauen, Testen und Linten.
2. Der Aufbau in wenigen Zeilen.
3. Konventionen, die ein Neuling hier falsch macht.
4. Dateien und Ordner, die nie bearbeitet werden dürfen.
Entferne alles, was nicht mehr stimmt. Markiere Befehle, die du nicht ausgeführt hast, als „nicht verifiziert“.

Wo es schiefgeht

• Alles in CLAUDE.md wird in jeder Session geladen und belegt Kontext. Lagere Details in Dateien aus, die sie importiert.
• Anweisungen, die nicht mehr stimmen, sind schlimmer als gar keine. Prüfe die Befehle erneut, wenn sich das Setup ändert.

Aus der offiziellen Dokumentation: Claude Code docs: How Claude remembers your project

So geht's

1. 1Drücke Shift+Tab, bis die Statusleiste „plan mode on“ anzeigt, oder beginne deinen Prompt mit /plan.
2. 2Beschreibe die Änderung und was sich nicht ändern darf. Claude kann weiterhin Befehle ausführen, um sich umzusehen, bearbeitet während der Planung aber keine Dateien.
3. 3Lies den Plan wie ein Designkonzept: eine falsche Datei, ein fehlender Fall, eine zu große Änderung. Fordere Änderungen an, bis er stimmt, und gib ihn dann frei.
4. 4Starte vor der nächsten, davon unabhängigen Aufgabe mit /clear neu.

Prompt zum Kopieren

/plan Ändere [was] so, dass [Ziel]. Randbedingungen: [was sich nicht ändern darf].
Liste die Dateien auf, die du anfassen wirst, die Reihenfolge der Änderungen, den Test, der jeden Schritt belegt, und alles, bei dem du unsicher bist. Bearbeite nichts, bevor ich zustimme.

Wo es schiefgeht

• Ein Plan, der mehr Dateien anfasst als erwartet, ist das Warnsignal. Frag nach dem Grund, bevor du ihn freigibst.
• Plan mode führt zur Erkundung trotzdem Befehle aus. Ein unbekanntes Repository lässt sich damit nicht gefahrlos ausführen.

Aus der offiziellen Dokumentation: Claude Code docs: Choose a permission mode · Claude Code docs: Commands · Claude Code docs: Best practices

So geht's

1. 1Öffne /permissions, um jede Regel zu sehen und aus welcher Einstellungsdatei sie stammt.
2. 2Leg die Regeln des Teams in .claude/settings.json ab und committe die Datei. Persönliche Regeln gehören in ~/.claude/settings.json oder .claude/settings.local.json.
3. 3Regeln werden zuerst auf deny, dann auf ask, dann auf allow geprüft, deshalb sticht eine einzige deny-Regel jede allow-Regel aus.
4. 4Wechsle die Modi mit Shift+Tab: acceptEdits genehmigt Dateiänderungen im Arbeitsverzeichnis. bypassPermissions schaltet Abfragen und Sicherheitsprüfungen ab; laut Dokumentation sollst du es nur in isolierten Containern oder VMs ohne Internetzugang verwenden.

Prompt zum Kopieren

Sieh dir die Befehle an, die du in dieser Session ausgeführt hast. Schlag Berechtigungsregeln für .claude/settings.json vor: Erlaube die rein lesenden Befehle und die Testbefehle, die wir täglich nutzen, verbiete alles, was Secrets liest oder außerhalb des Projekts löscht, und lass bei allem anderen nachfragen. Erkläre jede Regel in einer Zeile.

Wo es schiefgeht

• Eine allow-Regel, die auf jeden Befehl passt, ist dasselbe wie gar keine Abfragen. Erlaube exakte Befehle.
• Regeln in .claude/settings.json gelten nach dem Commit für das ganze Team. Prüfe sie wie Code.

Aus der offiziellen Dokumentation: Claude Code docs: Configure permissions · Claude Code docs: Settings files and precedence · Claude Code docs: Choose a permission mode

So geht's

1. 1Zwischen unabhängigen Aufgaben startet /clear ein neues Gespräch mit leerem Kontext.
2. 2Bei einer langen Aufgabe fasst /compact mit einem Schwerpunkt, zum Beispiel „/compact behalte den Plan und den fehlschlagenden Test“, das Bisherige zusammen.
3. 3Gib breite Suchen an einen Subagenten ab: Jeder läuft in seinem eigenen Kontextfenster, sodass nur seine Antwort in deine Session zurückkommt.
4. 4Claude Code komprimiert kurz vor dem Limit auch von selbst; wenn du selbst zu einem guten Zeitpunkt komprimierst, bleibt erhalten, was du auswählst.

Eingebaut

• Claude Code · Subagents

Prompt zum Kopieren

/compact Behalte: das Ziel, den Plan, die bisher geänderten Dateien und den Test, der noch fehlschlägt. Lass die Erkundung weg.

Wo es schiefgeht

• /clear vergisst das Gespräch. Alles, was du wieder brauchst, gehört vorher in CLAUDE.md.
• Von einem Subagenten bekommst du nur seine Antwort zurück. Frag ihn nach Dateipfaden und Zeilennummern, nicht nur nach Schlussfolgerungen.

Aus der offiziellen Dokumentation: Claude Code docs: Commands · Claude Code docs: Best practices · Claude Code docs: Create custom subagents

So geht's

1. 1Starte jede Session mit claude --worktree <name> (oder -w). Das legt einen Git-Worktree unter .claude/worktrees/<name>/ auf dem Branch worktree-<name> an.
2. 2Füge .claude/worktrees/ zu .gitignore hinzu, wie die Dokumentation empfiehlt.
3. 3Gib jeder Session eine Aufgabe mit eigener Prüfung, damit du sie einzeln durchsehen kannst.
4. 4Prüfe und merge jeden Branch wie jeden anderen Pull Request.

Prompt zum Kopieren

Du arbeitest in einem Worktree auf dem Branch worktree-[Name]. Aufgabe: [eine Änderung]. Fertig, wenn: [Test oder Befehl] durchläuft. Committe nur auf diesem Branch; merge oder rebase keine anderen Branches.

Wo es schiefgeht

• Jeder Worktree ist ein eigener Ordner, Abhängigkeiten und Build-Ausgaben werden also nicht geteilt. Installiere sie in jedem.
• Zwei Aufgaben, die dieselben Dateien anfassen, kollidieren beim Mergen trotzdem, ob mit Worktree oder ohne.

Aus der offiziellen Dokumentation: Claude Code docs: Run parallel sessions with worktrees

So geht's

1. 1Drücke bei leerer Eingabe zweimal Esc oder tippe /rewind (/checkpoint und /undo funktionieren auch).
2. 2Wähle den Punkt, bevor es schiefging, und stelle das Gespräch, den Code oder beides wieder her.
3. 3Kenne die Grenzen: Dateien, die Shell-Befehle wie rm, mv oder cp geändert haben, werden nicht wiederhergestellt, ebenso wenig Änderungen außerhalb von Claude Code oder in einer anderen Session.
4. 4Committe vor riskanten Schritten. Checkpoints dienen der schnellen Wiederherstellung innerhalb einer Session und ersetzen git nicht.

Prompt zum Kopieren

Bevor du anfängst, committe den aktuellen Stand mit der Nachricht „Checkpoint vor [Aufgabe]“. Dann [Aufgabe]. Frag mich vor jedem Befehl, der Dateien löscht oder verschiebt.

Wo es schiefgeht

• Rewind holt keine Datei zurück, die ein Befehl gelöscht hat. Das kann nur git.
• Änderungen, die du zwischendurch von Hand gemacht hast, werden ebenfalls nicht erfasst. Committe sie vor dem Rewind.

Aus der offiziellen Dokumentation: Claude Code docs: Checkpointing · Claude Code docs: Commands

So geht's

1. 1claude -p "..." läuft nicht interaktiv. --output-format json oder stream-json liefert eine Ausgabe, die ein Skript parsen kann.
2. 2Der Befehl endet bei Erfolg mit 0, bei einem Fehler mit einem Wert ungleich 0, sodass CI danach verzweigen kann.
3. 3Füge in CI --bare hinzu, damit Läufe nicht vom lokalen Setup abhängen.
4. 4Für Pull Requests richtet /install-github-app Claude Code GitHub Actions ein (nur für Repositories auf github.com); erwähne danach @claude in einem Kommentar in einem Pull Request oder Issue.

Prompt zum Kopieren

claude -p "Lies den Diff gegen main. Liste jede Änderung, die eine Abhängigkeit hinzufügt, die Authentifizierung berührt oder eine Datenbankmigration ändert, als JSON auf: {\"files\": [], \"reason\": \"\"}. Gib eine leere Liste zurück, wenn es keine gibt." --output-format json

Wo es schiefgeht

• Ein Skript läuft mit den Rechten, die du ihm gibst. Gib CI nur das Nötigste.
• /install-github-app funktioniert nur mit Repositories auf github.com.

Aus der offiziellen Dokumentation: Claude Code docs: Run Claude Code programmatically · Claude Code docs: GitHub Actions

So geht's

1. 1Führe /init in der CLI aus, um eine erste AGENTS.md im aktuellen Ordner anzulegen.
2. 2Leg persönliche Vorgaben in ~/.codex/AGENTS.md ab und Projektregeln im Repository. Ein Unterordner kann eine eigene Datei haben; Dateien näher an dem Ort, an dem Codex arbeitet, haben Vorrang.
3. 3Halte die Dateien kurz: Ihre Gesamtgröße ist begrenzt, standardmäßig auf 32 KiB.
4. 4Füge einen Abschnitt „## Code Review Rules“ hinzu: Die Reviews von Codex auf GitHub richten sich danach.

Prompt zum Kopieren

Lies dieses Repository und schreib AGENTS.md:
1. Die genauen Befehle zum Installieren, Bauen, Testen und Linten.
2. Der Aufbau in wenigen Zeilen.
3. Konventionen, die ein Neuling hier falsch macht.
4. Ein Abschnitt „## Code Review Rules“ mit dem, was ein Reviewer immer anmerken muss.
Liste nur Befehle auf, die du erfolgreich ausgeführt hast; markiere den Rest als „nicht verifiziert“.

Wo es schiefgeht

• Lange Dateien arbeiten gegen dich: Die Gesamtgröße ist standardmäßig auf 32 KiB begrenzt.
• Eine Datei im Unterordner, die der Datei im Stammverzeichnis widerspricht, ohne das zu sagen, verwirrt Menschen genauso wie Codex. Schreib dazu, was sie überschreibt.

Aus der offiziellen Dokumentation: Codex docs: AGENTS.md · Codex docs: CLI commands · Codex docs: GitHub integration

So geht's

1. 1In der CLI wechselt /permissions den Modus, und /status zeigt die geltende Freigaberichtlinie und die beschreibbaren Ordner.
2. 2„Ask for approval“, die empfohlene Standardeinstellung, bearbeitet Dateien und führt Befehle aus, solange es innerhalb des Arbeitsbereichs bleibt, und pausiert vor allem, was darüber hinausgeht.
3. 3„Approve for me“ behält dieselbe Sandbox bei, schickt Freigabeanfragen aber an eine automatische Prüfung statt an dich.
4. 4„Full access“ hebt die Grenzen für Dateisystem und Netzwerk auf. Die Dokumentation fügt einen Warnhinweis hinzu; reserviere den Modus für Umgebungen, die du wegwerfen kannst.

Prompt zum Kopieren

Bevor du anfängst, führe /status aus und nenne mir die Freigaberichtlinie und die beschreibbaren Ordner. Dann [Aufgabe]. Frag nach, bevor du einen Befehl ausführst, der das Netzwerk braucht oder außerhalb dieses Repositorys schreibt.

Wo es schiefgeht

• Bei „Approve for me“ liest kein Mensch die einzelnen Anfragen. Nutze den Modus dort, wo sich eine falsche Aktion mit wenig Aufwand rückgängig machen lässt.
• „Full access“ gilt für den ganzen Rechner, nicht nur für das Repository.

Aus der offiziellen Dokumentation: Codex docs: Permission modes · Codex docs: Sandboxing · Codex docs: Approvals and security · Codex docs: CLI commands

So geht's

1. 1codex exec "..." läuft nicht interaktiv und nutzt standardmäßig eine Sandbox mit reinem Lesezugriff.
2. 2Füge --sandbox workspace-write hinzu, wenn Dateien bearbeitet werden müssen; --full-auto ist veraltet.
3. 3--json gibt einen JSON-Lines-Stream mit Events aus, für Skripte, die jeden Schritt brauchen.
4. 4In GitHub Actions führt openai/codex-action@v1 codex exec für dich aus.

Prompt zum Kopieren

codex exec "Lies die Änderungen seit dem Tag [v1.2.0]. Schreib Release Notes, gruppiert nach Neu, Geändert und Behoben: eine Zeile pro Änderung, in Worten, die Nutzer verstehen, keine Commit-Hashes."

Wo es schiefgeht

• Ältere Anleitungen verwenden noch --full-auto. Das ist veraltet; nutze --sandbox workspace-write.
• Ein Job, der nur liest, sollte nur Lesezugriff haben, auch in CI.

Aus der offiziellen Dokumentation: Codex docs: Non-interactive mode · Codex docs: GitHub Action

So geht's

1. 1/review in der CLI prüft deinen Working Tree. codex review macht dasselbe ohne Chat, gegen einen Basis-Branch, einen Commit oder nicht committete Änderungen.
2. 2Kommentiere auf GitHub @codex review in einem Pull Request.
3. 3Aktiviere automatische Reviews unter „Personal preferences“ in den Codex-Einstellungen; dann ist kein Kommentar nötig.
4. 4Schreib die Regeln deines Teams in einen Abschnitt „## Code Review Rules“ in AGENTS.md.

Eingebaut

• Codex · Codex code review

Prompt zum Kopieren

## Code Review Rules
- Markiere jede Änderung an Authentifizierung oder Berechtigungen.
- Markiere Datenbankmigrationen ohne Rückweg.
- Markiere neue Abhängigkeiten und sag, ob sie nötig sind.
- Ignoriere die Formatierung; darum kümmert sich der Linter.

Wo es schiefgeht

• Reviews auf GitHub markieren nur Probleme der Stufen P0 und P1. Kein Kommentar heißt nicht, dass das Design stimmt.
• Ein Review ist eine zweite Meinung, kein Testlauf. Behalte die Tests bei.

Aus der offiziellen Dokumentation: Codex docs: CLI commands · Codex docs: GitHub integration

So geht's

1. 1Leg eine Umgebung mit den Repositories, Abhängigkeiten, Tools und Zugriffseinstellungen an, die die Aufgaben brauchen. Neue Umgebungen zeichnen ein Installationsskript und einen Start-Skill auf.
2. 2Leg den Internetzugang pro Umgebung fest: nur Paketmanager, ausgewählte Domains oder alles.
3. 3Starte Aufgaben aus ChatGPT, für längere Jobs aus der IDE-Erweiterung oder aus dem Terminal mit codex cloud exec; --attempts 1-4 fordert mehrere Versuche zum Vergleichen an.
4. 4Code Review und die Integrationen für GitHub und Linear laufen noch auf dem älteren Codex Cloud (Legacy), das OpenAI einstellen will.

Eingebaut

• Codex · Codex Cloud

Prompt zum Kopieren

codex cloud exec --attempts 3 "Aufgabe: [Änderung]. Kontext: [Dateien]. Fertig, wenn [Test] in dieser Umgebung durchläuft. Halte den Diff unter [n] Zeilen."

Wo es schiefgeht

• Mit uneingeschränktem Internet erreicht eine Aufgabe jede Seite, auch Seiten, die geschrieben wurden, um die Aufgabe zu steuern. Erlaube nur, was der Job braucht.
• Fehlt das Installationsskript, sind die Tests vielleicht nicht gelaufen. Prüfe, ob eine Aufgabe sie wirklich ausgeführt hat.

Aus der offiziellen Dokumentation: Codex docs: Cloud environments · Codex docs: CLI commands · Codex docs: IDE extension

So geht's

1. 1Leg das Standardmodell und den Reasoning-Aufwand in ~/.codex/config.toml fest (model und model_reasoning_effort). Die CLI und die IDE-Erweiterung nutzen die Datei gemeinsam.
2. 2Leg ein Profil als eigene Datei an, ~/.codex/<name>.config.toml, und starte mit --profile <name>.
3. 3Füge MCP-Server mit codex mcp add <name> -- <command> hinzu; jeder wird zu einer Tabelle [mcp_servers.<name>], und /mcp listet die aktiven auf.
4. 4/status zeigt, was gerade gilt, und codex resume --last setzt die letzte Session in diesem Ordner fort.

Prompt zum Kopieren

Lies ~/.codex/config.toml und die .codex/config.toml dieses Projekts. Nenne mir das geltende Modell, den Reasoning-Aufwand, die Sandbox und die MCP-Server, aus welcher Datei jeweils was stammt, und alles, was sich widerspricht.

Wo es schiefgeht

• Projekteinstellungen werden nur in vertrauenswürdigen Projekten geladen. Wenn eine ignoriert zu werden scheint, prüfe das zuerst.
• Profile sind jetzt eigene Dateien. Anleitungen, die [profiles.name] in config.toml ablegen, sind veraltet.

Aus der offiziellen Dokumentation: Codex docs: MCP · Codex docs: Config basics · Codex docs: Advanced config · Codex docs: CLI commands