Claude Code выключил Todo и Task-тулы по умолчанию: почему и как агентам держать план без них

Обновил на днях Claude Code - и агент перестал вести чек-лист. Не подвис, не сломался, просто молча работает без списка задач, который раньше маячил в терминале на каждом многошаговом прогоне. Причина не в баге: с версии Claude Code v2.1.233 (вышла 15 августа 2026) инструменты TodoWrite, TaskCreate, TaskGet, TaskUpdate и TaskList по умолчанию убрали у Opus 4.8, Sonnet 5, Fable 5, Mythos 5 и всех более новых моделей этих линеек. Причина в документации звучит так: эти модели и без письменного чек-листа держат в голове многошаговую задачу, а описания тулов и напоминания про них жрут контекст просто так. Вернуть поведение можно одной переменной окружения. А вот что делать пайплайнам и скиллам, которые на этот чек-лист были жёстко завязаны - вопрос отдельный, и у меня как раз есть живой пример из своего блог-конвейера.

Что именно отключили в Claude Code

TodoWrite и четвёрка Task-тулов (TaskCreate/TaskGet/TaskUpdate/TaskList) - это встроенные инструменты, которыми модель сама вела список задач текущей сессии: помечала пункт как in_progress, потом completed, показывала прогресс в терминале. С v2.1.233 их по умолчанию нет в наборе инструментов у Opus 4.8, Sonnet 5, Fable 5, Mythos 5 и более новых версий этих семейств - ни в интерактивной сессии, ни в SDK-запросе. Модель просто не добавляет ничего в список задач, пока работает.

На моделях постарше - например Opus 4.7 - ничего не поменялось: Claude Code как выдавал четыре Task-тула по умолчанию, так и выдаёт, а TodoWrite там доступен, только если явно выставить CLAUDE_CODE_ENABLE_TASKS=0. То есть это не отказ от идеи чек-листа как таковой, а решение конкретно про новые модели.

Отдельная деталь, которая многих собьёт с толку: в фоновых сессиях (background sessions) и в Claude Code on the web все пять тулов дают на любой модели, независимо от того, есть она в "чёрном списке" или нет. Про это ниже будет отдельная история.

Тут же стоит развести три разных номера версий, которые легко перепутать. Отключение по умолчанию завязано на CLI Claude Code v2.1.233. У TypeScript Agent SDK та же граница проходит по версии 0.3.233, у Python Agent SDK - по 0.2.139. Три разных продукта, три разных счётчика версий, но один и тот же рубеж поведения: если у вас Claude Code или один из SDK старше этих номеров, вы ещё не увидите разницы, даже сидя на Sonnet 5.

Почему Anthropic вообще убрала чек-лист из дефолта

Прямая цитата из официального разбора тулов Claude Code: "Those models keep track of multi-step work without a written checklist, and the tools' definitions and reminders take up context, so Claude Code leaves them out." Переводя на русский - новые модели и без чек-листа не теряют план задачи, а вот сами определения тулов плюс системные напоминания про них - это статья расхода контекстного окна, которая на новых моделях перестала окупаться.

Логика подтверждается версионной историей. В Agent SDK 0.2.136 TodoWrite задепрекейтили в пользу Task-тулов ("future versions will switch to Task tools"). В 0.3.142 headless- и SDK-сессии принудительно перевели на Task-тулы вместо TodoWrite - это была breaking change. И только в 0.3.233 Task-тулы (вместе с TodoWrite) убрали из дефолта на новых моделях целиком. Три шага за несколько месяцев, а не один резкий рубильник - что логично: сходный сценарий я уже разбирал, когда Anthropic молча включила Auto Mode по умолчанию - сначала опция, потом дефолт, а разбираться со сломанными автоматизациями достаётся тем, кто на старое поведение полагался.

С точки зрения экономии контекста всё сходится с тем, что вообще происходит вокруг CLAUDE.md и системных промптов Claude Code в последних релизах - тулы, которые не несут пользы для конкретной модели, режут в первую очередь, а не оставляют "на всякий случай". Я разбирал похожий сдвиг в подходе к контекст-инжинирингу в отдельной статье: там тоже не про "убрали функцию", а про "заплатили контекстным окном за то, что раньше было бесплатным по умолчанию".

