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

Плагіни провайдерів із власним процесом 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. створіть токен, виконавши claude setup-token на будь-якому комп’ютері з Claude Code, а потім запустіть у OpenClaw налаштування за токеном або вставлення токена для Anthropic
  2. OpenClaw зберігає отримані облікові дані Anthropic у профілі автентифікації
  3. вибір моделі залишається на anthropic/...
  4. наявні профілі автентифікації Anthropic залишаються доступними для відкочування та керування порядком

OpenAI Codex (ChatGPT OAuth)

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

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

bash
openclaw models auth login --provider openai

Для кількох облікових записів ChatGPT/Codex OAuth в одному агенті використовуйте --profile-id openai:<name>. Не використовуйте 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