Fundamentals

OAuth

OpenClaw поддерживает OAuth («аутентификацию по подписке») для провайдеров, которые его предлагают, в частности OpenAI Codex (ChatGPT OAuth) и повторное использование Anthropic Claude CLI. Для Anthropic практическое разделение выглядит так:

  • API-ключ Anthropic: обычная тарификация Anthropic API.
  • Anthropic Claude CLI / аутентификация по подписке в OpenClaw: сотрудники Anthropic сообщили нам, что такое использование снова разрешено, поэтому OpenClaw считает повторное использование Claude CLI и использование claude -p разрешёнными для этой интеграции, если Anthropic не опубликует новую политику. Для использования Anthropic в рабочей среде аутентификация с помощью API-ключа по-прежнему остаётся более безопасным рекомендуемым вариантом.

OpenClaw хранит как аутентификацию по API-ключу OpenAI, так и ChatGPT/Codex OAuth под каноническим идентификатором провайдера openai. Старые идентификаторы профилей openai-codex:* и записи auth.order.openai-codex являются устаревшим состоянием, исправляемым командой openclaw doctor --fix; для новой конфигурации используйте идентификаторы профилей openai:* и auth.order.openai.

На этой странице рассматривается:

  • как работает обмен токенами OAuth (PKCE)
  • где хранятся токены (и почему)
  • как работать с несколькими учётными записями (профили и переопределения для отдельных сеансов)

Плагины провайдеров, предоставляющие собственный процесс OAuth или API-ключа, используют ту же точку входа:

bash
openclaw models auth login --provider <id>

Приёмник токенов (зачем он нужен)

Провайдеры OAuth часто создают новый токен обновления при каждом входе или обновлении. Некоторые провайдеры аннулируют предыдущий токен обновления при выдаче нового для того же пользователя и приложения. Практический симптом: вы входите через OpenClaw и через Claude Code / Codex CLI, после чего один из них случайным образом выходит из учётной записи.

Чтобы снизить вероятность этого, OpenClaw использует хранилище профилей аутентификации как приёмник токенов:

  • среда выполнения считывает учётные данные каждого агента из одного места
  • несколько профилей могут сосуществовать и маршрутизироваться детерминированно
  • повторное использование внешнего CLI зависит от провайдера: когда OpenClaw становится владельцем локального профиля OAuth для провайдера, локальный токен обновления становится каноническим. Если этот локальный токен обновления отклонён, OpenClaw сообщает, что профиль требует повторной аутентификации, вместо возврата к токенам внешнего CLI. Первичная инициализация из Codex CLI ещё более ограничена: она может только заполнить пустой профиль вида openai:default, прежде чем OpenClaw станет владельцем OAuth для этого провайдера; после этого обновления, выполняемые OpenClaw, остаются каноническими
  • пути проверки состояния и запуска ограничивают обнаружение внешних CLI набором уже настроенных провайдеров, поэтому при конфигурации с одним провайдером хранилище входа постороннего CLI не проверяется

Хранилище (где находятся токены)

Секреты хранятся отдельно для каждого агента под логическим именем auth-profiles.json (базовым хранилищем служит база данных SQLite агента; имя JSON сохранено для совместимости и отображения в инструментах):

  • Профили аутентификации (OAuth + API-ключи + необязательные ссылки на уровне значений): ~/.openclaw/agents/<agentId>/agent/auth-profiles.json
  • Устаревший файл совместимости: ~/.openclaw/agents/<agentId>/agent/auth.json (статические записи api_key удаляются при обнаружении)

Устаревший файл только для импорта (по-прежнему поддерживается, но не является основным хранилищем):

  • ~/.openclaw/credentials/oauth.json (импортируется в хранилище профилей аутентификации при первом использовании)

Все перечисленные выше пути также учитывают $OPENCLAW_STATE_DIR (переопределение каталога состояния). Полное справочное описание: /gateway/configuration-reference#auth-storage

Сведения о статических ссылках на секреты и поведении активации снимков среды выполнения см. в разделе Управление секретами.

Если у дополнительного агента нет локального профиля аутентификации, OpenClaw использует сквозное наследование из хранилища агента по умолчанию или основного агента; при чтении хранилище основного агента не клонируется. Токены обновления OAuth особенно чувствительны: обычные операции копирования по умолчанию пропускают их, поскольку некоторые провайдеры заменяют или аннулируют токены обновления после использования. Настройте отдельный вход OAuth для агента, если ему требуется независимая учётная запись.

Повторное использование Anthropic Claude CLI