Как вернуть TodoWrite и Task-тулы обратно

Если вашему пайплайну чек-лист реально нужен - например, вы парсите tool_use-блоки TodoWrite для отрисовки прогресса в своём UI, - способов вернуть тулы четыре:

• переменная окружения CLAUDE_CODE_ENABLE_TODO_TOOLS=1 перед запуском (CLAUDE_CODE_ENABLE_TODO_TOOLS=1 claude) - самый простой путь, тулы появляются на любой модели и у любого провайдера;
• назвать нужный тул в --allowedTools, например claude --allowedTools TaskCreate;
• перечислить тулы в --tools - но это заодно ограничит весь набор встроенных инструментов сессии только перечисленными, так что туда придётся вписать всё, что реально нужно;
• в Agent SDK то же самое делают опции allowedTools и tools.

Отдельно стоит запомнить: TodoWrite и Task-тулы конфликтуют друг с другом через CLAUDE_CODE_ENABLE_TASKS. Если вам нужен именно старый TodoWrite (не Task-тулы), на моделях, где Task-тулы дефолтны, ставьте CLAUDE_CODE_ENABLE_TASKS=0 - обратный флаг тому, что включает Task-тулы.

У меня переход прошёл тихо - я запретил TodoWrite раньше Anthropic

У истории со Superpowers есть контрпример из моего же сетапа. Отключение TodoWrite и Task-тулов в проде я не заметил вообще - не из везения, а потому что запретил инструмент агентам сам, на два месяца раньше Anthropic. Grep по CLAUDE.md и AGENTS.md моих проектов находит формулировку "do NOT use TodoWrite, TaskCreate, or markdown TODO lists" в 14 файлах восьми разных проектов. Запрет я вписал 10 июня 2026 года, когда настраивал трекер задач beads (bd init) - с тех пор план живёт в beads, а не в эфемерном чек-листе сессии: это обычные git-файлы, они переживают и компакцию контекста, и смену сессии, чего TodoWrite никогда не умел.

Из-за этого саму ошибку "No such tool available: TodoWrite", которая полгода ломала скиллы Superpowers у других, я не поймал ни разу. Прогнал grep по всей истории своих сессий (~/.claude/projects/**/*.jsonl) - ноль реальных случаев. Когда CLAUDE.md прямо запрещает инструмент, модель его просто не зовёт, и миграция на Task-тулы (а потом и их исчезновение на новых моделях) прошла для меня незаметно, без единого сломанного прогона.

Что ломается у скиллов, завязанных на TodoWrite

