Codex-Kontoauswahl und Laufzeit

codex-current ist der kanonische Einstieg für neue Codex-Prozesse auf dem Server. Er verhindert, dass ein Auftrag selbstständig einen beliebigen Accountwrapper auswählt, und bricht bei einer unvollständigen selektierten Laufzeit ab.

WPMCP00: Anmeldung ohne vorhandene auth.json

Am 5. September 2026 wurde auf wpmcp00 der kanonische Anmeldeweg repariert. Zuvor verlangte der Dispatcher bereits eine Anmeldung, bevor er den offiziellen CLI-Login starten konnte. Der Kompatibilitätsaufruf im Helper-Verzeichnis zeigte zusätzlich auf den anderen Server. Beide Ursachen wurden korrigiert.

~/.local/bin/codex-current --login-preflight
~/.local/bin/codex-current login --device-auth

login und logout prüfen weiterhin den gewählten Account, beide Runtime-Dateien einschließlich SHA-256, Versionsgleichheit und die kanonische AGENTS-Topologie. Nur die Voraussetzung einer bereits gültigen Anmeldung entfällt. Eine vorhandene Authentifizierungsdatei muss weiterhin regulär, privat und dem Benutzer zugeordnet sein. Die offizielle CLI erzeugt die fehlende Datei; Platzhalter, Kopien anderer Accounts und manuelle Tokenänderungen sind kein Teil der Reparatur.

--login-preflight meldet login_ready: true und runtime_deep_verified: true, aber deep_verified: false: Dies bestätigt die Laufzeit, keine erfolgreiche Anmeldung. Normale Jobs verlangen unverändert Authentifizierung. Nach dem interaktiven Login sind normaler Preflight und ein echter kleiner Codex-Auftrag erforderlich.

Die installierte Reparatur wurde mit echter Runtime, Login-Hilfe und Logged-out-Status geprüft. Normale Aufrufe blieben vor Anmeldung gesperrt. Die Account-Auswahl und Zugangsdaten wurden nicht verändert. Ein einzelner Rollback enthält nur die drei vorherigen Code-Dateien mit insgesamt rund 22 KB.

Die inzwischen erfolgreichen PHP-MCP-Transporttests auf wpmcp00 benötigen keinen Codex-Auftrag. Sie ersetzen deshalb weder die offizielle Anmeldung noch den anschließenden echten Codex-Funktionstest.

Kanonische Pfade auf wpmcp

Die Registry bleibt vorerst beim kompatiblen Schema 2 mit ausgerichteten Listen. Position 0 ist die bewusste aktuelle Auswahl. Ein Schemawechsel darf erst erfolgen, wenn Stage, Test, Active, Fallback und alle Responses-Adapter auf einen neuen Vertrag migriert sind.

Start eines Prozesses

1. Der Dispatcher nimmt einen Shared Lock auf Registry und Auswahlstatus.
2. Er validiert das feste Accountlayout ohne Symlink-Ausbruch.
3. Er prüft, dass die globale Anleitung eine private reguläre Datei am kanonischen Pfad ist und alle globalen Spiegel als exakte Symlinks dorthin auflösen.
4. Er prüft Accountwrapper, auth.json, Runtime-Manifest, CLI-Binary und codex-code-mode-host auf Vollständigkeit und Versionsgleichheit.
5. Er ermittelt Wrapper, HOME, CODEX_HOME, Profil und Registry-Fingerabdruck als einen zusammengehörigen Snapshot.
6. Nach Freigabe des Locks startet er genau diesen Wrapper per exec.

Ein späterer Switch beeinflusst den bereits gestarteten Prozess nicht. Queue- und Adapterjobs müssen dieselbe Snapshot-Semantik für Start, Polling und Fortsetzung beibehalten. Eine Registry-Umsortierung ändert ihren Fingerabdruck und ist deshalb als mögliche Sitzungsgrenze zu behandeln.

Channel Manager und Telegram-Aufträge

Der Channel Manager fragt beim Erzeugen einer neuen Codex-Sitzung den aktuell selektierten Account-Snapshot des Responses-Adapters über den probe-freien Endpunkt GET /v1/codex/accounts/selected ab. Der Endpunkt liest Registry und Auswahl atomar, ohne alle registrierten Konten seriell anzumelden. Der Snapshot wird für Thread, Job, Polling und Fortsetzung eingefroren. Ein späterer Accountwechsel verschiebt daher keinen laufenden Telegram-Auftrag; erst eine neu erzeugte Sitzung übernimmt die dann aktuelle Auswahl. Ältere Adapter ohne den neuen Endpunkt bleiben über einen eng begrenzten 404-Fallback zum vollständigen Katalog kompatibel.

