OpenClawDocs
View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this page

Fundamentals

OAuth

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

  • Ключ API Anthropic: звичайна тарифікація API Anthropic.
  • 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)
  • де зберігаються токени (і чому)
  • як працювати з кількома обліковими записами (профілі та перевизначення для окремих сеансів)

Plugin постачальників, які мають власний процес 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