OpenClaw поддерживает повторное использование Anthropic Claude CLI и claude -p как разрешённый способ аутентификации. Если на хосте уже выполнен локальный вход в Claude, процессы первоначальной настройки и конфигурирования могут использовать его напрямую. Токен настройки Anthropic по-прежнему доступен как поддерживаемый способ аутентификации по токену, но OpenClaw предпочитает повторное использование Claude CLI, когда оно доступно.

Обмен OAuth (как работает вход)

Интерактивные процессы входа OpenClaw реализованы в openclaw/plugin-sdk/llm.ts и подключены к мастерам и командам.

Токен настройки Anthropic

Схема процесса:

  1. запустите получение токена настройки Anthropic или вставьте токен из OpenClaw
  2. OpenClaw сохраняет полученные учётные данные Anthropic в профиле аутентификации
  3. при выборе модели продолжает использоваться anthropic/...
  4. существующие профили аутентификации Anthropic остаются доступными для отката и управления порядком

OpenAI Codex (ChatGPT OAuth)

OAuth OpenAI Codex явно поддерживается для использования вне Codex CLI, в том числе в рабочих процессах OpenClaw.

Команда входа использует канонический идентификатор провайдера OpenAI:

bash
openclaw models auth login --provider openai

Используйте --profile-id openai:<name> для нескольких учётных записей ChatGPT/Codex OAuth в одном агенте. Не используйте openai-codex:<name> для новых профилей. Doctor преобразует этот старый префикс в идентификатор профиля openai:*, исключающий коллизии; после исправления запустите openclaw models auth list --provider openai, прежде чем копировать идентификаторы профилей в auth.order или /model ...@<profileId>.

Схема процесса (PKCE):

  1. создайте проверочную строку и проверочное значение PKCE, а также случайное значение state
  2. откройте https://auth.openai.com/oauth/authorize?... (область доступа openid profile email offline_access)
  3. попытайтесь принять обратный вызов на http://localhost:1455/auth/callback (по умолчанию хостом обратного вызова является localhost, и допускаются только хосты обратной петли; переопределите его с помощью OPENCLAW_OAUTH_CALLBACK_HOST)
  4. если вы можете вставить код до получения обратного вызова (либо работаете удалённо или без графического интерфейса и привязка обратного вызова невозможна), вместо этого вставьте URL-адрес перенаправления или код — ручная вставка конкурирует с обратным вызовом браузера, и используется вариант, завершившийся первым
  5. обменяйте код через https://auth.openai.com/oauth/token
  6. извлеките accountId из токена доступа и сохраните { access, refresh, expires, accountId }

Путь в мастере: openclaw onboard → вариант аутентификации openai.

Обновление и истечение срока действия

Профили хранят временную метку expires. Во время выполнения:

  • если expires находится в будущем, используется сохранённый токен доступа
  • если срок действия истёк, токен обновляется (с блокировкой файла), а сохранённые учётные данные перезаписываются
  • если дополнительный агент считывает унаследованный профиль OAuth основного агента, результат обновления записывается обратно в хранилище основного агента, а токен обновления не копируется в хранилище дополнительного агента
  • учётные данные CLI под внешним управлением (Claude CLI и ограниченная первичная инициализация из Codex CLI; см. Приёмник токенов) считываются заново вместо использования скопированного токена обновления. Если управляемое обновление завершается с ошибкой, OpenClaw сообщает, что затронутый профиль требует повторной аутентификации, вместо возврата токенов внешнего CLI.

Обновление выполняется автоматически; обычно управлять токенами вручную не требуется.

Несколько учётных записей (профилей) и маршрутизация

Два варианта:

1) Предпочтительный: отдельные агенты

Если вы хотите, чтобы «личная» и «рабочая» среды никогда не взаимодействовали, используйте изолированных агентов (отдельные сеансы, учётные данные и рабочие пространства):

bash
openclaw agents add workopenclaw agents add personal

Затем настройте аутентификацию отдельно для каждого агента (с помощью мастера) и направляйте чаты соответствующему агенту.

2) Расширенный: несколько профилей в одном агенте

Хранилище профилей аутентификации поддерживает несколько идентификаторов профилей для одного провайдера. Выберите используемый профиль:

  • глобально с помощью порядка в конфигурации (auth.order)
  • для отдельного сеанса с помощью /model ...@<profileId>

Пример (переопределение для сеанса):

  • /model Opus@anthropic:work

Выведите существующие идентификаторы профилей командой:

bash
openclaw models auth list --provider <id>

Связанная документация:

Связанные разделы

Was this useful?
On this page

On this page