Berechtigungen

Mit Berechtigungsprofilen kannst du Zugriffsgrenzen nach dem Prinzip der geringsten Rechte für lokale Befehle festlegen, die Codex in deinem Auftrag ausführt. Ein Profil ist eine benannte Richtlinie, die Dateisystemregeln mit Netzwerkregeln kombiniert. Die Dateisystemregeln bestimmen, was Befehle lesen oder schreiben dürfen; die Netzwerkregeln legen fest, welche Ziele Befehle erreichen dürfen.

Verwende Profile, damit Codex im aktuellen Chat die nötigen Zugriffsrechte erhält, ohne ihm weitreichenden Zugriff auf deinen Computer oder dein Netzwerk zu gewähren. Ein Profil ohne Schreibzugriff kann Codex beispielsweise ein Projekt prüfen lassen, ohne es zu bearbeiten. Ein Profil mit Schreibzugriff kann Änderungen auf ausgewählte Workspace-Stammverzeichnisse beschränken.

Lokale Berechtigungsprofile werden unter macOS, Linux, WSL und nativem Windows unterstützt. Unter Geltungsbereich und Durchsetzung findest du plattformspezifische Details und Einschränkungen.

Informationen zu den Netzwerkeinstellungen für Codex Cloud findest du unter Internetzugang.

Profil definieren und auswählen

Codex enthält drei integrierte Berechtigungsprofile:

• :read-only beschränkt die lokale Befehlsausführung auf Vorgänge ohne Schreibzugriff.
• :workspace erlaubt Schreibzugriffe innerhalb der aktiven Workspace-Stammverzeichnisse und der temporären Systemverzeichnisse.
• :danger-full-access hebt lokale Sandbox-Einschränkungen auf und sollte nur verwendet werden, wenn dieser weitreichende Zugriff beabsichtigt ist.

Erstelle unter [permissions.<name>] ein benanntes Profil. Lege anschließend den Profilnamen oder einen der oben genannten integrierten Werte für den Schlüssel default_permissions auf oberster Ebene fest. In diesem Beispiel ist project-edit ein benutzerdefinierter Profilname und kein integrierter Wert.

Administrierende in Unternehmen können Profile definieren und einschränken, welche Profile über die verwaltete Datei requirements.toml ausgewählt werden dürfen. Sobald allowed_permission_profiles vorhanden ist, sind nicht aufgeführte Profile unzulässig. Das gilt auch für nicht aufgeführte integrierte Profile und Profile, die in künftigen Codex-Versionen hinzukommen. Unter Verfügbare Berechtigungsprofile steuern findest du die empfohlene verwaltete Konfiguration.

Benutzerdefinierte Profile verwenden zwei miteinander verbundene Konzepte:

• [permissions.<name>.workspace_roots] fügt konkrete Verzeichnisse hinzu, die für dieses Profil als Workspace-Stammverzeichnisse gelten sollen.
• [permissions.<name>.filesystem.":workspace_roots"] definiert die Dateisystemregeln, die Codex in jedem maßgeblichen Workspace-Stammverzeichnis anwendet. Dazu gehören die zur Laufzeit ermittelten Workspace-Stammverzeichnisse der aktuellen Sitzung und die oben für das Profil definierten Stammverzeichnisse.

Profile verwenden außerdem das übliche Modell der Konfigurationsebenen. Ebenen mit höherer Priorität können unter demselben Profilnamen Einträge hinzufügen oder ersetzen, ohne das gesamte Profil erneut anzugeben.

So können beispielsweise eine Konfiguration auf Organisationsebene und eine Konfiguration auf Nutzerebene dasselbe Profil unabhängig voneinander erweitern:

# /etc/codex/config.toml
[permissions.server.workspace_roots]
"~/code/server" = true

# ~/.codex/config.toml
[permissions.server.workspace_roots]
"~/code/mobile-app" = true

Wenn server aktiv ist, fließen beide Workspace-Stammverzeichnisse in das resultierende Profil ein.

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = true

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"
"objects.githubusercontent.com" = "allow"
"*.github.com" = "allow"
"tracking.example.com" = "deny"