Тихо у меня - не значит чисто вокруг. Тут показательный кейс - open source скилл-пак Superpowers (репозиторий obra/superpowers, issue #1518). Минимум шесть скиллов - using-superpowers, brainstorming, subagent-driven-development, executing-plans, writing-plans, writing-skills - жёстко ссылались на TodoWrite в инструкциях. После перехода на Task-тулы они ловили No such tool available: TodoWrite и просто ломались посреди выполнения. Чинили руками: заменяли упоминания TodoWrite на TaskCreate по всем шести файлам и проверяли, что каждый скилл всё ещё работает.

В моём же сетапе есть более тихий вариант той же поломки. Доки плагина beads версии 1.0.3 до сих пор учат гибридному паттерну "bd persistent + TodoWrite ephemeral": тест "понадобится через 2 недели? YES = bd, NO = TodoWrite", инструкция "Reconstruct TodoWrite list from notes". А скилл using-superpowers из пакета superpowers 6.3.0 (тот же пакет, что и в issue #1518, просто версия свежее) прямо велит "create a todo per item". На новых моделях без CLAUDE_CODE_ENABLE_TODO_TOOLS=1 это инструкции в пустоту - только без явной ошибки в логах, что хуже: скилл молча живёт не по своей же документации.

Ирония в том, что это ровно тот же класс проблемы, который я разбирал в статье про то, как Opus 5 сломал половину моих скиллов: скилл, написанный под конкретное поведение конкретной модели или конкретного тула, не переживает следующий апдейт бесплатно. Разница только в том, что раньше ломались промпты под стиль модели, а теперь - хардкод названий инструментов.

Как агентам держать план без встроенных тулов

Вот тут я могу говорить не по документации, а по своему пайплайну - blog-pipeline генерирует черновики headless-командой claude -p "/blog-draft $TOPIC_ID" --permission-mode acceptEdits из cron-обёртки (cron/run-generate.sh). Модель в этих сессиях - claude-sonnet-5, то есть формально она в списке "без Task-тулов по умолчанию". И тем не менее headless-прогоны этого же пайплайна раз за разом получают системное напоминание, которое перечисляет TaskCreate, TaskGet, TaskList, TaskUpdate и ещё десяток тулов как доступные, просто отложенные - "deferred tools ... available via ToolSearch". Это и есть та самая оговорка про фоновые сессии из документации, только увиденная не в тексте, а живьём: headless-запуск через -p попадает в категорию, где тулы дают на любой модели вне зависимости от списка отключения.

Но даже с доступными Task-тулами blog-draft их не использует - и не потому что забыли, а потому что план и так живёт не в голове модели, а снаружи. Сам скилл (~/.claude/skills/blog-draft/SKILL.md) - это десять пронумерованных шагов от брифа до записи черновика, и каждый шаг опирается не на память сессии, а на внешнее состояние: scripts/bp_db.py topics-list --status in_work говорит, какая тема сейчас в работе, draft-create фиксирует результат в SQLite, topic-done закрывает тему. Упадёт сессия на середине - следующий прогон увидит тот же статус in_work в базе и продолжит по тем же десяти шагам, а не по обрывку todo-листа, который умер вместе с контекстом.

Второй пример у меня перед глазами каждый день - тот же трекер beads, которым я веду задачи по восьми проектам. bd create, bd ready и bd close фиксируют не только сам факт задачи, но и зависимости между ними, а hook bd prime вписывает актуальный workflow в системный промпт каждой новой сессии. Встроенный чек-лист модели такую нагрузку не выдерживал: в момент компакции контекста TodoWrite-список обнуляется вместе с остальной историей. Beads переживает и компакцию, и смену модели, и рестарт сессии, потому что живёт не в контексте, а в git-репозитории рядом с кодом.

Собственно это и есть ответ на вопрос "как держать план без TodoWrite": чек-лист модели - это дневник в оперативной памяти, полезный ровно на одну сессию. Как только план должен пережить рестарт, смену модели или недоступность тула, его место не в TodoWrite, а во внешнем состоянии - файле со скиллом, который явно нумерует шаги, и базе, которая знает, на каком шаге пайплайн остановился. Я уже строил такую же схему для cron-парка против облачных Routines - разные задачи, один и тот же принцип: не доверять состояние конкретному ephemeral-инструменту модели.

Что с этим делать на практике

Развернуть в чек-лист (в честь темы - последний раз в TodoWrite-стиле) можно так:

• если пайплайн просто отрисовывает прогресс TodoWrite в своём UI - ставьте CLAUDE_CODE_ENABLE_TODO_TOOLS=1 и живите дальше, дефолт сменился, а не функциональность;
• если скилл или промпт жёстко называет TodoWrite по имени (как у Superpowers) - грепните репозиторий на это имя сейчас, не дожидаясь No such tool available в проде;
• если план многошаговой задачи нигде не фиксируется, кроме памяти модели за сессию, - вынесите его во внешнее состояние: файл со шагами плюс табличка со статусом, а не расчёт на то, что конкретный тул будет доступен на конкретной модели вечно;
• если пайплайн вызывает Claude Code headless (через -p, как у меня) - явно проверьте версию CLI и SDK, а не полагайтесь на то, что "раньше работало", потому что граница поведения - это конкретный номер версии, а не дата.

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

Забавно, что я сам полез разбираться в этой теме ровно потому, что мой собственный blog-pipeline регулярно получает такое системное напоминание "consider using TaskCreate" в headless-прогонах - а пайплайн его благополучно игнорирует, потому что план уже расписан десятью шагами в файле скилла. Агент напоминает завести чек-лист, а чек-лист по факту уже есть, просто не в том туле, который агент ожидал увидеть. Удобно? Удобно - когда план живёт снаружи, а не в тулах, которые могут исчезнуть со следующим релизом.