Claude Code молча стирает логи сессий через 30 дней

Автор блога Brycewatson завёл папки проектов в ~/.claude/projects/ ещё в январе, но расшифровок старше 5 мая в них нет. Всё, что было раньше, удалила штатная чистка Claude Code. Она по умолчанию срабатывает через 30 дней, если в ~/.claude/settings.json нет ключа cleanupPeriodDays.

Коротко

• Claude Code хранит каждую сессию в отдельном .jsonl-файле в ~/.claude/projects/ и по умолчанию удаляет файлы старше 30 дней. Чистка идёт в фоне после старта сессии и пользователю ничего не сообщает.
• Лечится одной строкой { "cleanupPeriodDays": 3650 }, этого хватит примерно на десять лет. На 25 июня у автора с этим значением лежали 1 324 файла старше 31 дня, которые при умолчании уже были бы удалены.
• Подвох в том, что поднятое значение защищает только будущие файлы, а удалённое не вернёт. Исключение есть лишь для сессий Claude Desktop и Cowork, начиная с версии 2.1.248.

Если вы не следили, на это умолчание жалуются не впервые. Пользователь, открывший на GitHub issue #64999 на версии 2.1.156, назвал 30-дневный срок тихой и необратимой потерей данных: чистка без всякого уведомления удалила две его опорные сессии возрастом 44 и 52 дня. По его словам, обходной путь он нашёл только благодаря ошибке валидации. Схема отвергает cleanupPeriodDays: 0 и подсказывает поставить большое число.

Ключ cleanupPeriodDays по умолчанию равен 30 дням, а ноль схема не принимает

Настройка лежит в ~/.claude/settings.json как ключ верхнего уровня. В справочнике настроек указано: умолчание 30 дней, минимум 1, значение 0 не проходит валидацию. Так что выключить чистку нулём не получится, можно только поставить большое число.

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

Ещё одно условие: если организация задаёт cleanupPeriodDays через managed settings, побеждает её значение, в том числе для сессий Desktop. Проверить себя просто: откройте settings.json и поищите ключ. Если ключа нет, вы на 30 днях, хотя «у меня такой настройки нет» звучит как «у меня всё в порядке».

С версии 2.1.117 чистка удаляет не только расшифровки сессий

В первую очередь под удар попадают расшифровки: по одному .jsonl-файлу на каждую сессию в ~/.claude/projects/ и по отдельному файлу в subagents/ на каждый запуск субагента. Судя по changelog Claude Code, в версии 2.1.117 к ним добавились tasks/, shell-snapshots/ и backups/.

В документации по каталогу .claude названы ещё file-history/ и plans/, а также debug-логи, кэш вставок и осиротевшие worktrees. Папку автопамяти projects/<project>/memory/ чистка не трогает. Правда, до версии 2.1.228 она считала вложенные в неё папки данными сессий и могла удалять оттуда старые файлы.

В 2.1.248 появилось исключение: сессии, которые вы начали или в последний раз продолжили в Claude Desktop или Cowork, хранятся при любом возрасте. В changelog это названо исправлением для сессий, которые «исчезали через 30 дней». Новый ключ desktopSessionCleanupPeriodDays снова задаёт им срок, но не короче cleanupPeriodDays. Сессии из терминала и IDE подчиняются общему правилу.

С лимитом в 3650 дней у автора уцелели 1 324 старых файла расшифровок

Автор давно поднял значение до 3650, это примерно десять лет, и решил проверить, работает ли настройка. На 25 июня 2026 года на диске лежали 1 324 файла расшифровок старше 31 дня, из них 647 верхнеуровневых сессий. Лишний день он взял с запасом, чтобы все посчитанные файлы точно вышли за 30-дневный срок.

Самую старую из уцелевших расшифровок на тот момент последний раз изменяли 7 мая, 49 дней назад. За всё время набралось около 7 000 файлов расшифровок общим объёмом 1,58 ГБ, и эти цифры только растут.

По хронологии самого автора, значение 3650 у него стояло уже 11 июня: в тот день он упомянул его в посте Command. Майский пол к тому моменту уже образовался. Настройка остановила следующую чистку, но окно до мая не вернула.

Восемь папок проектов созданы с января по апрель, но расшифровок старше 5 мая в них нет

Дальше видно, где прошла чистка. Восемь папок проектов в projects/ созданы с января по апрель 2026 года, но ни в одной из них нет расшифровки старше 5 мая. Папки пережили свои файлы. Каталог shell-snapshots/ чистится по тем же часам и обрывается примерно там же, а коммиты в публичном репозитории автора chat-arch старше самой ранней майской сессии.

В первой версии разбора доказательством служили 150 файлов из file-history/ с датами в марте и апреле, самый ранний от 3 марта. Позже автор от них отказался. Даты достались от скопированных файлов: 124 из 150 записаны на диск больше чем через сутки после своей даты, а самый ранний только 12 апреля. Все папки file-history/ последний раз менялись 6 мая или позже.

Перепроверку автор провёл 30 сентября 2026 года на Claude Code 2.1.280. Свежую чистку на умолчании он не запускал, поэтому список удаляемых путей взят из документации, а не с его машины.

Возобновлённая сессия дописывается в тот же .jsonl, и /resume читает именно эти файлы

По данным Adityabawankule, каждая сессия пишется в файл ~/.claude/projects/<путь-проекта>/<id-сессии>.jsonl, куда записи только добавляются. Путь проекта получается из рабочей папки, где слеши заменены дефисами. Если возобновить старую сессию, запись продолжится в том же файле, а работа субагентов хранится рядом, в каталоге <id-сессии>/subagents/.

В документации Claude Code сказано, что /resume, claude --continue и claude --resume работают с этими локальными файлами. Если файла нет, сессию не открыть: на неизвестный ID Claude Code отвечает «No conversation found with session ID». Как пишет автор issue на GitHub, файлы удаляются через fs.unlink, мимо корзины Windows, без превью и без возможности отменить.

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

Главное ограничение автор называет сам. Он мерил на одной машине, и это не доказывает, что умолчание везде ведёт себя одинаково. За хранение тоже придётся платить диском: по его грубой оценке, загруженная установка даёт от сотен до нескольких тысяч файлов в неделю, поэтому он советует подумать о потолке вроде 365 дней. На наш взгляд, защиту истории неудачно спрятали в JSON: по данным того же issue, в интерфейсе Desktop этой настройки нет.

Ноль как «никогда» пока запрещён

Автор issue #64999 просил сделать умолчанием 365 дней или «никогда не удалять», переносить файлы в корзину, предупреждать перед чисткой, закреплять отдельные сессии и принимать 0 как «никогда». Сам он пока выставил 36500, около 100 лет. При перепроверке на 2.1.280 умолчание по-прежнему 30 дней, а ноль отвергается. Изменит ли Anthropic само умолчание, неизвестно, так что ключ лучше прописать сейчас, пока нужные логи ещё лежат на диске.