Claude Code наконец-то перестал страдать амнезией. Теперь он умеет помнить, над чем вы работали вчера, позавчера и неделю назад — но только если вы включили одну-единственную настройку.
Эта настройка выглядит так:
```bash
CLAUDE_CODE_TASK_LIST_ID=my-project claude
```
Указываете `TASK_LIST_ID` — и с этого момента список задач становится постоянным: закрыли терминал, открыли новый с тем же ID — все задачи, их статусы и зависимости на месте.
---
В чём была боль: «амнезия агента»
Типичная картина: вы три часа вместе с Claude Code распутываете сложный рефакторинг на десятки файлов. Агент помогает составить план, разворачивает его в десяток подзадач, вы отмечаете выполненное, намечаете следующее. Сессия плотная, осмысленная — живой рабочий процесс.
Потом вы закрываете терминал.
На следующий день открываете новый — и для агента всё начинается с нуля. Никакого плана, никакого статуса задач, никаких связей между шагами. Старые Todos жили только в памяти текущей сессии, и вместе с ней исчезали. Любая попытка строить долгую работу превращалась в борьбу с забывчивостью инструмента.
Плюс к этому:
- субагенты не видели задачи главного агента;
- нельзя было задать зависимости между задачами;
- невозможно было нормально вести долгие, прерывистые процессы.
---
Архитектурный сдвиг: от эфемерных Todos к персистентным Tasks
Новые Tasks — это не косметический рефакторинг, а смена архитектуры.
Как было:
- Задачи (Todos) хранились в памяти сессии.
- После закрытия терминала или очистки контекста список исчезал.
- Каждый агент жил в своём изолированном мире задач.
Как стало:
- Tasks теперь сохраняются на диске, в каталоге `~/.claude/`.
- Они привязаны к конкретному `TASK_LIST_ID`.
- Один и тот же список задач может использоваться в разных сессиях и даже в разных терминалах.
- Субагенты могут работать по общему списку через shared ID.
- Появились зависимости: `blockedBy` и `blocks`.
- Появился режим работы из нескольких сессий над одним проектом.
По сути, Claude Code получил нечто вроде минималистичного task-трекера, встроенного прямо в терминал.
---
Ключевое отличие: файловая система вместо оперативной памяти
Главный поворот — место хранения.
| Аспект | Старые Todos | Новые Tasks |
|---------------------|----------------------|--------------------------------|
| Хранение | Только в RAM | На диске, в `~/.claude/` |
| После закрытия сессии | Всё пропадает | Всё сохраняется |
| Видимость субагентам | Нет | Через общий `TASK_LIST_ID` |
| Зависимости задач | Отсутствуют | `blockedBy`, `blocks` |
| Multi-session | Невозможно | Несколько терминалов одновременно |
Использование диска решает сразу несколько проблем:
1. Персистентность — состояние задач не привязано к жизни конкретного процесса.
2. Шаринг — несколько агентов и несколько сессий могут видеть одно и то же состояние.
3. Прерывистая работа — можно честно разрывать работу на дни и недели, не теряя структуру.
---
Одна настройка, без которой магии не будет
Есть важный подводный камень: если `TASK_LIST_ID` не указать явно, он генерируется автоматически и живёт ровно столько же, сколько и сессия. Очистили контекст командой `/clear` — автоматически привязанный список задач исчез.
Поэтому, если вы хотите, чтобы Claude Code правда помнил задачи:
- задайте `CLAUDE_CODE_TASK_LIST_ID` в переменной окружения;
- или пропишите его в конфиге запуска;
- или всегда стартуйте агент с явным идентификатором проекта.
Например:
```bash
export CLAUDE_CODE_TASK_LIST_ID=my-big-refactor
claude
```
Теперь этот ID — постоянный якорь для вашего списка задач. Пока вы запускаете агент с тем же ID, он видит одну и ту же «доску» задач, независимо от того, сколько раз вы закрывали терминал.
---
Новые инструменты для работы с задачами
Вместе с персистентностью Claude Code получил набор специализированных инструментов для работы с Tasks. Агент теперь может:
- создавать и обновлять задачи;
- менять статусы (в работе, сделано, заблокировано);
- строить и использовать зависимости между задачами;
- работать с общим task list совместно с субагентами.
Ключевая деталь — агент понимает зависимости, а не просто хранит их как текст. Если задачи связаны так:
- Задача 3 `blockedBy` Задачи 2,
то агент не начнёт работать над третьей, пока вторая не будет завершена. Возникает настоящий граф зависимостей, как в нормальных системах управления проектами.
---
Зависимости как средство управления порядком работ
В реальных проектах редко бывает линейный список: «сделай A, потом B, потом C». Чаще это дерево или граф:
- какие-то задачи можно делать параллельно;
- какие-то жёстко завязаны на результаты других;
- часть задач — инфраструктурные, блокирующие всё остальное.
Tasks поддерживают этот сценарий «из коробки»:
- вы можете явно указать, какие задачи блокируют другие;
- агент видит, что именно сейчас доступно к выполнению;
- параллелизм становится контролируемым, а не случайным.
Пример: у вас есть задачи #1–#6. #1–#3 — подготовка инфраструктуры, #4 и #5 — независимые части фичи, #6 — финальный интеграционный шаг.
- #4 и #5 зависят от #2 и #3, но не зависят друг от друга;
- #6 зависит от #4 и #5.
В таком графе агент:
- сначала добивает подготовку;
- затем может параллельно выполнять #4 и #5 (особенно удобно через субагентов);
- автоматически понимает, что #6 доступна только после завершения обеих веток.
---
Киллер-фича: субагенты на общем списке задач
Настоящее раскрытие Tasks происходит, когда в игру входят субагенты.
Раньше каждый субагент жил в своём замкнутом контексте. Контекст главного агента и подагентов не синхронизировался, задачи приходилось прокидывать вручную через промпты. Это убивало идею параллельной работы.
Сейчас:
- у главного агента и всех субагентов может быть общий `TASK_LIST_ID`;
- задачник лежит на диске и является общей точкой правды;
- каждый субагент работает в своём контекстном окне, не засоряя память главного агента;
- синхронизация идёт через файловую систему — быстрая и прозрачная.
Получается простая, но мощная схема:
- главный агент (или человек-оркестратор) планирует и раскладывает работу на задачи;
- субагенты берут свободные задачи из общего списка и выполняют их;
- статусы и комментарии по задачам синхронизируются автоматически.
---
Сценарий: рефакторинг на 20+ файлов с воркерами и наблюдателем
Самый показательный кейс — большой, рискованный рефакторинг.
Представим:
- есть модуль из 20–30 файлов;
- изменения цепляются одно за другое;
- нужно не сломать поведение и сохранить управляемость процесса.
Можно развернуть такую схему:
1. Терминал A (Worker)
Основной агент-исполнитель. Пишет код, правит файлы, берёт задачи со статусом «готово к работе».
2. Терминал B (Checker / Observer)
Второй агент-наблюдатель. Проверяет изменения, запускает тесты, фиксирует найденные баги в тот же task list как новые задачи или подзадачи.
С точки зрения разработки это напоминает лёгкий CI/CD, встроенный в Claude Code:
- Worker не отвлекается на тесты и ревью — он концентрируется на реализации;
- OBSERVER видит всё, что происходит в списке задач, может помечать проблемные места и блокировать отдельные задачи;
- прогресс и статусы задач едины для обоих.
Синхронизация идёт через файловую систему:
- нет ощущения «расходящихся реальностей», когда один агент ещё не знает, что сделал другой;
- риск гонок минимален — задачи обновляются последовательно и достаточно быстро;
- вы всегда видите актуальную картину работ.
---
Multi-session: один список задач из нескольких терминалов
Ещё один важный эффект от перехода на дисковое хранение — многосессионность.
Теперь:
- можно открыть несколько терминалов с одним и тем же `TASK_LIST_ID`;
- в каждом запускать своего агента или свои сценарии;
- все они будут видеть один и тот же набор задач и статусов.
Пример практического использования:
- в одном терминале вы ведёте «архитектора» — агента, который проектирует решение, перекидывает задачи между статусами, создаёт зависимости;
- во втором — «исполнителя» фронтенда;
- в третьем — «исполнителя» бэкенда.
Все работают по одному списку. Когда фронтенд-агент завершает свою часть, задача меняет статус — и это тут же видно и архитектору, и бэкенд-агенту, и любому другому участнику процесса.
---
Как это настроить на практике
Минимальный рабочий рецепт:
1. Выберите логический идентификатор проекта, например:
`my_project_refactor`, `billing_v2`, `search-module`.
2. Задайте переменную окружения:
```bash
export CLAUDE_CODE_TASK_LIST_ID=billing_v2
```
3. Запустите Claude Code как обычно.
Теперь все создаваемые и редактируемые задачи будут привязаны к этому ID и сохраняться в `~/.claude/`.
4. Если хотите пустой список для нового потока работы — смените `TASK_LIST_ID` на другой.
Важно: зафиксируйте ID для конкретного проекта и не меняйте его в рамках одного большого рефакторинга или реализации фичи. Тогда история задач останется цельной.
---
А если Tasks не нужны?
Есть сценарии, в которых новая система будет лишней:
- быстрые правки в одном файле;
- одноразовый скрипт;
- короткий вопрос «обсудить идею» без реализации.
В таких случаях вам не нужен task list, граф зависимостей и оркестрация субагентов. Можно:
- либо работать с автоматически сгенерированным списком (и не переживать, что он исчезнет);
- либо вовсе отключить Tasks, вернувшись к старому простому поведению через соответствующую настройку.
Но для любых задач, которые выходят за рамки «сделать прямо сейчас и забыть», Tasks дают ощутимое преимущество.
---
Реальный рабочий процесс: декомпозиция фичи
Как это выглядит в боевом режиме, если подходить к фиче по-взрослому:
Шаг 1. Создание плана
- вы описываете фичу и просите агента разложить её на задачи;
- агент предлагает структуру: эпики, подзадачи, инфраструктура, тесты;
- вы уточняете порядок и добавляете зависимости (`blockedBy`, `blocks`);
- в результате получается управляемый список работ.
Шаг 2. Параллельная работа субагентов
- независимые задачи помечаются как доступные к выполнению;
- вы запускаете одного или нескольких субагентов-исполнителей;
- каждый берёт свою часть, работает в изолированном контексте;
- прогресс пишется в общий task list.
При этом главный агент остаётся «чистым» — в его контекст не валятся детали каждой правки, он оперирует уровнем задач и статусов.
Шаг 3. Продолжение через день (или через неделю)
- вы закрываете терминалы в конце рабочего дня;
- на следующий день запускаете агент с тем же `TASK_LIST_ID`;
- видите тот же список задач, с теми же статусами и зависимостями;
- не нужно пересказывать, что происходит — система уже знает состояние проекта.
---
Когда Tasks особенно полезны
Персистентные задачи раскрываются:
1. В сложных рефакторингах
20+ файлов, взаимосвязанные изменения, несколько итераций, откаты, тесты. Без структуры легко потеряться.
2. В декомпозиции больших фич
Когда фича разбивается на 10–30 подзадач, часть из которых можно делать параллельно, а часть — строго по порядку.
3. В работе с субагентами
Когда один агент планирует и оркестрирует, другие — реализуют, тестируют, проверяют.
4. В прерывистой работе
«Сегодня 2 часа, завтра 3, через неделю ещё пару часов». Tasks держат в памяти не текстовое описание, а именно структуру работы.
---
Когда Tasks избыточны
Есть и обратная сторона: не нужно пытаться применять Tasks всегда и везде.
Лучше остаться на простом сценарии, если:
- вы решаете одноразовую, маленькую задачу без продолжения;
- планирование в виде задач только тормозит;
- нет необходимости возвращаться к этому же контексту через время.
Но как только вы чувствуете, что:
- вы уже второй раз объясняете агенту один и тот же рефакторинг;
- вы вручную пишете списки TODO в файлы;
- вы постоянно теряете нити между днями работы,
— это сигнал, что пора включать персистентные Tasks.
---
Ограничения и трезвый взгляд
У системы есть и ограничения, о которых важно знать заранее:
- Хранение глобальное
Tasks лежат в общем каталоге `~/.claude/`. Это удобно, но требует минимальной дисциплины в выборе `TASK_LIST_ID`, чтобы не устроить хаос из десятков «test1», «tmp», «debug».
- Поиска по истории пока нет
Нельзя одним кликом найти «где была задача про миграцию схемы», если вы не помните её ID или точное название.
- Для глубокой, git-привязанной истории удобнее спец-решения
Если вам нужна детальная, привязанная к коммитам история изменений и задач, стоит использовать специализированные инструменты вроде git-backed трекеров. Tasks же — это скорее лёгкая «Jira в терминале», чем полноценная система управления проектами.
---
Что в итоге изменилось концептуально
Если обобщить:
Раньше (Todos):
- были временные записки агента внутри сессии;
- не переживали закрытие терминала;
- не умели ни в зависимости, ни в совместную работу субагентов;
- не позволяли строить серьёзные, многошаговые процессы.
Теперь (Tasks):
- появились долговечные, дисковые списки задач, живущие между сессиями;
- добавились зависимости и граф выполнения;
- субагенты и разные терминалы могут работать по одному списку;
- появилась возможность строить полноценные рабочие процессы: от планирования до завершения фичи.
По ощущениям это и правда похоже на мини-Jira, встроенную внутрь Claude Code и живущую прямо в терминале.
---
Что имеет смысл попробовать прямо сейчас
Если вы много работаете с Claude Code не только как с «умным собеседником», но и как с реальным помощником в разработке, имеет смысл:
1. Выбрать один живой проект — рефакторинг или фичу.
2. Задать осмысленный `CLAUDE_CODE_TASK_LIST_ID`.
3. Попросить агента:
- составить план работ;
- разложить его на подзадачи;
- явно проставить зависимости.
4. Поэкспериментировать с:
- одним воркером и одним наблюдателем в разных терминалах;
- прерывистой работой в течение нескольких дней;
- параллельными ветками задач.
После пары таких итераций становится ясно, где Tasks действительно дают рывок в продуктивности, а где достаточно старой модели «одна сессия — одна мысль».