Dieses Profil:

• Gewährt Lesezugriff auf die mindestens erforderlichen Laufzeitpfade für gängige Entwicklungstools.
• Wendet dieselben Regeln für Workspace-Stammverzeichnisse auf die aktuelle Sitzung und die für das Profil definierten Stammverzeichnisse an.
• Verhindert Schreibzugriffe auf IDE-bezogene Einstellungen wie .devcontainer/ in jedem Stammverzeichnis.
• Verweigert mithilfe einer Glob-Regel den Zugriff auf passende Umgebungsdateien.
• Erlaubt Netzwerkzugriff nur gemäß der konfigurierten Domainrichtlinie.

In einem aktiven Profil bleiben spezifischere Verweigerungsregeln in Kraft, auch wenn für einen allgemeineren Pfad Lese- oder Schreibzugriff erlaubt ist. Ein Profil kann beispielsweise Schreibzugriff auf Workspace-Stammverzeichnisse gewähren und zugleich für einen Pfad, der .env entspricht, den Wert deny festlegen.

Profil erweitern

Verwende extends, wenn ein Profil weitgehend einem integrierten oder einem anderen benannten Profil entspricht. Erweitere vorzugsweise ein integriertes Profil, statt von Grund auf zu beginnen, damit die grundlegenden Schutzmaßnahmen erhalten bleiben. Wenn ein Profil beispielsweise :workspace erweitert, bleibt das Verzeichnis .codex im Workspace-Stammverzeichnis ohne Schreibzugriff, sofern du dies nicht ausdrücklich überschreibst. Lege das übergeordnete Profil einmal fest. Füge anschließend nur abweichende Regeln hinzu oder überschreibe sie.

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
description = "Project editing with OpenAI API access."
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

Dieses Profil leitet sich von :workspace ab, verweigert weiterhin den Zugriff auf Dateien, die .env entsprechen, und erlaubt Anfragen an api.openai.com. Ein Profil kann :read-only, :workspace oder ein anderes benanntes Profil erweitern. Es kann :danger-full-access nicht erweitern. Codex lehnt außerdem unbekannte übergeordnete Profile und Vererbungszyklen ab.

Konfigurationsspezifikation

Dateisystemberechtigungen

Dateisystemeinträge verwenden read, write oder deny:

Spezifischere Einträge haben Vorrang vor allgemeineren. Wenn zwei Einträge denselben Pfad betreffen, hat deny Vorrang vor write und write wiederum Vorrang vor read.

Diese Rangfolge ermöglicht es, in einem Profil zunächst einen umfassenden Arbeitsbereich festzulegen und anschließend Dateien oder Verzeichnisse auszunehmen, auf die weiterhin kein Lesezugriff möglich sein soll:

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"

In diesem Beispiel bleibt das Workspace-Stammverzeichnis beschreibbar, .devcontainer/ bleibt lesbar, ohne beschreibbar zu werden, und Umgebungsdateien, die dem Muster entsprechen, bleiben für Befehle in der Sandbox unzugänglich.

Eine spezifischere Pfadangabe kann auch einen enger gefassten Teilbaum innerhalb einer umfassenderen Sperrregel wieder freigeben:

[permissions.project-edit.filesystem]
"~/Documents" = "deny"
"~/Documents/codex" = "write"

Unterstützte Pfadformen:

Unter nativem Windows können Pfade relativ zum Home-Verzeichnis auch umgekehrte Schrägstriche enthalten, zum Beispiel ~\work.

Verwende :root nur, wenn ein Profil bewusst umfassenden Lesezugriff benötigt:

[permissions.audit.filesystem]
":root" = "read"

Verwende verschachtelte Einträge unter :workspace_roots, um den Zugriff auf Unterpfade relativ zum Workspace-Stammverzeichnis einzugrenzen:

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"          # each workspace root
"docs" = "read"        # each workspace-root docs directory
"generated" = "deny"   # each workspace-root generated directory

