OpenAI Codex — App-Server provider (`codex-app-server`)

1. Architektur

┌─ OmniRoute-App ──────────────────┐        ┌─ codex-app-server-Sidecar ─────────┐
│  CodexAppServerExecutor          │  WS    │  codex app-server                   │
│  ws://codex-app-server:1456 ─────┼───────▶│  --listen ws://0.0.0.0:1456         │
│  (+ Berechtigungstoken)           │  JSON  │  --ws-auth capability-token         │
│                                  │  RPC   │  verwaltet OpenAI OAuth selbst      │
└──────────────────────────────────┘        │  (~/.codex/auth.json, autom. Aktual.)│
        │ gemeinsam genutzt                 └─────────────────────────────────────┘
        │ (Compose-Volumes)
        ▼
  codex-appserver-token   → das WS-Berechtigungstoken (von beiden eingebunden)
  codex-appserver-home    → ~/.codex (auth.json wird vom Dashboard geschrieben
                             und vom codex app-server des Sidecars gelesen)

• Der Sidecar lauscht nur im internen Compose-Netzwerk (ws://codex-app-server:1456) und ist durch ein Berechtigungstoken geschützt. Er wird niemals für den Host oder das Internet veröffentlicht.
• Die Codex CLI ist in omniroute:base integriert, sodass bei Verwendung des Sidecars keine Codex-Installation auf dem Host oder dem Rechner des Benutzers erforderlich ist.

2. Starten

# Stack MIT dem Sidecar-Profil für den codex app-server starten:
docker compose --profile base --profile codex-app-server up -d
# (podman: podman compose --profile base --profile codex-app-server up -d)

Der Sidecar erstellt beim ersten Start sein WS-Berechtigungstoken (im gemeinsam genutzten Volume codex-appserver-token), und die App liest dasselbe Token über OMNIROUTE_CODEX_APPSERVER_WS_TOKEN_FILE. Eine manuelle Token-Konfiguration ist nicht erforderlich.

3. Verbinden + anmelden

1. Füge im Dashboard eine Verbindung für OpenAI Codex (App-Server) hinzu. Es ist weder ein API-Schlüssel noch ein Token erforderlich (es handelt sich um einen Anbieter ohne Authentifizierung — der Sidecar übernimmt die Authentifizierung).
2. Falls die Codex CLI des Sidecars noch nicht angemeldet ist, meldet die Zustandsprüfung der Verbindung „läuft, aber nicht angemeldet“ (keinen roten Authentifizierungsfehler). Verwende Mit ChatGPT anmelden: Dadurch wird das standardmäßige Geräte-OAuth von Codex in deinem Browser ausgeführt und anschließend ~/.codex/auth.json über Authentifizierung anwenden in das gemeinsam genutzte Volume geschrieben (dieselbe Anmeldung dient sowohl dem Anbieter codex als auch codex-app-server).
3. Nach der Anmeldung wird die Zustandsprüfung grün (sie prüft sowohl /readyz als auch account/read — also, ob der Server aktiv und authentifiziert ist), und die Verarbeitung beginnt.

Das Dashboard überschreibt niemals eine intakte vorhandene ~/.codex/auth.json — es schreibt nur, wenn die Datei fehlt oder ihr Token veraltet ist (es wird immer eine Sicherung erstellt).

4. Bereitstellungsszenarien

• Betreiber mit einer bereits authentifizierten Codex CLI — binde dein ~/.codex vom Host in den Sidecar (codex-appserver-home) ein und überspringe den Anmeldeschritt.
• Öffentlicher Benutzer ohne lokal installiertes Codex — irrelevant: Der Sidecar enthält die CLI. Der Benutzer authentifiziert sich lediglich über das Dashboard.
• Bare-Metal-OmniRoute (kein Sidecar, Codex auf dem Host) — setze OMNIROUTE_CODEX_APPSERVER_WS auf deinen eigenen codex app-server und stelle sicher, dass Codex auf dem Host angemeldet ist; der Hinweis „Codex ist nicht installiert“ erscheint, wenn die Binärdatei fehlt.

5. Privater / UDP-Egress (optionale Betreiberkonfiguration, nicht enthalten)

Der generische Sidecar oben verwendet für den Egress das normale Netzwerk des Containers. Ein Betreiber, der den Codex-Datenverkehr über einen privaten Ausgangspunkt leiten muss (z. B. einen TUN-Tailscale-Sidecar, der TCP + UDP/QUIC transportiert), führt diesen als separate Compose-Überschreibung aus; er ist bewusst nicht Bestandteil des ausgelieferten Profils codex-app-server. Einzelheiten zu dieser Einrichtung findest du im internen Betriebshandbuch.

---

undefined (a58000c7685f)