Wer Codex in VSCodium auf Windows über SSH auf einen Linux-Server nutzt, kann in eine unangenehme Sackgasse laufen: Die Codex-Erweiterung versucht die Anmeldung über einen lokalen Browser-Redirect auf localhost:1455, aber genau dieser Rückweg funktioniert in manchen Remote-Setups nicht zuverlässig. OpenAI dokumentiert diesen lokalen Callback-Server auf Port 1455 ausdrücklich und empfiehlt für Remote- oder Headless-Umgebungen stattdessen den Device-Code-Login mit codex login --device-auth.

In meinem Fall war das Fehlerbild typisch: SSH funktionierte, der Remote-Server von VSCodium startete sauber, Port-Forwarding wurde aufgebaut, aber die Codex-Anmeldung blieb trotzdem hängen. Der Grund war nicht Debian, nicht der SSH-Schlüssel und nicht der Server selbst, sondern der Browser-Callback zurück auf localhost:1455. Für genau solche Umgebungen ist der Device-Code-Login gedacht.

Das Problem

Die Codex-Erweiterung oder die CLI startet bei der Standardanmeldung einen Browserflow und erwartet danach den Rücksprung auf einen lokalen Callback-Server. Standardmäßig läuft dieser auf localhost:1455. Auf einem lokalen Rechner ist das meist unproblematisch. In einer Remote-Konstellation mit VSCodium, SSH, Port-Forwarding und Windows als Client kann dieser Rückweg aber scheitern, obwohl der eigentliche SSH-Zugang längst funktioniert.

Das Symptom ist tückisch, weil die Logs oft harmlos aussehen: Public-Key-Login klappt, der codium-server wird gestartet, ein Remote-Port wird geöffnet, lokales Forwarding wird angelegt – und trotzdem kommt am Ende keine funktionierende Codex-Sitzung zustande. Dann sucht man schnell am falschen Ende und verdächtigt SSH, obwohl das eigentliche Problem in der Authentifizierungsschicht von Codex liegt.

Die robuste Lösung

Nicht die Extension auf Windows die Anmeldung durchklicken lassen, sondern sich direkt auf dem Zielserver per SSH mit Codex anmelden – und zwar per Device Code.

OpenAI nennt genau diesen Weg als bevorzugte Methode für Remote- und Headless-Umgebungen: In solchen Situationen soll codex login --device-auth verwendet werden. Dabei wird kein lokaler Redirect auf localhost:1455 benötigt. Stattdessen zeigt die CLI einen Link und einen Einmalcode an, der im Browser bestätigt wird.

Voraussetzungen

Auf dem Linux-Server muss die Codex CLI installiert sein. Die offizielle Dokumentation nennt für Linux mit npm die globale Installation über:

sudo npm install -g @openai/codex

Danach sollte codex --version funktionieren.

Schritt-für-Schritt-Anleitung

1. Per SSH auf den Zielserver einloggen

Zuerst ganz normal auf den Server verbinden, auf dem Codex später laufen soll:

ssh dev09 # dev09 ist einer meiner lokalen Entwicklungs-Server

Wichtig ist: Nicht auf dem Windows-Rechner anmelden, sondern wirklich in der SSH-Sitzung auf dem Linux-Server arbeiten.

2. Prüfen, ob die Codex CLI installiert ist

codex --version

Falls stattdessen codex: Kommando nicht gefunden erscheint, erst installieren:

node -v
npm -v
sudo npm install -g @openai/codex
codex --version

Die CLI ist Voraussetzung für den Remote-Login.

3. Device-Code-Login starten

codex login --device-auth

Dann erscheint eine Ausgabe dieser Art:

Open this link in your browser and sign in to your account
https://auth.openai.com/codex/device

Enter this one-time code
XXXX-XXXXX

Den Link lokal im Browser öffnen, einloggen, den Code eingeben, anmelden, fertig. OpenAI dokumentiert genau diesen Ablauf für Remote-Systeme.

4. Danach VSCodium neu verbinden

Wenn der Login auf dem Server erfolgreich war, kann die IDE-Erweiterung diese bestehende Codex-Anmeldung mitverwenden. CLI und IDE-Erweiterung teilen sich denselben Login-Zustand.

Der normale Browserflow hängt am lokalen Callback auf localhost:1455. Der Device-Code-Login umgeht genau diese Schwachstelle. Statt auf einen lokalen Port zu warten, authentifiziert sich die Remote-CLI über den im Browser bestätigten Einmalcode. Damit verschwindet die Abhängigkeit vom Tunnel, vom Loopback und von der lokalen Redirect-Kette.

Wo Codex die Anmeldung speichert

Codex verwendet als Konfigurationsverzeichnis ~/.codex. Laut OpenAI kann die Anmeldung entweder dateibasiert in ~/.codex/auth.json liegen oder im Credential Store gespeichert werden – abhängig von der Einstellung cli_auth_credentials_store. config.toml liegt ebenfalls in ~/.codex.

Wer eine klar sichtbare, dateibasierte Speicherung erzwingen will, kann in ~/.codex/config.toml setzen:

cli_auth_credentials_store = "file"

Dann ist die Anmeldung als Datei auf dem Server nachvollziehbar.

Der Einmalcode ist kein API-Key

Der angezeigte Gerätecode ist nur ein temporärer Login-Code. Er ist weder ein dauerhafter Schlüssel noch ein API-Key. Bei „Sign in with ChatGPT“ läuft Codex über den ChatGPT-Plan. Separate API-Abrechnung entsteht nur dann, wenn man sich bewusst mit API-Key anmeldet statt mit ChatGPT. OpenAI beschreibt diese beiden Modi ausdrücklich getrennt.

Für Plus, Pro, Business und Enterprise/Edu ist Codex im ChatGPT-Plan enthalten. Zusätzliche Credits betreffen nur flexible Mehrnutzung oberhalb des enthaltenen Umfangs, nicht den normalen Login per Device Code.