Verschachtelte Unterpfade müssen innerhalb ihres Workspace-Stammverzeichnisses bleiben. Verweise auf übergeordnete Verzeichnisse wie ../other-repo werden abgelehnt.

Lesezugriff mit exakten Pfaden oder Globs verweigern

Verwende deny für Dateien oder Verzeichnisbäume, die Codex nicht lesen soll, selbst wenn eine weiter gefasste Profilregel den Zugriff auf benachbarte Bereiche erlaubt. Exakte Pfade eignen sich für feste Speicherorte wie ~/.ssh. Glob-Muster sind besser geeignet, wenn ein Profil eine Gruppe sensibler Dateien abdecken soll, deren genaue Speicherorte sich je nach Repository unterscheiden.

Wenn sich ein Glob-Muster unter :workspace_roots befindet, interpretiert Codex es relativ zu jedem effektiven Workspace-Stammverzeichnis. Beispiel:

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Diese Regel verweigert den Lesezugriff auf passende .env-Dateien in jedem zur Laufzeit oder im Profil festgelegten Workspace-Stammverzeichnis. Verwende sie, wenn normale Schreibzugriffe im Workspace weiterhin möglich sein sollen, Umgebungsdateien, generierte Secrets oder ähnliche Dateien mit Zugangsdaten aber nicht lesbar sein dürfen.

deny-Glob-Muster werden als Regeln zum Verweigern des Lesezugriffs unterstützt. Globs mit read oder write sind beim Sandboxing unter Linux, WSL und nativem Windows weniger portabel. Verwende daher möglichst exakte Pfade oder Regeln für Unterverzeichnisse wie "docs/**" = "read".

Unter Linux, WSL und nativem Windows kann bei einem unbegrenzten **-Muster zum Verweigern des Lesezugriffs vor dem Start der Sandbox eine begrenzte Vorabexpansion erforderlich sein. Lege glob_scan_max_depth fest, wenn du ein unbegrenztes Muster wie "**/*.env" = "deny" verwendest:

[permissions.project-edit.filesystem]
glob_scan_max_depth = 3

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

