---
read_when:
    - Ви хочете зрозуміти OpenClaw OAuth від початку до кінця
    - Ви зіткнулися з проблемами анулювання токена / виходу з облікового запису
    - Вам потрібні потоки автентифікації Claude CLI або OAuth
    - Вам потрібні кілька облікових записів або маршрутизація профілів
summary: 'OAuth в OpenClaw: обмін токенами, зберігання та шаблони роботи з кількома обліковими записами'
title: OAuth
x-i18n:
    generated_at: "2026-04-29T11:04:03Z"
    model: gpt-5.5
    provider: openai
    source_hash: b4b228c83a79afa4018e9572f790ddfef016a73d2383d2847facdc5bb61ed004
    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 також підтримує **плагіни провайдерів**, які постачають власні потоки 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 використовує read-through
успадкування зі сховища стандартного/головного агента. Він не клонує
`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 як підтримуваний шлях token-auth, але тепер віддає перевагу повторному використанню Claude CLI і `claude -p`, коли вони доступні.

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

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

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

Інтерактивні потоки входу OpenClaw реалізовані в `@mariozechner/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. згенеруйте PKCE verifier/challenge + випадковий `state`
2. відкрийте `https://auth.openai.com/oauth/authorize?...`
3. спробуйте перехопити callback на `http://127.0.0.1:1455/auth/callback`
4. якщо callback не може прив’язатися (або ви працюєте віддалено/без headless), вставте URL/code перенаправлення
5. виконайте обмін на `https://auth.openai.com/oauth/token`
6. витягніть `accountId` з access token і збережіть `{ access, refresh, expires, accountId }`

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

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

Профілі зберігають timestamp `expires`.

Під час runtime:

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

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

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

Два шаблони:

### 1) Рекомендовано: окремі агенти

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

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

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

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

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

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

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

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

- `/model Opus@anthropic:work`

Як переглянути наявні ID профілів:

- `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) — ключі конфігурації автентифікації
