Halten Sie Geheimnisse aus der Arbeitsumgebung heraus und verweigern Sie den Zugriff auf sensible Dateien. Kombinieren Sie zunächst diese beiden Maßnahmen.
Schreibschutz, Freigaben und der Widerspruch gegen die Trainingsnutzung erfüllen unterschiedliche Aufgaben. Prüfen Sie getrennt, ob sie den Zugriff auf geheime Dateien verhindern können.
Lesen, Ausführen und Übertragen getrennt prüfen
Entfernen Sie unnötige Geheimnisse aus der Arbeitsumgebung. Erwägen Sie eine deny-Regel für den Lesezugriff auf sensible Dateien.
Prüfen Sie, wer Freigaben kontrolliert. Erweitern Sie die Grenze nicht unbedacht durch Full access oder die Erlaubnis, außerhalb der Sandbox auszuführen.
Prüfen Sie Befehlsnetzwerk, Übertragung an das Modell sowie Browser- und MCP-Zugriff getrennt.
Die OpenAI-Dokumentation zu Permissions, Sandbox, Freigaben und Sicherheit sowie zur Konfiguration wurde am 8. Oktober 2026 geprüft. Dieser Artikel behandelt vor allem Befehle in einer lokalen Sandbox. Die Beispielkonfiguration wurde auf keinem realen Gerät angewendet oder auf ihre Durchsetzung getestet. Geräte- und Kontoeinstellungen wurden nicht geändert.
Inhalt
- 1. Schreibschutz, Freigaben und Trainingseinstellungen
- 2. Geheimnisse aus der Arbeitsumgebung heraushalten
- 3. Beispielkonfiguration zum Verweigern von Lesezugriffen
- 4. .env-Muster und mögliche Lücken
- 5. Was das Abschalten des Befehlsnetzwerks blockiert
- 6. Umgebungsvariablen, Betriebssysteme und Cloud
- 7. Mit Dummy-Dateien prüfen
- Häufige Fragen
1. Schreibschutz, Freigaben und Trainingseinstellungen
Dateiänderungen zu verhindern ist etwas anderes, als das Lesen zu verhindern.
Beschränkt das Schreiben. Lesbare Dateiinhalte werden dadurch nicht als Geheimnisse verborgen.
Legt fest, wo Änderungen erlaubt sind. Das Lesen ist nicht zwangsläufig auf dieselben Orte beschränkt.
| Kontrolle | Was sie hauptsächlich regelt | Was sie allein nicht gewährleistet |
|---|---|---|
| Schreibschutz | Ob Dateien verändert werden dürfen | Dass zugängliche geheime Dateien nicht gelesen werden |
| Freigaberichtlinie | Wer Aktionen über eine Grenze hinweg prüft | Eine menschliche Prüfung jedes erlaubten Lesezugriffs |
| Dateibezogene deny-Regeln | Verweigerung von Lese- und Schreibzugriffen auf bestimmte Pfade | Entfernung bereits eingefügter Inhalte oder Sperrung anderer Zugriffswege |
| Befehlsnetzwerkbeschränkungen | Netzwerkziele von Befehlen in der Sandbox | Sperrung sämtlicher Verbindungen für Modelle, Authentifizierung, Browser, MCP und andere Dienste |
| Trainingseinstellungen | Ob verarbeitete Daten zur Modellverbesserung genutzt werden | Dass die Daten weder verarbeitet noch übertragen werden |
Auch mit on-request können Befehle innerhalb des erlaubten Bereichs ohne zusätzliche Freigabe laufen. Wenn Menschen prüfen sollen, kontrollieren Sie sowohl die Freigaberichtlinie als auch den Empfänger der Prüfanfrage.
Was bei automatischer KI-Prüfung anders ist
approvals_reviewer = "auto_review" leitet die betreffende Prüfung an eine KI. Dies ist keine menschliche Prüfung und macht nicht jede bereits erlaubte Aktion zusätzlich prüfpflichtig.
Quelle: OpenAI: Freigaben und Sandbox-Grenzen. Die Trainingsnutzung behandeln wir gesondert in ChatGPT und Codex: Trainingseinstellungen und vertrauliche Informationen.
2. Geheimnisse aus der Arbeitsumgebung heraushalten
Für eine UI-Änderung reichen möglicherweise Quellcode und erfundene Daten. Produktions-API-Schlüssel, Kundendaten und Familienunterlagen müssen nicht in derselben Umgebung liegen.
Eine Verschiebung in einen anderen Ordner reicht nicht aus. Bleiben umfassende Leserechte bestehen, können die Dateien weiterhin erreichbar sein.
Nur benötigte Inhalte in die Arbeitskopie aufnehmen
Verwenden Sie kleine Eingaben, die das Problem reproduzieren, statt Produktionsdaten.
Konfigurationsbeispiele sollten nur Feldnamen enthalten. Prüfen Sie auch Protokolle, Sicherungen und Verlauf.
Prüfen Sie, ob andere Ordner, das Home-Verzeichnis, gemeinsame Speicher oder verbundene Apps erreichbar sind.
Verhindern Git-Ignore-Regeln das Lesen?
.gitignore bestimmt, welche nicht versionierten Dateien Git ignorieren soll. Leserechte des Betriebssystems entzieht die Datei nicht. Selbst wenn ein Suchwerkzeug eine Datei normalerweise überspringt, garantiert das nicht, dass der direkte Lesezugriff über ihren Pfad verweigert wird. Eine nachträgliche Ignore-Regel betrifft außerdem keine bereits von Git erfassten Dateien. Git-Dokumentation: Geltungsbereich von gitignore.
Anweisungen und technisch erzwungene Zugriffssperren
Die Anweisung „Keine Geheimnisse lesen“ in AGENTS.md kann als Arbeitsregel sinnvoll sein. Sie erzeugt allein keine Zugriffsbeschränkung des Betriebssystems. Kombinieren Sie Anweisungen mit technisch erzwungenen Sperren. Beispiele zum Anonymisieren finden Sie in Vorsichtsmaßnahmen bei Eingaben in KI-Werkzeuge.
3. Beispielkonfiguration zum Verweigern von Lesezugriffen
Permission profiles sind eine Beta-Funktion. Prüfen Sie vor dem Einsatz die unterstützte Umgebung und die in der aktuellen Sitzung ausgewählte Konfiguration.
read: LesenErlaubt das Lesen des Ziels
write: BearbeitenErlaubt das Schreiben am Ziel
deny: VerweigernVerweigert sowohl Lesen als auch Schreiben am Ziel
Auf Konflikte mit bisherigen Sandbox-Einstellungen achten
Sind bisherige Einstellungen aktiv, werden Permission profiles unter Umständen nicht verwendet.
Konflikte und Administrationsvorgaben prüfen
Nicht mit bisherigen Einstellungen mischen: default_permissions und [permissions] sind nicht zur Kombination mit dem bisherigen sandbox_mode oder [sandbox_workspace_write] gedacht. Enthält die geladene Konfiguration sandbox_mode oder wird beim Start --sandbox verwendet, kommt normalerweise der bisherige Ansatz zum Einsatz. Administrationsvorgaben über allowed_permission_profiles sind eine gesonderte Bedingung.
Der folgende Konfigurationsvorschlag zur Veranschaulichung ergänzt das offizielle Beispiel für den Workspace um die Sperrung geheimer Dateien und menschliche Freigaben. Ersetzen Sie damit nicht Ihre gesamte vorhandene Konfiguration. Prüfen Sie Versionsunterstützung, Organisationsvorgaben und benötigte Ausführungspfade und testen Sie anschließend in einer Dummy-Umgebung.
Konfigurationsort: Benutzer und Projekt
~/.codex/config.toml
.codex/config.toml
Geltungsbereich und Ladebedingungen unterscheiden sich. Projektkonfigurationen werden nur für vertrauenswürdige Projekte geladen.
default_permissions = "project-private"
approval_policy = "on-request"
approvals_reviewer = "user"
[permissions.project-private]
extends = ":workspace"
[permissions.project-private.filesystem]
":root" = "deny"
":minimal" = "read"
[permissions.project-private.filesystem.":workspace_roots"]
".env" = "deny"
".env.production" = "deny"
"secrets" = "deny"
[permissions.project-private.network]
enabled = falseWelche Pfade erfasst dieses Beispiel?
Gilt für den aktuellen und jeden zusätzlichen Workspace
.envZur Sperrung vorgesehen.env.productionZur Sperrung vorgesehensecrets/ und InhaltZur Sperrung vorgesehensubfolder/.envGesondert prüfenUmbenannte Geheimnisse oder Kopien in ProtokollenGesondert prüfen:root verweigert das Lesen. Ausnahmen sind etwa :minimal für die Ausführung und vom geerbten Profil erlaubte temporäre Verzeichnisse.
Erbt die Bearbeitungsrechte von :workspace und sperrt die oben angegebenen Pfade. In Ausgaben enthaltene Geheimnisse werden damit nicht erfasst.
Profilnamen, mehrere Workspaces und temporäre Dateien
project-private ist der für dieses Beispiel gewählte Name. :workspace_roots gilt für den aktuellen und zusätzliche Workspaces und erfasst die aufgeführten Pfade direkt unter dem jeweiligen Stammverzeichnis. secrets erfasst eine so benannte Datei oder einen gleichnamigen Verzeichnisbaum.
Die Konfiguration verhindert nicht jeden Lesezugriff außerhalb des Workspace. Vermeiden Sie außerdem, Geheimnisse in temporäre Speicher zu kopieren.
Quelle: OpenAI: Konfiguration, Sperren und Geltungsbereich von Permission profiles. Der Artikel berichtet nicht von einer Anwendung des Beispiels und einer Isolationsprüfung auf einem realen Gerät.
4. .env-Muster und mögliche Lücken
Exakte Namen eignen sich für Geheimnisse an bekannten Orten. Bei Mustern ist zu beachten, dass *.env und .env.* verschieden sind. Nehmen Sie nicht an, dass das offizielle Beispiel **/*.env auch .env.production unter denselben Bedingungen sperrt.
| Beispielregel | Vorgesehenes Ziel | Gesondert prüfen |
|---|---|---|
.env | Datei dieses Namens direkt im Workspace-Stammverzeichnis | Unterordner und Dateinamen mit angehängtem Suffix |
.env.production | Produktionskonfiguration im Stammverzeichnis | Produktionskonfigurationen unter anderen Namen oder Kopien |
secrets | Pfad dieses Namens im Stammverzeichnis samt Inhalt | Kopien an anderen Orten, etwa in Protokollen oder Sicherungen |
**/*.env | Auf .env endende Dateien über mehrere Verzeichnisebenen | Dateinamen mit Suffix, Suchtiefe und Änderungen nach dem Start |
Verzeichnistiefe und nach dem Start angelegte Dateien prüfen
Unter Linux, WSL und nativem Windows können Sperrmuster mit uneingeschränktem ** eine begrenzte Auflösung vor dem Start erfordern. Die offizielle Dokumentation beschreibt, glob_scan_max_depth auf mindestens 1 zu setzen oder die Tiefe mit Mustern wie *.env, */*.env und */*/*.env ausdrücklich anzugeben. Verwenden Sie tiefere Verzeichnisse, prüfen Sie die Abdeckung bis zu dieser Ebene.
Einige Durchsetzungswege sammeln passende Pfade vor dem Start. Prüfen Sie auf Ihrem tatsächlichen Betriebssystem und mit Ihrer Version und Ausführungsumgebung, ob später angelegte Dateien gesperrt werden. Behandeln Sie Sperrmuster nicht als universelle Regel, die zwangsläufig alle künftigen Geheimnisse schützt.
Welche Regel gewinnt bei überlappenden Berechtigungen?
Eine spezifischere Pfadregel kann eine allgemeinere überschreiben. Für denselben Pfad gewinnt die Sperre; innerhalb einer umfassenden Sperre kann aber auch eine eng begrenzte Erlaubnis entstehen. Prüfen Sie zusätzliche Konfigurationsebenen und die Vererbung von übergeordneten Profilen.
Quellen: OpenAI: Lesezugriffe über Pfade und Muster sperren, Ladereihenfolge der Konfiguration. Die Projektdatei .codex/config.toml wird nur in vertrauenswürdigen Projekten geladen. Unterscheiden Sie zwischen dem Dateiinhalt und den tatsächlich aktiven Sitzungseinstellungen.
5. Was das Abschalten des Befehlsnetzwerks blockiert
Das Abschalten des Befehlsnetzwerks beschränkt die Netzwerknutzung von Programmen innerhalb der betreffenden Sandbox. Modell- und Authentifizierungsanfragen des Codex-Clients sind jedoch von diesen Kontrollen getrennt. Ein ausgeschalteter Befehlsnetzwerk-Schalter belegt nicht, dass gelesener Code nicht als Modellkontext übertragen wird.
Was die Netzwerkregeln für Befehle erfassen
Netzwerkaktivitäten von Befehlen, Skripten und deren Kindprozessen.
Modelle und Authentifizierung, Websuche, verbundene Apps, MCP, Browser und Computer Use sowie Cloud-Aufgaben.
Soll das Netzwerk erlaubt, aber auf bestimmte Ziele beschränkt sein, müssen Sie neben Domainregeln auch den Netzwerkproxy aktivieren. Erlaubte Domains nur im Profil aufzulisten aktiviert diese Regeln nicht.
| Befehlsnetzwerk | Proxy | Ergebnis |
|---|---|---|
| Aus | Beliebig | Befehlsnetzwerk ist nicht erlaubt |
| An | Aus | Direkte Verbindungen sind möglich; Domainregeln des Profils gelten nicht |
| An | An | Der Proxy setzt Domainregeln durch und sperrt externe Ziele, wenn keines erlaubt ist |
Geheimnisse können weiterhin an ein erlaubtes Ziel gesendet werden. Domains einzuschränken ist nicht dasselbe wie den übertragenen Inhalt zu prüfen. Nehmen Sie bei einer Freigabe außerhalb der Sandbox nicht an, dass die bisherigen Sperren unverändert schützen. Prüfen Sie, welche Grenzen die Freigabe erweitert. OpenAI: Netzwerkberechtigungen und Proxy-Anforderungen.
6. Umgebungsvariablen, Betriebssysteme und Cloud
Geheimnisse stehen nicht nur in Dateien. Enthält die Shell einen API-Schlüssel, kann ein Kindprozess dessen Wert über geerbte Umgebungsvariablen nutzen, auch wenn der Dateizugriff gesperrt ist. Die Vererbung wird gesondert mit shell_environment_policy verwaltet.
Automatischer Variablenausschluss: true und false
true | StandardWendet den automatischen Ausschluss nicht an für Variablen mit KEY, SECRET oder TOKEN im Namen
falseWendet diesen automatischen Ausschluss an
ignore_default_excludes. Diese Einstellung ist von Dateisperren getrennt und filtert anhand des Variablennamens; sie erkennt nicht jedes Geheimnis.Variablen mit anderen Namen oder von Programmen anderweitig abgerufene Werte werden dadurch nicht geschützt. set wird nach dem Ausschluss angewendet und kann ausgeschlossene Variablen wieder einsetzen. OpenAI: Umgebungsvererbung und Vorrangregeln.
Windows: auch die Sandbox-Implementierung prüfen
Lokale Permission profiles sind für macOS, Linux, WSL und natives Windows dokumentiert, die Implementierungen unterscheiden sich jedoch. Unter Windows wird die Sandbox mit erhöhten Rechten als stärkerer Ansatz beschrieben. Die Sandbox ohne erhöhte Rechte bietet schwächere Netzwerkisolation und kann einige Richtlinien zur Lese- und Schreibisolation nicht durchsetzen. Laut Dokumentation führen nicht unterstützte Richtlinien zur Verweigerung der Ausführung. Ein Fehler ist kein Grund, auf Full access umzuschalten. OpenAI: Durchsetzung nach Betriebssystem.
Cloud: lokale Einstellungen nicht unverändert übernehmen
Prüfen Sie die Einstellungen der jeweiligen Codex-Cloud-Umgebung gesondert. Lokale Profile gelten nicht zwangsläufig automatisch überall in der Cloud oder in dots Cloud-Umgebung. Übernehmen Sie den lokalen Konfigurationsvorschlag dieses Artikels nicht unverändert als Cloud-Konfiguration. Unterschiede der Ausführungsorte erläutert Codex Remote, Cloud und die Voraussetzungen für PC-Verbindungen.
7. Mit Dummy-Dateien prüfen
„Ich habe das Lesen untersagt“, „Ich habe die Konfiguration gespeichert“ und „Der Lesezugriff wurde tatsächlich verweigert“ sind unterschiedliche Nachweise. Lassen Sie Codex zum Testen keine echten Geheimnisse lesen. Die folgenden Schritte sind ein Prüfplan für Benutzer oder Administratoren, kein Bericht über Tests auf diesem Gerät.
- Umgebung dokumentieren: Notieren Sie Codex-Version, Betriebssystem, Ausführungsort und ausgewählte Berechtigungen. Prüfen Sie in der CLI mit
/statusden Workspace-Bereich und mit/permissionsdie ausgewählten Berechtigungen. - Konfigurationskonflikte prüfen: Prüfen Sie Benutzer- und vertrauenswürdige Projekteinstellungen, Profil, Startparameter und Administrationsvorgaben. Fügen Sie zur Diagnose keine vollständigen Konfigurationsdateien oder geheimen Werte in die Unterhaltung ein.
- Dummy-Dateien vorbereiten: Legen Sie in einem gesonderten Workspace ohne Geheimnisse erlaubte und zu sperrende Dateien mit erfundenen Markierungen an.
- Erlaubnis und Sperre prüfen: Bestätigen Sie über denselben Ausführungsweg, dass erlaubte Dateien lesbar sind und gesperrte Lesezugriffe Fehler erzeugen. Wenn Codex freiwillig auf das Lesen verzichtet, belegt das keine technisch erzwungene Sperre.
- Verschiedene Orte testen: Prüfen Sie Dummy-Dateien im Stammverzeichnis, in Unterordnern, mit Dateinamenssuffix und nach dem Start angelegte Dateien. Geben Sie keine Aktion frei, die die Sperre umgeht. Gelingt ein unerwarteter Lesezugriff, stoppen Sie die Nutzung dieser Umgebung und untersuchen Sie die Ursache.
- Auch Ausgabepfade prüfen: Prüfen Sie, ob Tests oder Builds Geheimnisse in Protokolle schreiben oder dieselben Informationen an andere MCP-Werkzeuge, Browser oder verbundene Apps weitergeben.
Verfügbare Informationen unterscheiden sich je nach CLI-Version und Anzeige. Prüfen Sie daher die tatsächliche Ausgabe, statt sich auf Befehlsnamen zu verlassen. Die offizielle CLI bietet über codex sandbox außerdem betriebssystemspezifische Prüfungen. Bevor Sie diese als gleichwertig behandeln, prüfen Sie, ob die mit einem Hilfsbefehl getesteten Einstellungen denen Ihrer üblichen Desktop- oder IDE-Sitzung entsprechen. OpenAI: Sandbox testen.
Nachträgliche Sperrregeln machen bereits gelesene Inhalte nicht rückgängig. Prüfen Sie die Speicherung früherer Unterhaltungen, Protokolle und Dateien sowie Trainingseinstellungen gesondert. Ein erfolgreicher Dateizugriff allein belegt keine Offenlegung an Dritte. Bewerten Sie getrennt, was gelesen wurde, wohin es gelangte und ob Zugangsdaten Maßnahmen erfordern.
Auch in einem öffentlichen Codex-Issue haben Nutzer Möglichkeiten zum Ausschließen geheimer Dateien gefordert. Das zeigt ein reales Anliegen, belegt aber nicht, dass die Funktion heute nicht unterstützt wird. Die Spezifikationsaussagen dieses Artikels stützen sich auf die aktuelle offizielle Permissions-Dokumentation, nicht auf ältere Beiträge.
Häufige Fragen
Verhindert read-only, dass .env übertragen wird?
Das lässt sich aus read-only nicht garantieren: Der Modus beschränkt Änderungen. Um lesbare .env-Inhalte vom Modellkontext fernzuhalten, prüfen Sie getrennt die Lesesperre für die Datei und eine Arbeitsumgebung ohne Geheimnisse.
Reichen .gitignore oder AGENTS.md?
Sie ersetzen keine technisch erzwungene Lesesperre. Git-Ignore-Regeln, Arbeitsanweisungen und Betriebssystemberechtigungen sind getrennte Mechanismen. Prüfen Sie mit Dummy-Dateien, dass deny in der aktuellen Ausführungsumgebung wirksam ist.
Läuft Codex ohne Netzwerkzugriff vollständig auf dem Gerät?
Nein. Befehlsnetzwerkbeschränkungen schalten Modell- und Authentifizierungsverbindungen nicht ab. Einstellungen für Browser, MCP, verbundene Apps und Cloud sind ebenfalls gesondert.
Schützt das Beispiel Geheimnisse unter Windows vollständig?
Ein vollständiger Schutz ist nicht garantiert. Prüfen Sie die Unterstützung der Beta-Funktion, die Sandbox-Implementierung, tatsächlich aktive Konfigurationsebenen, Pfade und Werkzeuge. Das Beispiel wurde auf keinem realen Gerät angewendet oder getestet.
