Ошибка 400 в Claude Code через сторонний API: проверьте схему Artifact

Если после обновления Claude Code стал выдавать ошибку на каждом ходе, а ответ упоминает неверное регулярное выражение в input schema инструмента Artifact, проверьте версию клиента, прежде чем менять ключ или модель. В пользовательском сообщении #92969 в официальном репозитории описана регрессия версий 2.1.265 и 2.1.266: строгие валидаторы отклоняли pattern с Unicode property escapes.

Это конкретная историческая несовместимость, а не объяснение любого HTTP 400. Нельзя представлять её как неисправленную проблему всех современных клиентов. В официальном журнале Claude Code исправление для сторонних эндпоинтов записано в версии 2.1.268.

Сначала сопоставьте признаки ошибки

Эту причину стоит проверить при сочетании трёх признаков: сбои начались после затронутого обновления, используется сторонний Anthropic-совместимый эндпоинт, а ошибка указывает на схему Artifact или pattern, который «not a regex». Точная формулировка зависит от валидатора.

Отклонение схемы происходит до ответа модели на задачу. Поэтому замена сложного запроса о коде простым приветствием может ничего не изменить. Это не доказывает поломку модели: некорректная часть может находиться в определении инструмента, приложенном к запросу.

Таблица помогает выбрать проверку, но не ставит диагноз. Сохраните полный обезличенный ответ и сравните путь поля с исходным сообщением. Не отключайте посторонние меры защиты и не переписывайте все схемы из-за одного отказа.

Узнайте версию реально работающего клиента

Начните с команды:

claude --version

Проверьте каждую среду: терминал, IDE и фоновый обработчик могут использовать разные установки. Обновите клиент обычным для вашей установки способом, перезапустите соответствующий процесс и снова проверьте версию.

2.1.268 — историческая версия с исправлением, а не повод откатывать более новую поддерживаемую установку. Используйте актуальную версию, поддерживаемую вашей организацией. Если окружение намеренно закреплено на затронутом выпуске, учтите это в диагностике и выполните обычную процедуру обновления.

Обновиться должен клиент, формирующий запрос. Изменение локальной установки в другом терминале не обновляет отдельно развёрнутый обработчик. Зафиксируйте, какой процесс отправил неудачный запрос и какой выполнил успешную повторную проверку.

Полная последовательность восстановления клиента

Сначала сохраните время неудачного запроса в UTC, полный текст ошибки и версию клиента. Если задача автоматически повторяет запросы, приостановите её штатным способом: повторная отправка уже отклонённой схемы не помогает определить причину. Сохраните рабочую папку и диалог. Их удаление уничтожит полезные сведения и не относится к документированному исправлению.

В macOS и Linux следующие команды показывают расположение исполняемого файла и состояние установки, не отправляя запрос модели:

command -v claude
claude --version
claude doctor

В Windows PowerShell расположение можно узнать через Get-Command claude, а затем выполнить те же команды version и doctor. Сопоставьте путь со средой, в которой произошёл сбой. После обновления терминальной установки IDE может продолжать использовать старый процесс. В удалённом контейнере разработки может быть отдельная установка с закреплённой версией.

Обновляйте клиент тем способом, которым управляется именно эта установка. Официальное руководство описывает claude update для поддерживаемых самостоятельно управляемых установок. Пользователям Homebrew нужно обновить установленный cask, например командой brew upgrade claude-code. Для корпоративной установки используйте принятый в организации процесс. Не запускайте несколько пакетных менеджеров подряд: можно создать вторую копию, оставив проблемный процесс без изменений.

После обновления закройте и заново откройте нужный клиент, повторите claude --version в той же среде и запишите результат. Сообщения об успешном обновлении недостаточно, если следующий запрос отправляет другой бинарный файл. Нужна поддерживаемая версия с исправлением из 2.1.268, а не возврат к этому старому выпуску.

Проверьте один запрос до перезапуска большой задачи

В первой проверке оставьте прежние провайдера и модель. Возьмите безопасную короткую задачу и выясните, сохраняется ли исходный отказ схемы. Успех после обновления поддерживает диагноз для этой конфигурации, но не подтверждает все функции провайдера.

Затем проверьте нужный процесс с инструментами: обычный текстовый ответ не выполняет ту же последовательность вызовов. Сохраните версию, маршрут, время, обезличенную ошибку и ID запроса. Если актуальный клиент всё ещё получает отказ схемы, сравните путь поля в новой ошибке, не предполагая автоматически старую регрессию.

Статья основана на сообщении в исходном проекте и журнале выпусков. Она не заявляет о воспроизведении в рабочей среде Ofox или измеренной доле успехов на разных шлюзах.

