Failed to refresh OAuth token в Claude Code: перевод и решение

Сообщение Failed to refresh OAuth token: another Claude Code process is refreshing it or exited mid-refresh по-русски значит: «Не удалось продлить токен OAuth: другой процесс Claude Code сейчас продлевает его или завершился посреди продления. Обычно это временно — повторите через минуту, а если не проходит, закройте другие процессы Claude Code или войдите заново». Вход при этом не отклонён. Сохранённый вход в claude.ai истёк и его нужно было продлить, но продление на этой же машине заняла другая копия Claude Code, и запрос остановили ещё до отправки — так ошибку описывает справочник ошибок Claude Code.

«Занято» здесь — это пустая папка ~/.claude/.oauth_refresh.lock (иногда вторая, ~/.claude.lock). Действуйте по порядку: подождите минуту и повторите команду; если ошибка возвращается, закройте другие окна и процессы Claude Code; если других процессов нет, а пустая папка блокировки старше минуты и не меняется, удалите её командой rmdir; если не помогло и это, выполните /login. Файл .credentials.json и запись в Связке ключей macOS не трогайте: их удаление как раз и разлогинит.

Минута в тексте ошибки взята не с потолка. В проверке 12 ноября 2026 года на Claude Code 2.1.316 под macOS брошенная блокировка снималась сама, когда её больше минуты никто не обновлял. Исключений два: на Windows пользователи сообщают о папке, которая не исчезает и через три минуты, а после скачка системных часов назад дата папки оказывается в будущем, и сама она уже не снимется. В обоих случаях помогает ручное удаление пустой папки.

Что значит «another Claude Code process is refreshing it» и чем это не является

Ошибка значит, что Claude Code ждал, пока другой его процесс продлит общий вход, и не дождался. В официальном разделе о входе и истёкших токенах Anthropic пишет, что параллельные сессии на одной машине используют один сохранённый вход и договариваются о продлении так, чтобы токен продлевал только один процесс за раз. Тот, кто продлевает, держит блокировку; остальные ждут. Если держатель завис или вышел, не сняв блокировку, ожидающий сдаётся и показывает это сообщение.

У ошибки две формы с одним смыслом. В интерактивной сессии:

Could not refresh your login because another Claude Code process is refreshing it (or exited mid-refresh) · Try again in a minute; if it keeps happening, close other Claude Code windows or sign in again with /login

В неинтерактивном режиме claude -p и в Agent SDK, где структурный код ошибки — server_error:

Failed to refresh OAuth token: another Claude Code process is refreshing it or exited mid-refresh. This is usually transient; retry in a minute, and if it persists close other Claude Code processes or sign in again

Блокировку часто называют lock-файлом, но на деле это три элемента. Их удалось увидеть 12 ноября 2026 года, пока Claude Code 2.1.316 продлевал вход; после нормального выхода процесса исчезли все три.

Если задана переменная CLAUDE_CONFIG_DIR, всё переезжает: папка и файл владельца лежат внутри указанной папки настроек, а вторая блокировка — рядом с ней под именем <папка>.lock.

Соседние сообщения похожи, но решаются иначе. Failed to authenticate: OAuth session expired and could not be refreshed значит, что продление состоялось и не удалось; это разобрано в статье Claude: Temporarily unable to authenticate — ждать или чинить. Если та же фраза начинается с Error during compaction:, смотрите Ошибка сжатия Claude Code: как починить /compact по тексту ошибки. А если после Failed to refresh OAuth token: говорится о заполненном диске (the disk that holds the Claude Code config directory … is full), блокировка ни при чём: по справочнику ошибок нужно освободить место на диске с ~/.claude, повторный вход не поможет.

Почему «через минуту»: брошенная блокировка устаревает за 60 секунд

Минута — это срок, после которого Claude Code считает блокировку брошенной. В коде версии 2.1.316 держатель обновляет дату изменения папки каждые 5 секунд, а папку, которую не обновляли дольше 60 секунд, следующий процесс удаляет сам. Ожидающий процесс делает пять попыток с паузой 1–2 секунды, затем 7,5 секунды смотрит, меняется ли дата папки, и только если она стоит на месте, выводит эту ошибку. Отсюда практический вывод: само сообщение почти всегда означает, что блокировка не двигается, то есть держатель завис или уже вышел.

