Вход через ChatGPT с использованием шлюза
Зачем это нужно
Если у вас уже есть шлюз моделей и вы используете Codex с API Platform, вы можете сохранить шлюз при переходе на вход через ChatGPT. Это даёт доступ к доступным для вашего рабочего пространства ChatGPT функциям и средствам управления (например, голосовому режиму) с сохранением шлюза моделей. Сравнение способов входа приведено в разделе Доступность функций.
Как настроить
При существующей аутентификации с помощью команды ключ шлюза помещается в Authorization. При входе через ChatGPT этот заголовок содержит токен ChatGPT. Выберите способ передачи отдельных учётных данных шлюза:
- Вариант A: Повторно используйте команду получения учётных данных с помощью небольшой вспомогательной программы запуска. Передавайте тот же ключ шлюза в отдельном заголовке.
- Вариант B: Позвольте Codex получать учётные данные шлюза через встроенную поддержку OAuth.
Добавьте конфигурацию выбранного провайдера в управляемый из облака файл requirements.toml вашего рабочего пространства в разделе Управляемая конфигурация. Эти требования применяются после входа пользователей через ChatGPT и не ограничивают другие способы входа. Совместимый с Codex базовый URL шлюза должен проксировать /models и /responses на https://chatgpt.com/backend-api/codex.
Вариант A: повторное использование команды получения учётных данных с помощью вспомогательной программы
Сохраните существующую команду получения учётных данных. Небольшая вспомогательная программа выполняет её перед запуском Codex и экспортирует результат как GATEWAY_KEY. Это тот же ключ шлюза, который вы используете сейчас; меняется только заголовок, в котором он передаётся.
Например, существующая конфигурация API/провайдера может содержать:
# config.toml — existing API/provider setup
model_provider = "enterprise_gateway"
[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/v1"
requires_openai_auth = false
[model_providers.enterprise_gateway.auth]
command = "/usr/local/bin/fetch-gateway-token"Для входа через ChatGPT замените этого провайдера следующей управляемой конфигурацией. Удалите его блок auth: аутентификацию провайдера с помощью команды нельзя совмещать с requires_openai_auth = true.
# requirements.toml
model_provider = "enterprise_gateway"
[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/backend-api/codex" # Keep the gateway route.
requires_openai_auth = true # Use the ChatGPT credential for OpenAI.
env_http_headers = { "X-Gateway-Key" = "GATEWAY_KEY" } # Send the same gateway key separately.Используйте вспомогательную программу запуска, например эту функцию оболочки для CLI. Замените команду и аргументы значениями из существующего блока auth:
codex_with_gateway() (
set -eu
GATEWAY_KEY=$(/usr/local/bin/fetch-gateway-token)
test -n "$GATEWAY_KEY"
export GATEWAY_KEY
exec codex "$@"
)
codex_with_gatewayНастройте шлюз так, чтобы он принимал X-Gateway-Key, проверял ключ и удалял этот заголовок перед пересылкой запроса серверной части. Теперь запрос от клиента содержит:
Authorization: Bearer <ChatGPT token>
ChatGPT-Account-ID: <workspace ID, when available>
X-Gateway-Key: <same gateway key returned by your command>Вспомогательная программа выполняется один раз при каждом запуске. Codex не запускает её повторно и не обновляет этот заголовок; когда срок действия ключа истечёт, получите новый ключ и перезапустите Codex. Для настольного приложения ваша интеграция запуска должна передавать GATEWAY_KEY процессу приложения. Выберите вариант B, если хотите, чтобы Codex управлял входом на шлюз и обновлением токенов.
На схемах заголовки запросов и вспомогательная программа запуска показаны в сокращённом виде. Используйте Authorization: Bearer <ChatGPT token> и сохраните проверку на пустой ключ во вспомогательной программе из примеров выше. Если GATEWAY_KEY пуст, Codex не отправляет X-Gateway-Key.


Вариант B: встроенная поддержка OAuth для шлюза
Используйте этот вариант, чтобы заменить команду и вспомогательную программу запуска входом на шлюз под управлением Codex. У шлюза должен быть сервер авторизации OAuth. Зарегистрируйте публичный клиент, поддерживающий поток кода авторизации с PKCE, затем замените URL и идентификатор клиента из примера. Удалите блок auth существующего провайдера и используйте следующую управляемую конфигурацию.
# requirements.toml
model_provider = "enterprise_gateway"
[model_providers.enterprise_gateway]
name = "Enterprise gateway"
base_url = "https://gateway.example.com/backend-api/codex" # Keep the gateway route.
requires_openai_auth = true # Use the ChatGPT credential for OpenAI.
[model_providers.enterprise_gateway.gateway_oauth] # Add gateway OAuth.
authorization_url = "https://login.example.com/oauth/authorize"
token_url = "https://login.example.com/oauth/token"
client_id = "YOUR_PUBLIC_CLIENT_ID"
delivery = { kind = "cookie", name = "auth-openid" } # Add gateway auth as a cookie.
# redirect_port = 43127По умолчанию Codex использует свободный порт петлевого интерфейса. Если ваш провайдер идентификации требует фиксированный URI перенаправления, задайте redirect_port и зарегистрируйте http://127.0.0.1:43127/callback для этого примера.


Добавление заголовков маршрутизации (необязательно)
В обоих вариантах Codex может отправлять шлюзу пользовательские заголовки маршрутизации. Например, добавьте эти заголовки тому же провайдеру enterprise_gateway в управляемом из облака файле requirements.toml:
[model_providers.enterprise_gateway.http_headers]
x-portkey-config = "<gateway-routing-config-id>"
x-portkey-metadata = '{"tool_id":"codex"}'Codex отправляет заголовки в запросах к провайдеру моделей; шлюз применяет правила маршрутизации. Используйте env_http_headers для значений, считываемых из окружения процесса Codex. Выполните тестовый запрос, чтобы убедиться, что шлюз получает оба заголовка и выбирает нужный маршрут. Другие параметры заголовков описаны в разделе Пользовательские провайдеры моделей.
Разделяйте пути передачи учётных данных
Codex отправляет заголовок ChatGPT Authorization, заголовок ChatGPT-Account-ID, если он присутствует, и заголовок или cookie шлюза. Настройте шлюз так, чтобы он проверял и удалял собственные учётные данные, а затем пересылал заголовки ChatGPT без изменений.
Особенности и ограничения
- Используйте сборку Codex, поддерживающую управляемые требования к провайдерам моделей, а для варианта B — встроенную поддержку OAuth для шлюза. Старые сборки могут игнорировать или отклонять неподдерживаемые поля.
- Этот маршрут охватывает запросы через выбранного провайдера моделей. Вход через ChatGPT, MCP, плагины и другие подключения приложений могут использовать иные пути.
- Ваш шлюз видит данные запросов и оба набора учётных данных. Скрывайте их в журналах; никогда не пересылайте учётные данные шлюза вышестоящему сервису.
- Встроенная поддержка OAuth для шлюза требует браузера и доступного адреса обратного вызова на петлевом интерфейсе. Резервный вариант с кодом устройства отсутствует. Без токена обновления пользователям придётся повторять вход через браузер после истечения срока действия токена доступа.
- Стандартного ответа OpenAI
/v1/modelsнедостаточно: Codex ожидает массивmodels. Проверьте список моделей, отправку запроса и каждую функцию, используемую в вашем развёртывании.
Голосовая связь через шлюз
Эта настройка маршрутизирует запросы Codex к провайдеру моделей; она не включает ChatGPT Voice. В голосовых сеансах WebRTC создание вызова и соединение по дополнительному каналу используют отдельные маршруты. Экспериментальный параметр experimental_realtime_webrtc_call_base_url в ~/.codex/config.toml меняет только базовый HTTP URL для создания вызова. Он не перенаправляет соединение по дополнительному каналу, медиаданные или обычные запросы к моделям. Прежде чем использовать это переопределение, совместно с OpenAI проверьте адрес назначения вызова и обработку учётных данных, затем протестируйте полный голосовой сеанс.
О пути передачи учётных данных API/провайдера см. Совместимость шлюза и Развёртывание шлюза. Об этих управляемых настройках см. Управляемая конфигурация и Справочник по конфигурации.