Вход через 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.

Вариант A: повторное использование команды получения учётных данных через вспомогательную программу запуска. Тот же ключ шлюза переносится из Authorization в X-Gateway-Key, а вход через ChatGPT обеспечивает содержимое Authorization.
Вариант A во время выполнения: шлюз проверяет и удаляет X-Gateway-Key, затем без изменений пересылает Authorization ChatGPT и идентификатор учётной записи, если он присутствует, серверной части Codex.

Вариант 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 для этого примера.

Вариант B: замена аутентификации на шлюзе с помощью API key встроенной поддержкой OAuth для шлюза в сочетании со входом через ChatGPT.
Вариант B во время выполнения: шлюз обрабатывает свой cookie OAuth и пересылает учётные данные ChatGPT серверной части Codex.

Добавление заголовков маршрутизации (необязательно)

В обоих вариантах 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/провайдера см. Совместимость шлюза и Развёртывание шлюза. Об этих управляемых настройках см. Управляемая конфигурация и Справочник по конфигурации.