Проверка 12 ноября 2026 года выполнялась на одном Mac: Claude Code 2.1.316, команда claude -p, фиктивные учётные данные в отдельной папке настроек через CLAUDE_CONFIG_DIR, настоящий вход не использовался. С только что созданной пустой папкой блокировки, которую никто не обновлял, ошибка появлялась примерно через 8 секунд (7,9; 8,0; 8,6 с) с кодом выхода 1, и немедленный повтор давал то же. Через 65 секунд после создания той же папки Claude Code снял её сам и пошёл обычным путём продления, а папку с датой изменения 5 минут назад снял сразу. Папку с датой на 30 дней вперёд он не снял и через 65 секунд; после rmdir следующий запуск сразу прошёл обычным путём. Одной свежей второй блокировки <папка>.lock хватало для той же ошибки примерно через 7,9 секунды.

Когда же скрипт обновлял дату папки каждые 2 секунды, изображая живого держателя, этой ошибки не было вовсе: через 35 секунд Claude Code перестал ждать и отправил запрос со старым токеном. Значит, при живом держателе вы увидите не это сообщение, а задержку и, если вход к тому времени так и не продлён, другую ошибку аутентификации.

Не проверялись Windows, гонка двух процессов с настоящим входом, снятие второй блокировки через минуту и перехват блокировки у мёртвого процесса по файлу владельца. Последний путь в коде 2.1.316 есть, но включается удалённым флагом, состояние которого для конкретного аккаунта неизвестно. Поэтому с версии 2.1.282, где Anthropic исправила ошибку, длившуюся «до минуты» после закрытия или аварийного завершения держателя, восстановление у вас может пройти быстрее минуты, а может и нет.

Как посмотреть, кто держит блокировку, ничего не меняя

Понять, есть ли блокировка, жив ли её держатель и двигается ли она, можно за полминуты одними командами чтения. Именно о таких оставшихся после сбоя файлах блокировки спрашивал сотрудник Anthropic в issue #79688 на GitHub о сбое расширения VS Code при первом запуске за день. Команды ниже для пути по умолчанию; с CLAUDE_CONFIG_DIR подставьте свою папку.

1. Проверьте, есть ли блокировки и пусты ли они: ls -ld ~/.claude/.oauth_refresh.lock ~/.claude.lock, затем ls -A ~/.claude/.oauth_refresh.lock (пустой вывод — папка пуста). Если обеих папок нет, держатель уже закончил, и достаточно повторить команду.
2. Посмотрите возраст папки и сравните с текущим временем: date; stat -f '%Sm' ~/.claude/.oauth_refresh.lock на macOS или date; stat -c '%y' ~/.claude/.oauth_refresh.lock в Linux. Повторите через 10 секунд. Дата сдвинулась — держатель жив и работает, ждите. Не сдвинулась и старше минуты — блокировка брошена. Дата впереди текущего времени — блокировка «из будущего», сама она не снимется.
3. Прочитайте файл владельца: cat ~/.claude/.oauth_refresh.lock.owner. В нём pid, procStart в формате вывода ps и pidSpace с именем компьютера; если имя чужое (общая домашняя папка, контейнер), держатель работает на другой машине. В вашей версии файла может и не быть: в проверке выше ошибку вызывала и папка без него.
4. Проверьте процесс по номеру из файла: ps -p <pid> -o pid,lstart,command. Процесса нет — держатель мёртв. Процесс есть, но время запуска не совпадает с procStart — номер уже достался другой программе. Совпадает — в колонке command видно, кто держит: расширение VS Code, --chrome-native-host, claude auth status или ваш скрипт.
5. Посмотрите все процессы Claude Code: pgrep -fl claude. Шаблон ловит и чужие программы, в командной строке которых есть «claude», например настольное приложение Claude, поэтому выбирайте в выводе конкретные номера.

На Windows то же самое показывают Get-ChildItem "$HOME\.claude" -Force -Filter ".oauth_refresh.lock*" | Select-Object Name, LastWriteTime, Get-Item "$HOME\.claude.lock" -Force и Get-Process -Id <pid>.

