---
read_when:
    - Ви хочете зрозуміти OpenClaw OAuth від початку до кінця
    - У вас виникли проблеми з анулюванням токена / виходом із системи
    - Вам потрібні потоки автентифікації Claude CLI або OAuth
    - Вам потрібні кілька облікових записів або маршрутизація профілів
summary: 'OAuth в OpenClaw: обмін токенами, зберігання та патерни роботи з кількома обліковими записами'
title: OAuth
x-i18n:
    generated_at: "2026-05-11T20:33:24Z"
    model: gpt-5.5
    provider: openai
    source_hash: 2a7382fbcbe7e6034057da66a2dd8685df6d9345c36eeb8261eb12440d00a402
    source_path: concepts/oauth.md
    workflow: 16
---

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

- **API-ключ Anthropic**: звичайна оплата Anthropic API
- **Anthropic Claude CLI / автентифікація за підпискою всередині OpenClaw**: співробітники Anthropic
  повідомили нам, що це використання знову дозволене

OpenAI Codex OAuth явно підтримується для використання в зовнішніх інструментах, як-от
OpenClaw. Ця сторінка пояснює:

Для Anthropic у production API-ключ є безпечнішим рекомендованим шляхом.

- як працює **обмін токенів** OAuth (PKCE)
- де **зберігаються** токени (і чому)
- як працювати з **кількома обліковими записами** (профілі + перевизначення для окремих сесій)

OpenClaw також підтримує **провайдерські plugins**, які постачають власні потоки
OAuth або API-ключів. Запускайте їх через:

```bash
openclaw models auth login --provider <id>
```

## Приймач токенів (навіщо він існує)

Провайдери OAuth зазвичай випускають **новий refresh token** під час потоків входу/оновлення. Деякі провайдери (або клієнти OAuth) можуть інвалідовувати старі refresh tokens, коли для того самого користувача/застосунку випущено новий.

Практичний симптом:

- ви входите через OpenClaw _і_ через Claude Code / Codex CLI → один із них згодом випадково "виходить із системи"

Щоб зменшити це, OpenClaw розглядає `auth-profiles.json` як **приймач токенів**:

- runtime читає облікові дані з **одного місця**
- ми можемо зберігати кілька профілів і маршрутизувати їх детерміновано
- повторне використання зовнішнього CLI залежить від провайдера: Codex CLI може ініціалізувати порожній
  профіль `openai-codex:default`, але щойно OpenClaw має локальний профіль OAuth,
  локальний refresh token стає канонічним; інші інтеграції можуть залишатися
  керованими ззовні й повторно читати своє сховище автентифікації CLI
- шляхи статусу й запуску, які вже знають налаштований набір провайдерів, обмежують
  виявлення зовнішнього CLI цим набором, тож непов'язане сховище входу CLI не
  перевіряється для конфігурації з одним провайдером

## Зберігання (де живуть токени)

Секрети зберігаються у сховищах автентифікації агентів:

- Профілі автентифікації (OAuth + API-ключі + необов'язкові посилання рівня значень): `~/.openclaw/agents/<agentId>/agent/auth-profiles.json`
- Файл сумісності зі спадковими версіями: `~/.openclaw/agents/<agentId>/agent/auth.json`
  (статичні записи `api_key` очищаються, коли їх виявлено)

Файл лише для імпорту зі спадкових версій (досі підтримується, але не є основним сховищем):

- `~/.openclaw/credentials/oauth.json` (імпортується в `auth-profiles.json` під час першого використання)

Усе наведене вище також враховує `$OPENCLAW_STATE_DIR` (перевизначення каталогу стану). Повний довідник: [/gateway/configuration](/uk/gateway/configuration-reference#auth-storage)

Про статичні посилання на секрети та поведінку активації runtime-знімка див. [Керування секретами](/uk/gateway/secrets).

Коли вторинний агент не має локального профілю автентифікації, OpenClaw використовує наскрізне
успадкування зі сховища типового/основного агента. Під час читання він не клонує
`auth-profiles.json` основного агента. OAuth refresh tokens є особливо
чутливими: звичайні потоки копіювання типово пропускають їх, бо деякі провайдери обертають
або інвалідовують refresh tokens після використання. Налаштуйте окремий OAuth-вхід для
агента, коли йому потрібен незалежний обліковий запис.

## Сумісність зі спадковими токенами Anthropic

<Warning>
Публічна документація Claude Code від Anthropic каже, що пряме використання Claude Code лишається в межах
лімітів підписки Claude, а співробітники Anthropic повідомили нам, що використання Claude
CLI у стилі OpenClaw знову дозволене. Тому OpenClaw розглядає повторне використання Claude CLI і
використання `claude -p` як санкціоновані для цієї інтеграції, якщо Anthropic
не опублікує нову політику.

Поточну документацію Anthropic щодо планів для прямого Claude Code див. у [Використання Claude Code
з вашим планом Pro або Max](https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan)
та [Використання Claude Code з вашим планом Team або Enterprise](https://support.anthropic.com/en/articles/11845131-using-claude-code-with-your-team-or-enterprise-plan/).

Якщо вам потрібні інші варіанти у стилі підписки в OpenClaw, див. [OpenAI
Codex](/uk/providers/openai), [Qwen Cloud Coding
Plan](/uk/providers/qwen), [MiniMax Coding Plan](/uk/providers/minimax),
і [Z.AI / GLM Coding Plan](/uk/providers/glm).
</Warning>

OpenClaw також надає setup-token Anthropic як підтримуваний шлях автентифікації токеном, але тепер віддає перевагу повторному використанню Claude CLI і `claude -p`, коли вони доступні.

## Міграція Anthropic Claude CLI

OpenClaw знову підтримує повторне використання Anthropic Claude CLI. Якщо на хості вже є локальний
вхід Claude, onboarding/configure може повторно використати його напряму.

## Обмін OAuth (як працює вхід)

Інтерактивні потоки входу OpenClaw реалізовані в `@earendil-works/pi-ai` і під'єднані до майстрів/команд.

### setup-token Anthropic

Форма потоку:

1. запустіть setup-token Anthropic або paste-token з OpenClaw
2. OpenClaw зберігає отримані облікові дані Anthropic у профілі автентифікації
3. вибір моделі залишається на `anthropic/...`
4. наявні профілі автентифікації Anthropic лишаються доступними для rollback/керування порядком

### OpenAI Codex (ChatGPT OAuth)

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

Форма потоку (PKCE):

1. згенерувати verifier/challenge PKCE + випадковий `state`
2. відкрити `https://auth.openai.com/oauth/authorize?...`
3. спробувати перехопити callback на `http://127.0.0.1:1455/auth/callback`
4. якщо callback не вдається прив'язати (або ви працюєте віддалено/headless), вставити URL/код перенаправлення
5. виконати обмін на `https://auth.openai.com/oauth/token`
6. витягти `accountId` з access token і зберегти `{ access, refresh, expires, accountId }`

Шлях у майстрі: `openclaw onboard` → вибір автентифікації `openai-codex`.

## Оновлення + завершення строку дії

Профілі зберігають часову мітку `expires`.

Під час runtime:

- якщо `expires` у майбутньому → використати збережений access token
- якщо строк дії минув → оновити (під блокуванням файлу) і перезаписати збережені облікові дані
- якщо вторинний агент читає успадкований OAuth-профіль основного агента, оновлення
  записує назад у сховище основного агента, а не копіює refresh token у
  сховище вторинного агента
- виняток: деякі зовнішні облікові дані CLI залишаються керованими ззовні; OpenClaw
  повторно читає ці сховища автентифікації CLI замість витрачати скопійовані refresh tokens.
  Ініціалізація Codex CLI навмисно вужча: вона засіває порожній
  профіль `openai-codex:default`, а потім оновлення, якими володіє OpenClaw, підтримують локальний
  профіль канонічним.

Потік оновлення автоматичний; зазвичай вам не потрібно керувати токенами вручну.

## Кілька облікових записів (профілі) + маршрутизація

Два патерни:

### 1) Бажаний: окремі агенти

Якщо ви хочете, щоб "особисте" і "робоче" ніколи не взаємодіяли, використовуйте ізольованих агентів (окремі сесії + облікові дані + робочий простір):

```bash
openclaw agents add work
openclaw agents add personal
```

Потім налаштуйте автентифікацію для кожного агента (майстер) і маршрутизуйте чати до правильного агента.

### 2) Розширений: кілька профілів в одному агенті

`auth-profiles.json` підтримує кілька ідентифікаторів профілів для того самого провайдера.

Виберіть, який профіль використовується:

- глобально через порядок у конфігурації (`auth.order`)
- для окремої сесії через `/model ...@<profileId>`

Приклад (перевизначення сесії):

- `/model Opus@anthropic:work`

Як подивитися, які ідентифікатори профілів існують:

- `openclaw channels list --json` (показує `auth[]`)

Пов'язана документація:

- [Відмовостійке перемикання моделей](/uk/concepts/model-failover) (правила ротації + cooldown)
- [Slash-команди](/uk/tools/slash-commands) (поверхня команд)

## Пов'язане

- [Автентифікація](/uk/gateway/authentication) - огляд автентифікації провайдера моделей
- [Секрети](/uk/gateway/secrets) - зберігання облікових даних і SecretRef
- [Довідник конфігурації](/uk/gateway/configuration-reference#auth-storage) - ключі конфігурації автентифікації