Zwei Konten in Codex CLI: So trennen Sie Arbeits- und private Logins

Wenn Sie Codex CLI sowohl für private Projekte als auch für berufliche Aufgaben einsetzen, müssen Sie Umgebungen und Benutzerkonten sauber voneinander trennen. Das Flag --profile ist für diesen Zweck nicht vorgesehen: Gemäß der Dokumentation zur Basiskonfiguration legt ein Profil lediglich die Datei $CODEX_HOME/<name>.config.toml über die Hauptkonfiguration (um Parameter wie Modellwahl, Sandbox-Stufe oder MCP-Server anzupassen), wechselt jedoch nicht die aktiven Anmeldedaten.

Um unterschiedliche Konten zu verwenden, definieren Sie über die Umgebungsvariable CODEX_HOME unabhängige Verzeichnisse und führen den Anmeldevorgang (codex login) für jedes Verzeichnis separat durch.

Risiken beim manuellen Kopieren von Sitzungsdateien

Ein Artikel auf Habr beschreibt einen solchen Behelf aus der Praxis: Der Autor automatisierte den Kontowechsel, indem er Authentifizierungsdateien über ein Bash-Skript austauschte und das verbleibende Kontingent über einen undokumentierten Web-Interface-Endpunkt abfragte. Der Autor wies selbst ausdrücklich auf den entscheidenden Nachteil hin: die Abhängigkeit von einer internen, privaten Backend-API, die sich jederzeit ohne Vorankündigung ändern kann.

Das manuelle Bearbeiten von Sitzungsdateien birgt zudem die Gefahr, den Lebenszyklus von Token zu beschädigen: Wird ein Refresh-Token an einer Stelle rotiert, verliert das kopierte Duplikat im anderen Verzeichnis unter Umständen seine Gültigkeit. Ein solcher Autorisierungsfehler nach dem Kopieren von Dateien wird in Issue #15410 beschrieben. Ein einzelner Bericht beweist zwar nicht, dass jede Dateikopie zwangsläufig fehlschlägt, doch das manuelle Übertragen von Dateien schafft unnötige Betriebsrisiken. Lesen oder kopieren Sie auth.json keinesfalls manuell und greifen Sie nicht auf private Backend-APIs zu. Der vorgesehene Weg besteht darin, die CLI die Sitzungen in getrennten Verzeichnissen eigenständig verwalten zu lassen.

Anmeldedatenspeicher und Richtlinienbeschränkungen

Vor dem Einrichten getrennter Verzeichnisse ist es wichtig zu verstehen, wie und wo Authentifizierungsdaten abgelegt werden. Laut der Authentifizierungsdokumentation unterstützt die Konfigurationsoption cli_auth_credentials_store folgende Modi:

• file — Anmeldedaten werden in einer lokalen Datei auth.json innerhalb des CODEX_HOME-Verzeichnisses gespeichert.
• keyring — Daten werden im Schlüsselbund des Systems abgelegt (Keychain unter macOS, Secret Service unter Linux).
• auto — Die CLI versucht zunächst, den System-Keyring zu nutzen, und weicht auf den Dateispeicher aus, falls kein Keyring verfügbar ist.
• ephemeral — Die Sitzung verbleibt ausschließlich im Arbeitsspeicher des aktuellen Prozesses.

Beachten Sie bei der Planung getrennter Umgebungen folgende Einschränkungen und Vorbehalte:

• Separate CODEX_HOME-Verzeichnisse garantieren keine vollständige Isolation, wenn auf dem Rechner zentrale Unternehmensrichtlinien gelten (Managed configuration / requirements.toml). Hat ein Administrator eine bestimmte Anmeldemethode oder einen Speichertyp vorgegeben, besitzen diese Vorgaben stets Vorrang vor lokalen Einstellungen.
• Im Quellcode der CLI unterscheidet der Keyring-Dienst Verzeichnisse anhand eines Hashwerts des CODEX_HOME-Pfads (siehe storage.rs). Die Annahme, dass verschiedene Verzeichnisse automatisch denselben Keyring-Eintrag teilen, trifft daher nicht zu. Dennoch garantiert dies keine lückenlose Isolation über alle Umgebungen hinweg: Das tatsächliche Verhalten des Speichers hängt vom Betriebssystem und den Systemeinstellungen ab und sollte auf dem jeweiligen Zielsystem überprüft werden.
• Sie können nicht von vornherein davon ausgehen, dass sich Token ausschließlich im Verzeichnis befinden, solange der aktive Speichermodus nicht verifiziert ist.

Schritt-für-Schritt-Einrichtung zweier Umgebungen

Wir richten zwei dedizierte Verzeichnisse ein: $HOME/.codex-personal und $HOME/.codex-work. Das bestehende Verzeichnis ~/.codex bleibt dabei unverändert und unberührt.

Schritt 1. Verzeichnisse vorbereiten

Erstellen Sie eigene Verzeichnisse mit Zugriffsbeschränkung ausschließlich für Ihr Benutzerkonto:

mkdir -p "$HOME/.codex-personal" "$HOME/.codex-work"
chmod 700 "$HOME/.codex-personal" "$HOME/.codex-work"

Sofern die Richtlinien Ihrer Organisation den dateibasierten Speicher gestatten, können Sie vor der Anmeldung in jedem Verzeichnis cli_auth_credentials_store = "file" explizit in der Datei config.toml konfigurieren:

cat << 'EOF' > "$HOME/.codex-personal/config.toml"
cli_auth_credentials_store = "file"
EOF

cat << 'EOF' > "$HOME/.codex-work/config.toml"
cli_auth_credentials_store = "file"
EOF

Falls auf Ihrem Gerät verbindliche unternehmensweite Authentifizierungsrichtlinien gelten, verwenden Sie stattdessen den vom Administrator freigegebenen Speichermodus.

Schritt 2. Unabhängige Authentifizierung

Die anmeldebasierte Browser-Authentifizierung bindet sich an die Sitzung, die aktuell auf chatgpt.com aktiv ist. Das Profilmenü des Browsers zeigt lediglich die aktuelle Websitzung an und belegt nicht, welche Anmeldedaten im jeweiligen CODEX_HOME gesichert wurden. Prüfen Sie das gewünschte Konto und den passenden Workspace daher bei jedem Browser-Login sorgfältig:

• Wechseln Sie vor dem Anmelden in die private Umgebung im Browser zu Ihrem privaten Konto.
• Wählen Sie vor dem Anmelden in die Arbeitsumgebung das entsprechende geschäftliche Konto oder den gewünschten Workspace im Browser aus.

Führen Sie den Login-Vorgang für jede Umgebung separat aus:

env CODEX_HOME="$HOME/.codex-personal" codex login

env CODEX_HOME="$HOME/.codex-work" codex login

Bestätigen Sie in beiden Fällen die Autorisierungsanfrage im sich öffnenden Browserfenster. Sollten Zweifel bestehen, führen Sie den regulären Befehl env CODEX_HOME="..." codex logout aus und wiederholen Sie die Anmeldung für das betreffende Verzeichnis, während Sie das aktive Konto im Browser nochmals prüfen (lesen oder kopieren Sie Tokendateien keinesfalls manuell).

Schritt 3. Anmeldestatus überprüfen

Überprüfen Sie den Authentifizierungsstatus in beiden Verzeichnissen:

env CODEX_HOME="$HOME/.codex-personal" codex login status
env CODEX_HOME="$HOME/.codex-work" codex login status

Der Befehl codex login status gibt lediglich Aufschluss über die Authentifizierungsmethode, liefert aber keinen Nachweis über die Identität eines bestimmten Benutzerkontos. Beachten Sie den Unterschied bei den Abrechnungsquellen: Ein ChatGPT-Login greift auf das Abonnement oder das enthaltene Kontingent des jeweiligen Plans und Workspace zu, während ein Login per API-Schlüssel separat über die OpenAI Platform abgerechnet wird.

Dieser Leitfaden setzt voraus, dass Sie zwei verschiedene ChatGPT-Konten nutzen. Zeigt die Ausgabe von status einen API-Key an, entspricht dies nicht dem gewünschten Szenario — überprüfen Sie in diesem Fall den Anmeldevorgang für das betreffende Verzeichnis erneut.

Schritt 4. Testausführung einer Aufgabe

Um die Arbeitsumgebung zu überprüfen, führen Sie eine reale Aufgabe in einem geschäftlichen Test-Repository aus und schränken Sie die Berechtigungen über die Sandbox read-only ein:

cd /path/to/work-project
env CODEX_HOME="$HOME/.codex-work" codex exec --sandbox read-only "Lies die README.md und beschreibe den Zweck des Projekts. Verändere keine Dateien"

Ein kurzer Read-Only-Test bestätigt die Funktion von Sitzung und Sandbox. Die Überprüfung des Verbrauchs (Usage) im jeweiligen Konto oder Workspace nach dem Test liefert jedoch lediglich ein verzögertes, indirektes Indiz und keinen verbindlichen Identitätsnachweis. Bleiben Restzweifel bestehen, führen Sie env CODEX_HOME="$HOME/.codex-work" codex logout aus und wiederholen Sie den Anmeldevorgang, während Sie das im Browser aktive Konto sorgfältig kontrollieren.

Tägliche Nutzung

Für die tägliche Arbeit können Sie Befehle entweder direkt mit vorangestelltem CODEX_HOME aufrufen oder zwei Hilfsfunktionen in Ihrer Shell-Konfigurationsdatei (~/.zshrc oder ~/.bashrc) hinterlegen:

codex-personal() {
  env CODEX_HOME="$HOME/.codex-personal" codex "$@"
}

codex-work() {
  env CODEX_HOME="$HOME/.codex-work" codex "$@"
}

Beispiele für den Aufruf mit Weiterleitung aller Argumente über "$@":

codex-work login status

cd /path/to/work-project
codex-work exec --sandbox read-only "Lies die README.md und beschreibe den Zweck des Projekts. Verändere keine Dateien"

codex-personal