Codex untrusted Approval Policy abgeschafft: Was zu tun ist

Codex CLI v0.149.0 (stabil, 20. August 2026) hat die Approval Policy untrusted mit PR #39630, “Retire the untrusted approval policy” (die untrusted Approval Policy abschaffen), abgeschafft.¹ Der PR entfernt untrusted “from the CLI, configuration schema, and MCP tool interface” (aus CLI, Konfigurationsschema und MCP-Tool-Schnittstelle), und ein explizites approval_policy = "untrusted" schlägt jetzt “with an actionable error” (mit einem umsetzbaren Fehler) fehl.⁴ Reproduziert auf 0.149.1 am 25. August 2026: Der Sitzungsstart bricht mit Error: approval_policy = "untrusted" is no longer supported; remove this setting ab, egal ob der Wert in config.toml, in einer Profildatei oder in einem -c-Override steht, und die codex-Binary weist -a untrusted bereits beim Parsen der Argumente zurück.⁵ Ändern Sie den Wert auf on-request und lassen Sie den Sandbox-Modus unverändert; für die vorsichtigste Konfiguration kombinieren Sie --sandbox read-only mit on-request.³ Die aktuelle Menge an Policies besteht aus on-request, never und der granularen Tabellenform.² Stand v0.149.1 (24. August 2026, UTC), dem npm-latest.¹ {.answer-block}

TL;DR

• Die Änderung: Der vollständige Changelog von v0.149.0 führt PR #39630 auf, “Retire the untrusted approval policy”. Die Release Notes liefern über diesen Titel hinaus keinen Migrationstext;¹ die PR-Beschreibung schon: untrusted ist aus CLI, Konfigurationsschema und MCP-Tool-Schnittstelle verschwunden, und explizite Einstellungen “now fail with an actionable error” (schlagen jetzt mit einem umsetzbaren Fehler fehl).⁴
• Wer handeln muss: alle mit approval_policy = "untrusted" in ~/.codex/config.toml oder einem Profil sowie alle, die --ask-for-approval untrusted (oder -a untrusted) in Skripten, Aliassen oder CI übergeben.
• Der Ersatz: on-request, bei unverändertem Sandbox-Modus. read-only plus on-request ist das Paar, das die Dokumentation als “Safe read-only browsing” führt.² Die alte Kombination workspace-write plus untrusted hat keinen direkten Nachfolger; Rückfragen pro Befehl leben jetzt in Exec-Policy-Regeln.⁴⁸
• Die aktuelle Menge: on-request, never oder approval_policy = { granular = { ... } } für die Steuerung pro Kategorie. Die Sandbox-Modi bleiben read-only, workspace-write und danger-full-access.²
• Fail-fast statt stillschweigend: Ein übrig gebliebenes approval_policy = "untrusted" stoppt die Sitzung mit Error: approval_policy = "untrusted" is no longer supported; remove this setting, in config.toml, in einer Profildatei oder in einem -c-Override. codex doctor meldet nur, dass die Konfiguration nicht geladen werden konnte, ohne den Schlüssel zu nennen.⁵

Was hat Codex 0.149 geändert?

Die Schlagzeilen gehören neuen Oberflächen, darunter dem codex agents-Dashboard, codex queue und einem erweiterten codex doctor; die Änderung an der Approval Policy steht weiter unten, im vollständigen Changelog.¹ Die Beschreibung von PR #39630 enthält das Detail, das die Release Notes auslassen. Zwei ihrer drei Punkte sind hier relevant: “Remove untrusted from the CLI, configuration schema, and MCP tool interface. Explicit approval_policy = "untrusted" settings now fail with an actionable error.” und “Remove the known-safe command allowlist. Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.” (Die Allowlist bekannt sicherer Befehle entfällt; als untrusted markierte Projekte fordern jetzt für jeden Befehl eine Genehmigung an, sofern keine explizite Exec-Policy-Regel ihn erlaubt.)⁴ Ein Bugfix im selben Release betrifft dieselben Leser: “Resumed and forked threads now restore their active permission profile instead of silently falling back to current defaults.” (Fortgesetzte und geforkte Threads stellen jetzt ihr aktives Berechtigungsprofil wieder her, statt stillschweigend auf die aktuellen Standardwerte zurückzufallen.)¹

Jede Zeile zitiert die Release Notes von v0.149.0.¹

Wer muss überhaupt etwas bearbeiten?

Vier Stellen tragen den Wert. Finden Sie zuerst alle, denn ein Profil oder ein Shell-Alias setzt die alte Policy wieder durch, nachdem Sie die Hauptdatei korrigiert haben.

