Codex mit dem MCP-Gateway verbinden

Codex mit JanuaPort verbinden

Codex verbindet sich von Ihrem Rechner aus mit JanuaPort, per Streamable HTTP und mit einem eigenen Token. Welche Werkzeuge Codex sieht, legt Ihr Admin fest. Jeder Aufruf steht im Protokoll.

Belegt am 30.10.2026 mit Codex CLI 0.162.1 an JanuaPort 0.89.0: lesende Werkzeuge per Token, im Protokoll mit Status ok. Ungetestet: Anmeldung per OAuth/SSO, schreibende Werkzeuge und Sichten.

Token vom Admin

Ihr Admin stellt einen eigenen Token für diesen Zugang aus, in der Admin-GUI, per Kommandozeile oder über den Admin-MCP. Der Token zählt als eigene Identity. Geben Sie ihm einen Namen wie codex-<name> und ein Ablaufdatum, dann erkennen Sie ihn im Protokoll wieder. Ohne Freigabe sieht Codex kein Werkzeug.

Eintrag in der config.toml

Der Token steht nie in der Konfigurationsdatei, nur in einer Umgebungsvariable.

export JANUAPORT_TOKEN="jnpt_<id>_<secret>"

$env:JANUAPORT_TOKEN = "jnpt_<id>_<secret>"

[mcp_servers.januaport]
url = "https://<ihre-anlage>/mcp"
bearer_token_env_var = "JANUAPORT_TOKEN"   # Codex liest das Token aus dieser Umgebungsvariable

Erster Aufruf

Rufen Sie ein lesendes Werkzeug auf, zum Beispiel januaport/ping. Der Aufruf erscheint im Protokoll unter dem Namen des Tokens.

codex exec "Rufe januaport/ping auf und zeige das Ergebnis."

Für schreibende Werkzeuge lassen Sie die Freigabe-Rückfrage von Codex eingeschaltet.

Häufige Fragen

Funktioniert Codex mit Anmeldung über SSO?

Das ist noch nicht geprüft. Codex kennt eine Anmeldung per OAuth (codex mcp login), an einer Anlage mit SSO haben wir sie aber noch nicht getestet. Bis dahin nutzen Sie einen eigenen Token.

Warum steht der Token nicht in der config.toml?

Damit er nicht in einer Datei landet, die kopiert oder in ein Repository gelegt wird. Codex liest ihn aus der Umgebungsvariable, die unter bearer_token_env_var steht.