glob_scan_max_depth muss mindestens 1 betragen. Bei höheren Werten werden vor dem Start der Sandbox tiefere Ebenen durchsucht. Das kann unter Linux, WSL und nativem Windows zusätzlichen Aufwand beim Start verursachen. Wenn du keine begrenzte Expansion verwenden möchtest, gib konkrete Tiefen an, zum Beispiel *.env, */*.env und */*/*.env.

Füge dem Profil wiederverwendbare Workspace-Stammverzeichnisse hinzu, wenn dieselben Regeln nicht nur für das Stammverzeichnis der aktuellen Sitzung gelten sollen:

[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = true

Wenn dieses Profil aktiv ist, wendet Codex die Regeln unter :workspace_roots auf die zur Laufzeit festgelegten Workspace-Stammverzeichnisse der aktuellen Sitzung sowie auf jedes aktivierte Workspace-Stammverzeichnis aus der Profildefinition an.

Unter nativem Windows werden Pfade mit Laufwerkbuchstaben wie D:\work und UNC-Pfade wie \\server\share als absolute Pfade unterstützt.

Netzwerkberechtigungen

Netzwerkzugriff und Netzwerkfilterung werden getrennt konfiguriert. Lege permissions.<name>.network.enabled = true fest, damit Befehle auf das Netzwerk zugreifen können, und aktiviere features.network_proxy, um die Domänenregeln des Profils durchzusetzen:

[features]
network_proxy = true

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"example.com" = "allow"      # exact host
"*.example.com" = "allow"    # subdomains only
"**.example.com" = "allow"   # apex and subdomains
"ads.example.com" = "deny"   # deny wins over allow

Das jeweilige Verhalten hängt von beiden Einstellungen ab:

• Netzwerk aus: Befehle können unabhängig von der Proxy-Funktion nicht auf das Netzwerk zugreifen.
• Netzwerk ein, Proxy aus: Befehle haben direkten, uneingeschränkten Zugriff auf das Netzwerk. Die Domänenregeln im Berechtigungsprofil werden nicht durchgesetzt.
• Netzwerk ein, Proxy ein: Befehle verwenden den Proxy, der die Domänenregeln des Profils durchsetzt. Wenn für den aktiven Proxy keine Domänen zugelassen sind, blockiert er externe Ziele.

Weder das Hinzufügen von [permissions.<name>.network.domains] noch die Einstellung permissions.<name>.network.enabled = true aktiviert features.network_proxy. Alternativ können Administrierende den Proxy mit [experimental_network] in requirements.toml aktivieren. Weitere Informationen findest du unter Verwaltete Konfiguration.

Ein aktiver Netzwerk-Sandbox-Proxy bindet standardmäßig an lokale Listener:

[permissions.project-edit.network]
enabled = true
proxy_url = "http://127.0.0.1:3128"
enable_socks5 = true
socks_url = "http://127.0.0.1:8081"
enable_socks5_udp = true

Belasse diese Listener-Einstellungen auf ihren Standardwerten, sofern du Codex nicht in eine bestimmte Laufzeitumgebung integrierst. Die Netzwerkschlüssel dangerously_* sind Ausweichmechanismen für spezialisierte Umgebungen und sollten nicht für die normale lokale Entwicklung verwendet werden.

Lokale und private Netzwerke

Wenn der Netzwerk-Proxy aktiv ist, aktiviert Codex standardmäßig einen Schutz für lokale und private Netzwerke, um DNS-Rebinding und unbeabsichtigten Zugriff auf lokale Dienste zu verhindern. Um ein lokales Ziel bewusst direkt zuzulassen, nimm den exakten Hostnamen oder die exakte IP-Adresse in die Zulassungsliste auf:

[permissions.project-edit.network.domains]
"localhost" = "allow"
"127.0.0.1" = "allow"

Lege allow_local_binding = true nur fest, wenn das Profil auf der Zulassungsliste stehende Hostnamen erreichen muss, die in lokale oder private Adressen aufgelöst werden:

[permissions.project-edit.network]
enabled = true
allow_local_binding = true

[permissions.project-edit.network.domains]
"localhost" = "allow"

Unix-Sockets

Die Weiterleitung von Unix-Sockets über einen Proxy ist ein lokaler Ausweichmechanismus für Tools wie Docker. Setze sie sparsam ein:

[permissions.project-edit.network.unix_sockets]
"/var/run/docker.sock" = "allow"
"/tmp/old.sock" = "deny"

Verwende deny, um einen Socket-Pfad abzulehnen, auch wenn ein Zulassungseintrag geerbt wurde. Abgelehnte Socket-Pfade werden nicht in die effektive Zulassungsliste aufgenommen.

Wenn Unix-Sockets aktiviert sind, binde Proxy-Listener weiterhin ausschließlich an Loopback-Adressen.

Migration von älteren Sandbox-Einstellungen

Berechtigungsprofile ersetzen die frühere Kombination aus sandbox_mode und sandbox_workspace_write, wenn ein wiederverwendbares Profil sowohl Dateisystem- als auch Netzwerkzugriffe regeln soll. Verwende für eine Sitzung entweder das eine oder das andere System, nicht beide.

Empfohlene Einstiegskonfigurationen:

• Verwende für einen Ablauf ohne Schreibzugriff das integrierte Profil :read-only oder definiere ein benutzerdefiniertes Profil, das nur dort Lesezugriff gewährt, wo er benötigt wird.
• Verwende zum Bearbeiten des Workspace das integrierte Profil :workspace oder definiere ein benutzerdefiniertes Profil, das über :workspace_roots Schreibzugriff gewährt und nur die zusätzlichen temporären Pfade oder Cache-Pfade hinzufügt, die für den Ablauf benötigt werden.
• Verwende :danger-full-access für die uneingeschränkte lokale Ausführung nur, wenn du bewusst das weitreichendste lokale Zugriffsmodell einsetzen möchtest.

Profile legen die lokale Standardkonfiguration einer Sitzung fest. Von der Organisation verwaltete Vorgaben können zusätzliche Einschränkungen festlegen, die eine Benutzerkonfiguration nicht lockern darf. Unter Verwaltete Konfiguration findest du Informationen zu administrativ erzwungenen Einschränkungen für Dateisystem und Netzwerk.

Geltungsbereich und Durchsetzung

Berechtigungsprofile legen die Grenzen für die lokale Ausführung von Befehlen in einer Sandbox fest. Verwende sie zusammen mit Genehmigungsrichtlinien und den separaten Kontrollmechanismen für die Websuche, Konnektoren, MCP-Server, den integrierten Browser, die Computernutzung und Codex Cloud.

Was Profile regeln

• Lokale Befehlsausführung: Berechtigungsprofile regeln die Ausführung von Befehlen in der Sandbox auf deinem Computer. Für Konnektoren, MCP-Server, Browser- und Computernutzungsfunktionen, Umgebungseinstellungen von Codex Cloud sowie genehmigte Berechtigungsausweitungen gelten eigene Kontrollmechanismen.
• Schreibzugriffe auf das Dateisystem: Ein Profil mit Schreibzugriff kann dauerhafte Änderungen verursachen. Behandle Schreibzugriffe auf Skripte, Build-Schritte, Paketmanager-Hooks, Shell-Startdateien und gemeinsam genutzte Verzeichnisse als sicherheitskritisch, da Tools oder andere Personen diese Dateien später außerhalb des ursprünglichen Sandbox-Kontexts ausführen können.
• Ziele ausgehender Verbindungen: Domänenregeln begrenzen die Ziele des Netzwerkverkehrs von Befehlen in der Sandbox nur, solange der Netzwerk-Proxy aktiv ist. Sie geben keinen Aufschluss darüber, ob ein zugelassenes Ziel vertrauenswürdig ist. Zulassungsregeln mit Platzhaltern bleiben weit gefasst.
• Lokale Dienste: Ein aktiver Netzwerk-Proxy blockiert Ziele in lokalen und privaten Netzwerken standardmäßig. Wenn du localhost, private IP-Adressen oder Unix-Sockets zur Zulassungsliste hinzufügst oder allow_local_binding = true festlegst, erlaubst du ausdrücklich den Zugriff auf lokale Dienste.

Was der Netzwerk-Proxy nicht regelt

Der Netzwerk-Proxy filtert nur den Datenverkehr lokaler Befehle, die innerhalb der Sandbox ausgeführt werden. Die Domänen-Zulassungsliste des Profils gilt nicht für:

• Websuche: Das gehostete Suchtool verwendet eigene Zugriffseinstellungen. Steuere es mit web_search und bei verwalteten Clients zusätzlich mit allowed_web_search_modes. tools.web_search.allowed_domains filtert Suchergebnisse, aber nicht den Netzwerkzugriff von Befehlen.
• Apps und Konnektoren: Konnektorbasierte Tools verwenden eigene dienstseitige Verbindungen, Workspace-Berechtigungen sowie App- oder Tool-Einstellungen.
• MCP-Server: Lokale und entfernte MCP-Server verwenden eigene Prozesse oder Transportmechanismen. Steuere sie über die Konfiguration mcp_servers und verwaltete Zulassungslisten für Server.
• Browser und Computernutzung: Für die Navigation im Browser und Aktionen der Computernutzung gelten eigene Einstellungen für Funktionen und Genehmigungen.
• Datenverkehr der Codex-Dienste: Anfragen an Modelle, zur Authentifizierung und an andere Client-Dienste verwenden die separaten HTTP- und System-Proxy-Einstellungen des Clients.
• Codex Cloud: Diese Aufgaben verwenden die eigenen Einstellungen für den Internetzugang ihrer Umgebung.

Um diese Bereiche einzuschränken, konfiguriere jede Funktion direkt. Eine Zulassungsliste für den Netzwerkzugriff von Befehlen ist keine globale Netzwerkrichtlinie für alle Aktionen, die Codex ausführen kann.

So funktioniert die Durchsetzung

• Unter macOS verwendet Codex Seatbelt-Sandbox-Profile. Wenn die ausgewählte Richtlinie von der Plattform-Sandbox nicht durchgesetzt werden kann, verweigert Codex die Ausführung des Befehls, anstatt ihn stillschweigend ohne Sandbox auszuführen.
• Unter Linux und WSL verwendet Codex bubblewrap und seccomp. Für kompatible Ausweichlösungen steht Landlock zur Verfügung. Die wirksamste Methode zur Durchsetzung hängt von Benutzer-Namespaces und der Kernel-Unterstützung ab. Eingeschränkte Container-Hosts können kompatible Ausweichlösungen erforderlich machen. Nicht unterstützte Richtlinien mit getrennten Zugriffsregeln werden abgelehnt.
• Unter nativem Windows bietet Sandboxing mit elevated den stärksten Schutz, weil dabei eigene Sandbox-Benutzerkonten mit eingeschränkten Berechtigungen, Berechtigungsgrenzen im Dateisystem und Firewallregeln genutzt werden können. Sandboxing mit unelevated ist eine Ausweichlösung mit schwächerer Netzwerkisolierung und kann nicht alle getrennten Ausnahmen für Lese- und Schreibzugriffe durchsetzen. Nicht unterstützte Richtlinien werden daher abgelehnt. Verwende WSL, wenn du das Sandbox-Modell von Linux benötigst.

Hinweise zum Betrieb

Wähle das restriktivste Profil, mit dem sich die Aufgabe noch abschließen lässt, insbesondere wenn du Schreibzugriffe oder ausgehenden Netzwerkzugriff gewährst. Stimme Genehmigungsrichtlinie, Umgang mit Secrets und Zulassungsregeln auf diese Zugriffsebene ab.

Gängige Profile

Ohne Schreibzugriff mit Netzwerk-Zulassungsliste

default_permissions = "readonly-net"

[features]
network_proxy = true

[permissions.readonly-net.filesystem]
":minimal" = "read"

[permissions.readonly-net.filesystem.":workspace_roots"]
"." = "read"

[permissions.readonly-net.network]
enabled = true

[permissions.readonly-net.network.domains]
"api.openai.com" = "allow"

Dateizugriff auf den Workspace beschränkt

Das folgende Beispiel zeigt ein Berechtigungsprofil, das Codex Schreibzugriff auf deine Workspace-Ordner gewährt und Lesezugriffe auf das übrige Dateisystem verweigert (mit begrenzten Ausnahmen gemäß :minimal).

default_permissions = "workspace-only"

[permissions.workspace-only]
# By extending the :workspace profile, you get Codex's safeguards to ensure
# subfolders such as .codex/ and .git/ within a workspace root are read-only
# while the rest of the folder is writable.
extends = ":workspace"

[permissions.workspace-only.filesystem]
# By default, deny read access to all files on disk.
":root" = "deny"

# Though in practice, a software agent needs to be able to read folders that
# contain common tools, such as `/usr/bin`, to get work done, so grant access
# to a "minimal" set of files and folders, as determined by Codex.
":minimal" = "read"

# By extending the :workspace profile, :tmpdir and :slash_tmp are "write" by
# default, though you can deny access to them altogether, if desired.
":tmpdir" = "deny"
":slash_tmp" = "deny"

Workspace-Schreibzugriff ohne Netzwerkzugriff

default_permissions = "project-edit"

[permissions.project-edit.filesystem]
":minimal" = "read"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"

[permissions.project-edit.network]
enabled = false

Workspace-Schreibzugriff mit öffentlichem Webzugriff

default_permissions = "workspace-net"

[features]
network_proxy = true

[permissions.workspace-net.filesystem]
":minimal" = "read"

[permissions.workspace-net.filesystem.":workspace_roots"]
"." = "write"

[permissions.workspace-net.network]
enabled = true

[permissions.workspace-net.network.domains]
"*" = "allow"

Verwende die globale Zulassungsregel "*" nur, wenn du öffentlichen Netzwerkzugriff erlauben möchtest. Sperrregeln können eine weit gefasste Zulassungsliste einschränken.