Содержание
- 1. Что происходит на самом деле — токен «court» и теги invoke
- 2. Фон: агент «генерирует» и свои вызовы инструментов
- 3. Почему это происходит — две первопричины и условия-триггеры
- 4. Разбираем три типичных заблуждения
- 5. Исправляем прямо сейчас (для пользователей Claude Code)
- 6. Для разработчиков: профилактика через API/SDK
- 7. Как отличить от похожих ошибок
- 8. Официальный статус
- 9. Чек-лист профилактики
- Итоги
- FAQ
Если вы запускали длинные сессии в Claude Code, то могли заметить, как на экран внезапно начинает выводиться странная строка:
court
<invoke name="Bash">
<parameter name="command">ssh host 'cp file file.bak ; sed -i ...'</parameter>
<parameter name="description">…описание команды…</parameter>
</invoke>
Your tool call was malformed and could not be parsed. Please retry.Вызов инструмента (команда), который должен был выполниться за кулисами, протекает в чат сырым текстом — и никогда не запускается. В самом начале сидит бессмысленное слово court (или call). Естественно забеспокоиться: «у меня что-то сломалось?» или «я что-то неправильно настроил?» Но короткий ответ такой: дело не в вашем окружении и не в вашей команде.
Это сбой на стороне модели, при котором Claude (особенно семейство Opus 4.8 / 4.7) портит «управляющие теги» вызова инструмента в момент их генерации. В официальном репозитории Anthropic по этому поводу открыто множество issue (#64108, #64150, #64690, #65705, #66153, #67295, #68354 и другие). В этой статье разбираются механизм, причины, типичные заблуждения, способы исправления для пользователей и разработчиков, отличие от похожих ошибок и официальный статус — на основе документации Anthropic и реальных issue. Самое важное действие, сразу: когда появляется court, не упорствуйте в этой сессии — пораньше уходите в свежую сессию (/clear). Почему — объясняется ниже.
Что на самом деле такое «court» и протёкшие теги invoke
— управляющий тег генерируется битым, поэтому утекает на экран вместо выполнения
Битый вызов невозможно разобрать, поэтому он никогда не выполняется (fail-closed) — нет риска, что сработает неверная команда.
Реальные проблемы — потерянный ход и «цепная реакция», если оставить всё как есть.
1. Что происходит на самом деле — токен «court» и теги invoke
Теги <invoke name="Bash"> и <parameter name="command">, которые вы видите, — это «разметка вызова инструмента», которую вы вообще не должны видеть. Когда Claude выполняет команду или редактирует файл, он генерирует эти структурированные теги в XML-стиле как токены, а Claude Code (харнесс) разбирает их и реально запускает команду. Обычно харнесс поглощает теги, они никогда не доходят до экрана, и вы видите только результат работы инструмента.
На этот раз, однако, «открывающий управляющий токен» вызова инструмента сгенерировался битым: в начало затесалось постороннее слово court или call. Харнесс реагирует только на строгий синтаксис, поэтому решает: «это не вызов инструмента, а просто текст» — и выводит его прямо на экран. Команда не выполняется, и вы получаете «Your tool call was malformed and could not be parsed.» В некоторых случаях сообщения об ошибке нет вовсе, и всё просто зависает в тишине (в issue #65705 ответ вернулся со stop_reason=end_turn и без чего-либо для выполнения, так что диалог завис).
Само слово court не имеет смысла. Но это и не совсем случайное, разовое слово — в нескольких независимых отчётах протечка проявляется как court / call с поразительным постоянством. В issue #64690 это анализируется как «вместо правильного тега выбирается токен, соседний в словаре». Иными словами, court лучше понимать как сигнатуру, которая помогает распознать этот баг.
2. Фон: агент «генерирует» и свои вызовы инструментов
Почему «управляющий тег» вообще может сломаться? Ключ в том, что для ИИ-агента вызов инструмента в конечном счёте — это всего лишь генерация текста.
Когда вы используете инструменты через Claude API, формат, который видит разработчик, — это JSON (блок tool_use). Однако внутри модель следует скрытому системному промпту, который Anthropic подставляет автоматически, и генерирует обрамляющие теги <function_calls>, <invoke> и <parameter> в виде потока токенов. Затем слой API разбирает их и преобразует в чистый JSON-блок tool_use (согласно официальной документации по tool use). Каждый «вызов инструмента» в MCP и ИИ-агентах опирается на этот механизм.
Здесь важно, что парсер харнесса работает по принципу «fail-closed» (ошибается в безопасную сторону). Если тег отличается от ожидаемой формы хотя бы на один токен, харнесс не догадывается и не запускает его — он сразу отклоняет его как некорректный. Это правильное проектирование харнесса: «услужливо подправить» неоднозначную команду и выполнить её было бы куда опаснее. Так что весь этот феномен — случай «сломалось → было отклонено → не выполнилось», то есть отказ произошёл безопасно.
Если в одном предложении
Вызов инструмента — это «текст со специальными тегами», который генерирует модель. Когда открывающий токен этих тегов ломается во время генерации, харнесс не может его распознать, поэтому он утекает в обычный текст и не выполняется. Само отклонение — это правильный механизм безопасности; баг кроется исключительно в генерации на стороне модели.
3. Почему это происходит — две первопричины и условия-триггеры
Если свести воедино реальные issue, причина распадается на «(1) повреждение в момент генерации» и «(2) цепную реакцию от самоотравления», которая и делает всё неприятным.
Как ломается, а затем «цепляется»
· Несколько вызовов инструментов в одном сообщении / вызов инструмента сразу после текста (#66153)
· Состояние сразу после запуска
/compact (#67295: рецидив при первом же вызове после compact)· Фоновый Bash (run_in_background) или 3+ подключённых MCP-серверов (#64690)
· Длинные аргументы инструмента размером с абзац (#49747: отдельный вариант, где XML просачивается в JSON)
Вывод: сама поломка — редкое дрожание сэмплинга. По-настоящему неприятная часть — цепочка в пункте (2) —
именно поэтому «упорно повторять попытки в той же сессии» может оказаться худшим ходом.
4. Разбираем три типичных заблуждения
Информация об этом феномене легко путается. Чтобы реагировать правильно, исправим три распространённых заблуждения.
| Распространённое мнение | На самом деле |
|---|---|
| «Инструмент взбунтовался / дал сбой» | Наоборот. Битый вызов был отклонён без выполнения (fail-closed). Нет риска, что сработает неверная команда; всё, что произошло, — «потерянный ход + визуальная протечка». Отказ был безопасным. |
| «Просто повтори — само вылечится, если оставить» | Верно лишь наполовину. Лёгкий случай восстанавливается с одной повторной попытки, но как только битый блок осел в истории, модель имитирует его и цепляется. В #65705 было 14 сбоев подряд за 5+ часов; в #66153 — 30+ за одну сессию. Упорствовать в той же сессии — себе во вред. |
«court что-то значит / это команда» | Это ничего не значит — просто мусор от повреждённого управляющего токена. Но court/call повторяются как маркер, поэтому полезны как диагностический признак. |
Важнее всего второй пункт. В отчётах об инцидентах часто пишут «восстановилось после повтора, проблем нет» — но это справедливо лишь для «лёгкого» случая до начала цепочки. Суть этого бага в том, что как только он переходит в режим цепочки, никакое количество повторов внутри этой сессии его не исправит.
5. Исправляем прямо сейчас (для пользователей Claude Code)
Реакция зависит от того, «всё ещё лёгкий случай или цепочка уже началась?» В порядке приоритета:
Порядок приоритета
court, пораньше выполните /clear или начните новую сессию. Обрезать отравленную историю — самое надёжное. Перед переходом сохраните состояние через git commit или заметку для передачи./compact сообщали о рецидиве сразу после — это ненадёжное лекарство.
Правило: «промахнулся дважды — брось сессию и начни с чистого листа».
Чем дольше упорствуешь в отравленной истории, тем глубже рана. Держите CLI в актуальной версии (но учтите: исправление ещё не выпущено — обновление это гигиена, а не волшебное средство).
Совет: если вы привычно сохраняете состояние в git или в .md-заметку для передачи, перейти в новую сессию в любой момент вам ничего не стоит. Чем больше вы запускаете длинные автономные сессии, тем сильнее окупается эта привычка (и она напрямую связана с управлением вашим контекстным окном).
6. Для разработчиков: профилактика через API/SDK
Если вы строите собственного агента на Claude API / SDK, можно добавить в харнесс следующие защиты. Логика обнаружения, предложенная в issue #65705, практична.
// Проверяем полученный ход ассистента перед выполнением
const text = assistantText(resp);
const looksLeaked =
/<invoke\s+name=/.test(text) ||
/function_calls/.test(text) ||
/\bcourt\s*<invoke/.test(text);
// 1) Разметка выше есть, но НЕТ структурированного блока tool_use → битый вызов
if (looksLeaked && !hasToolUseBlock(resp)) {
// 2) Не показывать; логировать. НЕ хранить битый блок в истории (предотвращает самоотравление)
// 3) Подсказать «выдай это как структурированный tool_use, а не текст» и автоматически повторить
return retryWithNudge(messages);
}
// Отклоняем неполный tool_use, вызванный обрезкой
if (resp.stop_reason === 'max_tokens' && lastBlock(resp)?.type === 'tool_use') {
return retryWith({ max_tokens: higher }); // не выполнять
}Четыре принципа. (1) Всегда проверяйте stop_reason (end_turn при том, что ни один инструмент реально не запустился, = обнаружение тихого зависания). (2) Перед выполнением убедитесь, что текст не содержит <invoke name= или function_calls; если содержит — повторите вместо выполнения. (3) Не храните битый блок в истории диалога (если оставить, следующая генерация будет его имитировать — самоотравление / #62344). (4) Держите аргументы инструмента короткими и разбивайте длинный вывод (избегайте варианта с длинной нагрузкой из #49747). Даже при использовании официального харнесса вроде Claude Agent SDK стоит понимать, как ведут себя долгоиграющие циклы.
7. Как отличить от похожих ошибок
Есть несколько ошибок класса «инструмент не запускается», и им нужны разные решения. Различайте эти четыре, чтобы не путать их.
| Симптом | Что это на самом деле | Основное решение |
|---|---|---|
| показаны court / call + сырые теги invoke, не выполнено | Тема этой статьи. Повреждение при генерации управляющего токена + цепочка через самоотравление | Предпочесть свежую сессию (/clear); не упорствовать после двух промахов |
| 400 «thinking blocks cannot be modified» блокирует сессию | Несовпадение сигнатуры в расширенном мышлении (другой баг). Жёсткая ошибка API | См. отдельную статью (Esc×2 / rewind) |
| ответ обрывается на середине потока (нет искажённого XML) | Обычная обрезка при достижении max_tokens. Не ошибка | Поднять max_tokens и перезапустить |
| XML не структурируется в Bedrock, LangChain и т. п. | Сторонний клиент не справляется с разбором формата Anthropic (langchain-aws #521). Не воспроизводится на официальном API / Claude Code | Пересмотреть библиотеку интеграции / слой хостинга |
Ось различения проста. Если вы видите «искажение court / call + сырой XML» — это данный баг. Ошибка сигнатуры 400 — это ошибка thinking-блока. Чистый обрыв — просто лимит вывода. Только на Bedrock или через LangChain — указывает на слой интеграции. О других частых ошибках Claude Code см. сводку ошибок.
8. Официальный статус
По состоянию на июнь 2026 года нет подтверждённого официального исправления (записи в changelog), которое говорило бы, что этот феномен решён. Если проследить релиз-ноты вплоть до последней версии Claude Code (линии 2.1.183), там нет записи, посвящённой повреждению сериализации вызова инструмента, и многие связанные issue остаются открытыми или помечены как «duplicate / stale». Поэтому каждое исправление в этой статье — это обходное решение в ожидании официального фикса, и нельзя утверждать, что «обновление до последней версии это чинит» (обновляться рекомендуется, но это не гарантированное лекарство).
При этом сам fail-closed-дизайн харнесса — «отклонить битый вызов, а не выполнять его наугад» — правилен. Чинить нужно стабильность генерации модели, а не ослаблять парсер до «подправить и всё-таки выполнить», что навлекло бы серьёзный риск запуска неверной команды. Лучшее, что мы как пользователи можем сделать, — работать так, чтобы избегать цепочки, и сообщать о воспроизведениях в официальные issue с вашим окружением и логами (чем больше отчётов, тем выше приоритет и быстрее исправление).
9. Чек-лист профилактики
Пользователям Claude Code: (1) Когда появляется court/call, повторите не более двух раз; если не уходит — сразу /clear / новая сессия. (2) Избегайте очень длинных / многодневных сессий; сохраняйте работу в git/заметки на контрольных точках. (3) Не запихивайте несколько вызовов инструментов в одно сообщение. (4) Помните, что /compact — не панацея (рецидив возможен сразу после). (5) Держите CLI в актуальной версии и сообщайте о воспроизведениях в официальные issue.
Разработчикам API/SDK: (1) Всегда проверяйте stop_reason. (2) Обнаруживайте утечку <invoke name= / function_calls в текст и повторяйте. (3) Не храните битые вызовы в истории (профилактика самоотравления). (4) Держите аргументы инструмента короткими; разбивайте длинный вывод. (5) Никогда не выполняйте неполный tool_use из-за обрезки по max_tokens — вместо этого повторите.
Итоги
В Claude Code «показаны court / call + сырой тег <invoke>, при том что инструмент не выполняется» — это сбой на стороне модели, при котором Claude (семейство Opus 4.8 / 4.7) генерирует управляющий токен вызова инструмента в битой форме. Харнесс отклоняет его по принципу fail-closed, так что нет риска, что сработает неверная команда (отказ был безопасным). По-настоящему неприятная часть в том, что как только битый блок остаётся в истории, модель имитирует его и «цепляется». Поэтому «повтор всё чинит» справедливо лишь пока случай лёгкий, и правилом становится «промахнулся дважды — уходи в свежую сессию».
Причина двухслойна: (1) повреждение при генерации управляющего токена + (2) цепочка через самоотравление. Триггеры включают длинные / многодневные сессии, тяжёлый контекст, состояние после /compact, несколько одновременных инструментов, 3+ MCP-серверов и длинные аргументы инструментов. Поскольку по состоянию на июнь 2026 года официального исправления нет, каждое средство — это обходной путь. Пользователям стоит «предпочитать свежую сессию + чаще сохранять состояние»; разработчикам — «проверять stop_reason, повторять при обнаружении утечки, не хранить битую историю и укорачивать аргументы». Чтение ошибки 400 thinking-блока, сводки ошибок Claude Code и MCP вместе с этим сделает вас гораздо устойчивее к проблемам с вызовами инструментов.
FAQ
Q. «court» или тег invoke на моём экране вызваны ошибкой в моей команде или настройках?
A. Нет — почти наверняка нет. Это известный сбой на стороне модели, при котором Claude генерирует теги вызова инструмента в битой форме; в официальном репозитории Anthropic заведено несколько issue (#64108, #65705, #66153 и другие). Это не ошибка в вашем окружении, команде или настройках. Воспринимайте court/call как «сигнатуру» бага.
Q. Может ли при этом выполниться неверная команда и повредить мой сервер или файлы?
A. Нет. Битый вызов инструмента признаётся «некорректным» и отклоняется без выполнения (дизайн fail-closed). Происходит лишь то, что ход теряется впустую, а управляющий текст становится виден; на ваши данные или состояние сервера это не влияет. Он спроектирован так, чтобы отказывать безопасно.
Q. Я слышал «просто повтори, и оно само починится». Это правда?
A. Только когда случай лёгкий. При первом, разовом появлении подсказка «продолжай» часто заставляет выдать вызов заново корректно. Но как только битый блок остаётся в истории диалога, модель использует его как шаблон и повторяет то же повреждение (самоотравление). На этом этапе повтор в той же сессии бьёт рикошетом. Если сбоит дважды подряд, прекратите упорствовать и перейдите в свежую сессию (/clear).
Q. Починит ли это /compact?
A. Ненадёжно. Сжатие контекста иногда помогает, но в issue #67295 это повторилось при самом первом вызове инструмента сразу после /compact. Самый надёжный ход — не /compact, а свежая сессия (/clear), которая полностью сбрасывает историю. Перед переходом сохраните состояние работы в git или заметки.
Q. Починит ли это обновление Claude Code до последней версии?
A. Нельзя сказать, что это «чинит» проблему. По состоянию на июнь 2026 года нет официальной записи в changelog, подтверждающей исправление, и многие связанные issue остаются открытыми или дублирующими. Обновление рекомендуется как гигиена, но это не волшебное средство. Пока лучший подход — работать так, чтобы избегать цепочки (промахнулся дважды → свежая сессия) и сообщать о воспроизведениях в официальные issue.