Какой у меня случай: причины по тому, что было перед ошибкой

Причину проще всего определить по тому, что вы делали прямо перед ошибкой, и по результату проверок выше. Все строки — сообщения пользователей в issue на GitHub с указанными версиями; поведение папки с датой в будущем и второй блокировки дополнительно воспроизведено в проверке 12 ноября 2026 года.

Если подключение Claude in Chrome ещё не настроено как следует, начните со статьи Расширение Claude in Chrome: установка и подключение Claude Code. Если в VS Code непонятно, под каким аккаунтом вообще работает расширение, поможет Как проверить аккаунт Claude Code в VS Code: /status, логин и API-маршрут.

Как убрать ошибку: от ожидания до /login

Безопасный порядок — от действий, которые ничего не меняют, к повторному входу; на каждом шаге проверяйте, ушла ли ошибка, и дальше не идите. Первые два шага и четвёртый — официальные рекомендации справочника ошибок Claude Code, третий — решение авторов отчётов на GitHub, совпавшее с проверкой 12 ноября 2026 года.

1. Подождите минуту и повторите команду. Если другой процесс успеет продлить вход, ваша сессия просто возьмёт продлённый вход; брошенная блокировка за это время устаревает.
2. Закройте другой процесс Claude Code. Закрывайте конкретное окно или процесс, номер которого нашли в файле владельца или в pgrep: kill <pid> на macOS и Linux, Stop-Process -Id <pid> на Windows. Затем повторите команду.
3. Удалите пустую папку блокировки, если её никто не держит. Делайте это, только когда процессов Claude Code нет, папка пуста и её дата не меняется: rmdir ~/.claude/.oauth_refresh.lock, а если осталась вторая — rmdir ~/.claude.lock. На Windows: Remove-Item "$HOME\.claude\.oauth_refresh.lock". Команда rmdir не удаляет непустые папки, поэтому лишнего не заденет. В отчёте #95236 о блокировке на Windows следующий claude -p после удаления прошёл за 3,3 секунды, а в отчёте #95739 о блокировке с датой в будущем продление сразу заработало с теми же сохранёнными учётными данными.
4. Выполните /login в интерактивной сессии или claude auth login в терминале. По справочнику ошибок новый вход не ждёт блокировку продления, поэтому это последний шаг, если ошибка возвращается при отсутствии других процессов.

Удалять ли .credentials.json и Связку ключей из-за этой ошибки

Нет. Справочник ошибок Claude Code прямо говорит, что это сообщение не означает отказа во входе: мешает блокировка, а не сохранённый вход. По сообщениям пользователей на GitHub, вход лежит в %USERPROFILE%\.claude\.credentials.json на Windows, в ~/.claude/.credentials.json в Linux и контейнерах, а на macOS — в Связке ключей под именем Claude Code-credentials. Удалив их, вы получите настоящий выход из аккаунта вместо временной ошибки, а блокировка останется на месте. Переустанавливать Claude Code справочник тоже не предлагает: его шаги — подождать, закрыть другие процессы и войти заново. Отдельно о команде pkill -f claude, которую советуют в общих инструкциях: она завершает все процессы, в командной строке которых встречается «claude», включая настольное приложение Claude и чужие скрипты. Закрывайте процессы по номеру.

Claude Code на Windows: папка блокировки может не исчезать сама

На macOS брошенная блокировка в проверке 12 ноября 2026 года снималась сама через минуту, но с Windows приходят другие сообщения. Автор issue #95236 на Windows 11 и версии 2.1.272 запускал пакеты claude -p, подождал 180 секунд, получил ту же ошибку и вылечил её только удалением пустой папки; другой пользователь описал то же в Linux внутри песочницы Docker. Почему правило минуты там не срабатывает, неизвестно, и после обновления автор сбоя больше не видел, но оговорился, что воспроизвести его по требованию не мог и раньше. В issue #91708 пользователи Windows описывают ещё и EPERM при создании папки блокировки, после которого приходится входить заново каждое утро; строки об исправлении EPERM в журнале изменений нет. Ещё одна мелочь Windows — файлы .oauth_refresh.lock.owner.tmp.*, которые в issue #108764 накопились до 811 штук, хотя, по словам автора, ничего не ломали.