Две небольшие проверки с разными критериями успеха

Сначала запросите короткий текст в той же конфигурации. Это реальный вызов модели: он может расходовать лимит или оплачиваться провайдеру. Подойдёт следующий диагностический запрос; фиксированная английская строка упрощает точное сравнение:

Reply with exactly: connection check
Do not modify files or run commands.

Ожидается обычный ответ ассистента вместо прежнего отказа из-за схемы Artifact. Точное совпадение строки проверяет базовую обработку ответа, а не качество программирования. Новую ошибку сохраните отдельно: запрос мог дойти до другого этапа проверки, но это ещё не полное восстановление.

Затем положите безопасный sample.txt во временную папку и попросите клиент прочитать первую строку, ничего не меняя. Сравните ответ с файлом и проверьте результат инструмента. Если обычная конфигурация включает встроенное определение Artifact, сохраните её при повторной проверке. Отключив этот инструмент, вы уже не проверите прежний способ формирования запроса.

Это предлагаемые тесты, а не результаты нашей учётной записи. Возобновляйте длинную задачу только после исчезновения исходного отказа и успешного обмена с нужным инструментом. Не поручайте редактирование или развёртывание настоящего проекта только ради проверки соединения.

Почему пометки «Anthropic-совместимый» недостаточно

Совместимость может охватывать аутентификацию, формат сообщений и потоковую передачу, но не все возможности JSON Schema. Описанная проблема касается обработки pattern во встроенном определении инструмента валидатором. Это не то же самое, что способность модели рассуждать о коде.

Не редактируйте сгенерированное регулярное выражение вслепую и не отключайте проверку в рабочей среде. Это может пропустить нежелательные значения или скрыть другую несовместимость. Предпочтителен исправленный клиент; оставшуюся проблему передайте провайдеру в минимальном примере без секретов.

Включите только небольшой фрагмент схемы с отклоняемой конструкцией. Для проверки валидатора провайдеру не нужны исходники частного проекта, переменные окружения или полная история разговора.

Успешный разбор JSON не означает допустимость регулярного выражения

Документ может быть синтаксически корректным JSON, но его JSON Schema pattern — несовместимым с конкретным валидатором. Ниже упрощённая иллюстрация, а не полное определение инструмента из исходного отчёта:

{"type":"string","pattern":"^[\\p{L}]+$"}

JSON-парсер получает строку с обратной косой чертой и p{L}. Интерпретация этой строки как регулярного выражения — отдельная операция. Поддержка свойств Unicode зависит от движка и режима. Поэтому успешный локальный разбор JSON не доказывает, что провайдер примет pattern.

Замена на .* не является равноценным исправлением: она меняет множество допустимых значений. Удаление всего инструмента тоже меняет возможности клиента. Ни то ни другое не требуется, чтобы проверить действие официального исправления в вашей конфигурации. Если вы поддерживаете шлюз, воспроизводите ошибку в тестовой среде и фиксируйте движок и версию валидатора. Не ослабляйте все производственные схемы ради одного исторического запроса.

Передавайте в поддержку только оставшуюся минимальную ошибку

Полезное обращение помещается на одном экране: версии до и после обновления, тип API, модель, путь отклонённого поля, время UTC, request ID провайдера, результаты короткого текстового и инструментального тестов. Фрагмент схемы приложите, если его запросят. Удалите токены, закрытые промпты, пути репозитория и содержимое файлов, не нужное для воспроизведения проверки.

Если ошибка Artifact исчезла, но теперь сбоит результат инструмента, переходите к руководству по tool-result или thinking-signature, указанному в конце статьи. Если отклоняется тот же pattern, попросите провайдера подтвердить фактически полученную схему и проверьте, не остался ли старый клиент в прокси или worker. Если минимальный пример не работает и на актуальном клиенте, сохраните его для обращения в исходный проект, не приписывая этой регрессии все ответы 400.

Восстановление означает, что нужный клиент отправляет исправленный запрос по нужному маршруту и безопасная инструментальная операция завершается. Это не подтверждение работы всех моделей и всех функций провайдера.

Другие ошибки 400 требуют отдельных проверок

Инструкция по отсутствующему tool_result разбирает прерванные или неверно сформированные обмены с инструментами. Руководство по thinking signature касается других проблем сохранения сообщений. Не заменяйте эти объяснения схемой Artifact, если признаки ошибки не совпадают.

Полезное обращение в поддержку начинается с наблюдений: версия клиента, тип эндпоинта, отклонённое поле и точный ответ. Формулировка «Claude Code не работает» не отличает исправленную регрессию клиента от продолжающейся проблемы провайдера.