Der Telegram-Einstieg verwendet codex:gpt-5.6-luna mit Reasoning low als leichten Koordinator. Dieser kann mit dem gescopteten MCP-Tool session_create einen separaten Folgejob anlegen und dessen Modell und Reasoning aus dem dynamischen Adapterkatalog wählen. Auch dieser neue Thread erhält beim Start einen eigenen aktuellen Account-Snapshot und behält ihn bis zum Abschluss. Modellbezeichner am Responses-Adapter sind immer providerqualifiziert, beispielsweise codex:gpt-5.6-sol.

Vor Telegram-Ingest bindet der Channel Manager die Source an den privaten Zugriffsstatus owner oder allowlisted. Unbekannte und gesperrte Absender erreichen den Account-Snapshot und Codex-Adapter nicht. session_create trägt zusätzlich den kleinsten benötigten Scope conversation, stage oder server. Für Stage und Server müssen sowohl das aktuelle Registry-Recht als auch der getrennt konfigurierte Workspace vorhanden sein. Der Dispatcher liest die Registry vor jedem Start erneut; Ban oder Rechteentzug wirken deshalb auch gegen wartende Aufträge. Nur der Owner kann die Registry über die gescopteten Tools verändern. Identitäten und Profile bleiben außerhalb dieses Wiki.

Der Thread-Start ist ein möglicher Cold Start. Der Channel Manager verwendet dafür ein auf 120 Sekunden begrenztes Timeout und einen stabilen, nicht personenbezogenen Idempotency-Key. Ein Timeout kann dadurch sicher erneut versucht werden, ohne doppelte Threads anzulegen. Im Live-Smoke antwortete der neue Snapshot-Endpunkt in rund 0,2 Sekunden; ein separater Folgejob mit frei gewähltem Modell und Reasoning wurde anschließend erfolgreich angelegt und abgeschlossen.

Vor Deployment und Ende-zu-Ende-Prüfung dieses Pfads bleiben codex-current --status und codex-current --preflight Pflicht. Der service-spezifische Resolver dient danach ausschließlich dazu, den bestätigten Snapshot für einen laufenden Job unveränderlich fortzuführen.

Preflight und Status

• codex-current --status
• codex-current --preflight
• codex --version

--status prüft den ausgewählten Pfad ohne Netzwerkaufruf. --preflight ergänzt die SHA-256-Prüfung des Runtime-Bundles und einen begrenzten lokalen Login-Status. Beide Prüfungen validieren außerdem die kanonische globale Anleitung und sämtliche registrierten Symlinks. Eine Kopie statt eines Links, ein abweichendes oder relatives Ziel, ein defekter Link oder ein Pfadausbruch beendet den Start fail-closed. Auch bei einer inkonsistenten oder abgemeldeten Auswahl ist ein stiller Wechsel auf einen anderen Account verboten. Die Statusausgabe ist privat zu behandeln, da sie den ausgewählten Profilnamen enthalten kann.

Erhaltene Fallbackrouten

Fallback ist keine automatische Accountwahl

Direkte Routen bleiben für Diagnose, Reparatur, Reauthentifizierung und kontrollierten Rollback erhalten. Neue Aufträge dürfen sie nicht verwenden, um die zentrale Auswahl zu umgehen.

Anweisungen für Codex

Die einzige reguläre globale Anleitung liegt unter /home/wpmcp/codex-projects/AGENTS.md. Die folgenden globalen Ladeorte sind ausschließlich absolute Symlinks, deren Rohziel und vollständig aufgelöstes Ziel exakt diese Datei sein müssen:

• /home/wpmcp/codex-accounts/AGENTS.md
• jedes registrierte CODEX_HOME/AGENTS.md
• /home/wpmcp/.codex/AGENTS.md für die Standalone-Runtime

So gibt es keine auseinanderlaufenden globalen Kopien. Der Installer sichert vorhandene Dateien oder Links einzeln und ersetzt nur diese bekannten globalen Ladeorte. Repository-spezifische AGENTS.md-Dateien unterhalb der einzelnen Projekte bleiben reguläre, konkretere Projektanweisungen und werden weder verlinkt noch überschrieben.

Im öffentlichen Wiki stehen weder Profilnamen noch Zugangsdaten, Auth-Dateien oder private Sitzungsinhalte.