В каких версиях Claude Code это исправляли и что ещё открыто

Anthropic несколько раз меняла поведение этой блокировки; ниже строки из журнала изменений Claude Code (CHANGELOG.md на GitHub) с датами выпуска. Свою версию покажет claude --version, обновит — claude update.

По состоянию на 12 ноября 2026 года ни одна строка журнала вплоть до версии 2.1.322 не упоминает EPERM на Windows, блокировку с датой в будущем, --chrome-native-host, процесс загрузки настроек в VS Code, вторую блокировку ~/.claude.lock и файлы .owner.tmp.*. Процесс, закрытый или убитый посреди продления, покрывает строка 2.1.282; в issue #105729, открытом на 2.1.280, автор 31 октября 2026 года добавил, что проверка шлюза, которую вызывающая программа завершала по таймауту, оставляла пустую папку в 8 запусках из 8; версию для этого опыта он не указал. Короткие команды как класс исправлены в 2.1.301, а медленное продление для auth status и plugin — в 2.1.317 и 2.1.318, после того как пользователи воспроизвели проблему на 2.1.302 и 2.1.303 с claude plugin validate (#102265) и на 2.1.311 с claude auth status (#105645). Отдельных строк про claude doctor, claude agents --json и --bg в журнале нет. В issue #103325 на Windows с версиями 2.1.296–2.1.303 планировщик вызывал claude auth status и claude agents --json, и вход дважды слетел из-за гонки продления, хотя именно этого сообщения там не было. Отчётов о коротких командах на версиях после 2.1.318 по состоянию на 12 ноября 2026 года не найдено. Сотрудник Anthropic ответил на GitHub по этой теме один раз: 16 августа 2026 года в issue #79688 назвал проблему «похожей на настоящий баг», а 19 сентября бот закрыл issue как неактивный. Отдельно официальная документация отмечает, что до версии 2.1.211 выход компьютера из сна мог заставить две сессии продлить вход одним токеном и разлогинить все окна сразу.

Как не допустить повторения: VS Code, скрипты, серверы, контейнеры

Ошибка возникает там, где несколько процессов Claude Code одновременно тянутся к одному истёкшему входу, поэтому профилактика сводится к тому, чтобы продлевал один процесс или чтобы продлевать не приходилось вовсе. Ниже — что помогало пользователям в отчётах на GitHub и что рекомендует Anthropic.

• Если VS Code по утрам восстанавливает несколько окон, пользователи помогали себе настройкой "window.restoreWindows": "one" (#90688) или одним запуском claude -p в терминале до открытия VS Code, чтобы вход успел продлиться (#102785, #79688). Если расширение в итоге не запускается вовсе, смотрите Claude Code не работает в VS Code? Сначала найдите поверхность сбоя.
• Если скрипты, мониторинг или баннер SSH часто вызывают claude auth status, claude doctor, claude agents --json или запускают фоновые сессии через --bg (о них — Claude Code Agent View: запуск и управление фоновыми сессиями), сначала обновитесь хотя бы до 2.1.318: исправления 2.1.301, 2.1.317 и 2.1.318 касаются именно коротких команд. На старых версиях пользователи из #95822 продлевали вход командой claude -p /usage и перед запуском удаляли пустую папку блокировки старше минуты. И не завершайте claude принудительно посреди работы: в #105729 проверка, убитая вызывающей программой по таймауту, оставляла пустую папку блокировки в 8 запусках из 8.
• Если Claude Code работает на сервере, в CI или по расписанию без человека, Anthropic в справочнике ошибок советует для такой автоматизации ANTHROPIC_API_KEY или долгоживущий токен от claude setup-token. Такие способы входа не используют продление сохранённого входа, а значит, и эту блокировку.
• Если на Windows открыто много процессов одновременно, пользователи из #91708 заменяли их одним сервером claude remote-control с параметром --capacity N.
• Если Claude Code работает в контейнере или виртуальной машине, следите за системными часами: официальная документация советует проверить время, когда вход запрашивают слишком часто, а скачок часов назад оставляет блокировку с датой в будущем.