Der Fehler bei der veralteten Tabelle ist laut. Auf 0.149.1 stoppt codex exec --profile safe "hi" mit einer noch in config.toml vorhandenen [profiles.safe]-Tabelle mit Error loading config.toml: --profile `safe` cannot be used while .../config.toml contains legacy `profile = "safe"` or `[profiles.safe]` config; move those settings into .../safe.config.toml ..., sodass das --profile safe eines Teamkollegen scheitert, bevor Codex den Approval-Wert überhaupt liest.⁵

Ein grep pro Seite:

# Config and profiles: match the key, not the bare word
grep -rnE 'approval_policy\s*=\s*"untrusted"' ~/.codex/*.toml .codex/config.toml 2>/dev/null

# Scripts, aliases, CI
grep -rn --exclude-dir=node_modules \
  -e "ask-for-approval untrusted" -e "ask-for-approval=untrusted" \
  -e "-a untrusted" -e "approval_policy=untrusted" \
  ~/.zshrc ~/.bashrc . 2>/dev/null

# CI directories: read every bare hit, because YAML can split a flag from its value
grep -rn --exclude-dir=node_modules "untrusted" .github .gitlab-ci.yml .circleci 2>/dev/null

Der erste grep sucht aus gutem Grund nach dem Schlüssel statt nach dem bloßen Wort. trust_level = "untrusted" ist eine andere Einstellung; lassen Sie sie stehen. Die Konfigurationsreferenz definiert projects.<path>.trust_level als den Schlüssel, der “a project or worktree as trusted or untrusted” (ein Projekt oder Worktree als vertrauenswürdig oder nicht vertrauenswürdig) markiert, und nicht vertrauenswürdige Projekte “skip project-scoped .codex/ layers, including project-local config, hooks, and rules” (überspringen projektbezogene .codex/-Ebenen, einschließlich projektlokaler Konfiguration, Hooks und Regeln).⁷ PR #39630 ändert, was ein untrusted Projekt mit Befehlen macht, nicht den Schlüssel: “Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.”⁴ Ein blindes Suchen-und-Ersetzen von untrusted beschädigt diesen Schlüssel.

Profildateien sind der dokumentierte Preset-Mechanismus (~/.codex/<name>.config.toml, ausgewählt mit codex --profile <name>), daher kann das Profil eines Teamkollegen den abgeschafften Wert wieder einführen, ganz gleich, was die Hauptkonfiguration sagt.²

Wie sieht die aktuelle Menge an Approval Policies aus?

Die Sicherheit von Codex entsteht aus zwei Ebenen: Der Sandbox-Modus entscheidet, was Codex technisch tun kann, und die Approval Policy entscheidet, wann Codex anhalten und fragen muss.² Die Abschaffung berührt nur die zweite.

Die granulare Form deckt fünf Rückfrage-Kategorien ab: sandbox_approval, rules (Execpolicy-Rückfragen), mcp_elicitations, request_permissions und skill_approval.² Keine davon bildet untrusted nach, das eine Regel zur Befehlsklassifizierung war (bekannt sichere Lesezugriffe automatisch ausführen, bei allem nachfragen, was den Zustand verändern könnte) und kein Filter über Rückfrage-Kategorien.²

workspace-write plus untrusted, in der Dokumentation die Zeile “Automatically edit but ask for approval to run untrusted commands” (automatisch bearbeiten, aber vor dem Ausführen nicht vertrauenswürdiger Befehle um Genehmigung bitten), hat keinen direkten Nachfolger.² workspace-write plus on-request fragt nicht mehr vor Befehlen, die innerhalb der Sandbox laufen; read-only plus on-request fragt sowohl vor Bearbeitungen als auch vor Befehlen.² PR #39630 hat “the known-safe command allowlist” entfernt und benennt den verbleibenden Mechanismus für Rückfragen pro Befehl: “Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.”⁴ Exec-Policy-Regeln sind derselbe Mechanismus hinter der Kategorie rules der granularen Tabelle, den “execpolicy-rule prompts”, die die Approvals-Seite aufführt.² Sicherheitsverantwortliche, die sich bei einem beschreibbaren Workspace auf untrusted verlassen haben, sollten diese Regeln aufbauen. Die Rules-Dokumentation beschränkt sie auf Befehle, die außerhalb der Sandbox laufen; eine prefix_rule mit decision = "prompt" fragt “before each matching invocation” (vor jedem passenden Aufruf):⁸

# ~/.codex/rules/default.rules
prefix_rule(pattern = ["git", "push"], decision = "prompt")

Die Read-only-Sandbox bleibt die grobe Alternative, die Änderungen von vornherein blockiert.³

Wie lauten die genauen Änderungen?

Die Zuordnung ist eine Zeile lang: Aus untrusted wird on-request, und der Sandbox-Modus bleibt, was er war.³

Hauptkonfiguration (eine Profildatei erhält dieselbe Änderung):

# ~/.codex/config.toml (before)
approval_policy = "untrusted"
sandbox_mode    = "read-only"

# ~/.codex/config.toml (after)
approval_policy = "on-request"
sandbox_mode    = "read-only"

Ein Skript:

# before
codex --sandbox workspace-write --ask-for-approval untrusted "$@"

# after
codex --sandbox workspace-write --ask-for-approval on-request "$@"

Das Paar -a/--ask-for-approval gehört zur codex-TUI-Binary. codex exec kennt kein solches Flag: Auf 0.149.1 scheitert codex exec --ask-for-approval untrusted "hi" mit error: unexpected argument '--ask-for-approval' found.⁵ Für codex exec setzen Sie die Policy in der Konfiguration oder übergeben sie inline:

# non-interactive run, policy set inline
codex exec --sandbox workspace-write -c approval_policy=never "$@"

Zwei Ermessensfragen folgen. Erstens: Wo niemand eine Rückfrage beantworten kann, bleibt die interaktive codex-Binary unter on-request bei der ersten Genehmigung hängen; das dokumentierte nicht interaktive Paar ist --sandbox read-only --ask-for-approval never, und codex exec --sandbox workspace-write ist der dokumentierte nicht interaktive Einstiegspunkt.² Zweitens: Wenn Sie untrusted mit danger-full-access für “volle Macht, aber jedes Mal fragen” kombiniert hatten, überlebt diese Eigenschaft den Tausch nicht. Die beiden Beispiele der Dokumentation für eine on-request-Rückfrage sind das Verlassen der Sandbox und der Netzwerkzugriff, und danger-full-access entfernt beide Auslöser.² Rückfragen aus den anderen vier Kategorien der granularen Tabelle feuern unter vollem Zugriff weiterhin: Exec-Policy-Regeln mit decision = "prompt", MCP-Elicitations, Skill-Genehmigungen und request_permissions-Rückfragen.²⁸ Die optionale Einstellung approvals_reviewer = "auto_review" leitet geeignete Rückfragen durch einen Reviewer-Agenten; sie gilt nur für interaktive Policies und bleibt daher nach der Migration verfügbar.²

Wie prüfe ich, dass die Änderung gegriffen hat?

1. Führen Sie codex doctor aus. Mit dem abgeschafften Wert noch in der Konfiguration beginnt seine Config-Zeile mit ✗ config config could not be loaded, und die Detailzeile lautet · failed to load Codex config; doctor nennt den störenden Schlüssel nicht. Der benannte Fehler kommt beim Start von codex oder codex exec. Eine saubere doctor-Zeile bedeutet, dass der Wert weg ist; eine fehlgeschlagene bedeutet, dass Sie trotzdem eine Sitzung starten müssen, um zu sehen, welcher Schlüssel es ist.⁵ Der Startfehler ist identisch, ob der Wert in config.toml, in einer mit --profile ausgewählten Profildatei oder in einem -c approval_policy=untrusted-Override steht.⁵ Die Flag-Form scheitert früher, beim Parsen der Argumente: codex -a untrusted --version gibt error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>' aus, gefolgt von [possible values: on-request, never].⁵
2. Starten Sie eine Wegwerf-Sitzung in einem Scratch-Verzeichnis und führen Sie /status aus. Die Zeile Permissions zeigt die aktive Policy, und on-request erscheint dort als “Ask for approval”.⁵ /permissions öffnet das Preset-Menü, statt den aktiven Modus zu melden; lesen Sie stattdessen /status.⁵ /status listet außerdem die Workspace-Verzeichnisse auf.²
3. Setzen Sie einen älteren Thread fort. PR #39153, “Restore permission profiles when resuming threads”, stellt jetzt “the latest persisted approval policy, approvals reviewer, and active permission-profile ID when resuming or forking a thread” (die zuletzt gespeicherte Approval Policy, den Approvals Reviewer und die aktive Permission-Profile-ID beim Fortsetzen oder Forken eines Threads) wieder her.⁶ Ein fortgesetzter Thread, dessen gespeicherte Policy untrusted ist, bleibt ungetestet; behandeln Sie diesen Fall als unbekannt, bis Sie einen öffnen.

Ein Vorbehalt zur Dokumentation selbst. Die offizielle Seite “Agent approvals & security”, erfasst am 24. August und erneut geprüft am 25. August 2026, zeigt in ihrer Kombinationstabelle weiterhin --ask-for-approval untrusted, enthält weiterhin den Absatz, der mit “With --ask-for-approval untrusted, Codex runs only known-safe read operations automatically” beginnt, und verwendet in ihrem config.toml-Beispiel weiterhin approval_policy = "untrusted".² Der Eintrag approval_policy der Konfigurationsreferenz führt untrusted als Erstes in seiner Typ-Union auf, während seine Beschreibung einen anderen Wert als veraltet markiert: “on-failure is deprecated; use on-request for interactive runs or never for non-interactive runs.”⁷ Der PR und die Binary sind die maßgebliche Quelle; die Docs hinken hinterher. Kopieren Sie den Beispielblock der Dokumentation nicht ohne Tausch des Werts in eine frische 0.149-Installation.

FAQ

Was ersetzt approval_policy = "untrusted" in Codex?

approval_policy = "on-request", bei unverändertem sandbox_mode. Für die vorsichtigste Kombination setzen Sie daneben sandbox_mode = "read-only".³

Welche Codex-Version hat die untrusted Policy abgeschafft?

v0.149.0, stabil seit dem 20. August 2026, über PR #39630 im vollständigen Changelog. v0.149.1 (24. August 2026, UTC) ist das aktuelle npm-latest.¹

Was passiert, wenn ich untrusted in config.toml stehen lasse?

Codex verweigert den Start der Sitzung. Auf 0.149.1 stoppt codex exec mit Error: approval_policy = "untrusted" is no longer supported; remove this setting, derselbe Fehler erscheint für eine Profildatei und für -c approval_policy=untrusted, und codex doctor meldet nur, dass die Konfiguration nicht geladen werden konnte.⁵ PR #39630 beschreibt das Verhalten als Fehlschlagen “with an actionable error”.⁴

Ist on-request weniger sicher, als untrusted es war?

Innerhalb von workspace-write ja: untrusted fragte vor jedem Befehl, der den Zustand verändern konnte, und on-request führt Befehle in der Sandbox ohne Rückfrage aus.² Die Sandbox-Ebene holt einen Teil des Spielraums zurück: read-only blockiert Schreibzugriffe unabhängig von der Policy, und on-request fragt weiterhin vor jeder Eskalation.³ Für Rückfragen pro Befehl in einem beschreibbaren Workspace schreiben Sie Exec-Policy-Regeln, den Mechanismus, den PR #39630 benennt.⁴⁸

Muss ich auch meinen Sandbox-Modus ändern?

Nein. Die Abschaffung betrifft nur die Approval Policy; behalten Sie read-only, workspace-write oder danger-full-access so bei, wie Sie es hatten.³

Wichtigste Erkenntnisse

Für einzelne Entwickler: - Durchsuchen Sie ~/.codex/*.toml per grep nach approval_policy = "untrusted" (nicht nach dem bloßen Wort), ersetzen Sie jeden Treffer durch on-request und lassen Sie sandbox_mode und jedes trust_level = "untrusted" unangetastet. - Führen Sie codex doctor aus, dann /status in einer Scratch-Sitzung, und setzen Sie einen alten Thread fort, um zu sehen, was 0.149 wiederherstellt.

Für Teams, die gemeinsame Profile und Skripte pflegen: - Korrigieren Sie Profildateien und Inline-Overrides im selben Commit wie config.toml; eine veraltete [profiles.<name>]-Tabelle blockiert --profile vollständig, bis Sie sie nach ~/.codex/<name>.config.toml verschieben.⁵ - Stellen Sie unbeaufsichtigte Jobs auf --sandbox read-only --ask-for-approval never bei der codex-Binary um oder auf codex exec --sandbox workspace-write -c approval_policy=never; die interaktive codex-Binary unter on-request bleibt an einer Rückfrage hängen, die niemand beantwortet, und codex exec hat kein --ask-for-approval-Flag.⁵

Für Sicherheitsverantwortliche: - Der untrusted-Klassifikator (sichere Lesezugriffe automatisch ausführen, bei Änderungen nachfragen) hat kein granulares Gegenstück; PR #39630 verweist für Rückfragen pro Befehl auf Exec-Policy-Regeln (“unless an explicit exec policy rule allows it”),⁴ geschrieben als prefix_rule mit decision = "prompt" in ~/.codex/rules/default.rules,⁸ und die Read-only-Sandbox blockiert Änderungen von vornherein. - Erwägen Sie approvals_reviewer = "auto_review", wo ein Reviewer-Agent bei geeigneten Rückfragen einen Menschen vertreten kann.

Referenzen