Память Claude Code: Auto Memory, /memory и почему агент забывает

Коротко (TL;DR)

Память Claude Code — это способность агента переносить знания между сессиями, которые сами по себе стартуют с чистого контекстного окна. Устроена она из двух разных механизмов, и их постоянно путают:

• CLAUDE.md — файл правил, который пишете и правите вы. Инструкции проекта, стиль, инварианты. Полностью под контролем человека.
• Auto memory — заметки, которые Claude ведёт сам: после сессий он решает, что стоит запомнить, и складывает это в отдельные файлы.

Что важно сразу (данные на 11 июля 2026):

• Auto memory включена по умолчанию и требует Claude Code v2.1.59 или новее (проверить — claude --version).
• Индекс памяти MEMORY.md подгружается в контекст не целиком: первые 200 строк или первые 25KB, что наступит раньше. Всё, что дальше, при старте сессии агент не видит — вот главная причина, почему он «забывает».
• Файлы лежат локально на вашей машине: ~/.claude/projects/<project>/memory/. Между машинами и коллегами память не синхронизируется.
• Проверить и переключить память — команда /memory прямо в сессии.
• «Auto Dream» — это НЕ подтверждённая официально функция Claude Code. Реальная фича Anthropic под названием Dreams относится к другому продукту (Managed Agents API), а не к терминалу, которым вы пользуетесь. Ниже разберём, откуда путаница.

Дальше — механика в деталях, разбор мифа про «Auto Dream», разница между memory rot и context rot и риски, о которых молчат обзоры.

Что такое память Claude Code и чем она отличается от CLAUDE.md

Каждая сессия Claude Code начинается с чистого контекстного окна — агент не помнит прошлый разговор. По официальной документации знания через этот разрыв переносят ровно два механизма, и разница между ними принципиальна.

SpaceX · xStockSpaceX — частная компания. Торгуй её токеном на Bybit за крипту.Торговать SpaceX →

CLAUDE.md — это «конституция» проекта. Её пишет человек: как устроен код, какие команды запускать, что нельзя ломать. Claude читает файл при старте и относится к нему как к контексту, а не как к жёстко исполняемой конфигурации — важная оговорка из доков: если действие нужно заблокировать гарантированно, ставят PreToolUse-хук, а не строчку в CLAUDE.md. Файл детерминирован и предсказуем: что написали, то и загрузится.

Хуки Claude Code: как автоматизировать действия агента и не подорваться на своих же настройках

MCP в Claude Code: как подключить серверы, не сжечь контекст и когда он не нужен

Плагины в Claude Code: как установить, создать свой маркетплейс и не поймать вредоносный

SKILL.md без магии: собираем свой скилл Claude Code по инженерным паттернам

Agent Skills в Claude Code: как работают, где взять и как не поставить вредоносный скилл

Auto memory — противоположность по природе. Это записная книжка, которую агент ведёт о себе и о работе автономно. Никто вручную туда не пишет: Claude сам извлекает «полезное» из сессии и сохраняет. Отсюда и специфические риски, которых у CLAUDE.md нет, — агент может запомнить не то, запомнить с ошибкой или не подгрузить запомненное.

Смешивать эти два слоя — типичная ошибка. Один обзор (MindStudio) даже утверждает, будто auto memory дописывает знания прямо в CLAUDE.md — это противоречит официальным докам и всем остальным разборам: авто-память пишет в отдельные файлы, а CLAUDE.md остаётся исключительно ручным. Держите границу в голове: CLAUDE.md — ваш, MEMORY.md — его.

Идея «агент сам ведёт свою базу знаний» — не изобретение Claude Code; это отдельный архитектурный паттерн, когда ИИ-агент ведёт markdown-вики вместо классического RAG. Auto memory — встроенная в CLI, урезанная реализация той же идеи.

Ещё одна путаница: это не память Claude.ai

Читатель гуглит «память Claude» и попадает то на терминал, то на чат-приложение. Это разные продукты. Память чат-бота Claude.ai (компартментализация по проектам, запущена в августе 2025-го, обновлена в октябре) — потребительская функция веб-приложения. Она не имеет отношения к auto memory в Claude Code CLI: разные хранилища, разная механика, разное поведение. Всё, что ниже, — только про CLI.

Auto memory: как это работает

Где физически лежит память

Каждый проект получает свою папку: ~/.claude/projects/<project>/memory/. Путь выводится из git-репозитория, поэтому все worktree и подкаталоги одного репо делят одну директорию памяти. Внутри — индексный файл MEMORY.md и тематические заметки.

Ключевое свойство — память machine-local. Она не синхронизируется между устройствами и облачными окружениями. У коллеги на другом ноутбуке — своя, отдельная папка памяти. Для распределённой команды это прямой риск рассинхронизации: агент у одного разработчика «знает» одно, у другого — другое.

SpaceX · xStockSpaceX — частная компания. Торгуй её токеном на Bybit за крипту.Торговать SpaceX →

Почему агент «забывает»: лимит загрузки MEMORY.md

Вот механизм, который объясняет большинство жалоб «Claude всё забыл». Индекс MEMORY.md подгружается в начало каждой сессии частично: первые 200 строк или первые 25KB — что наступит раньше. Содержимое за этим порогом при старте не загружается. Формально память есть на диске, но агент её не видит.

Работают оба порога сразу — строки и килобайты. То есть даже короткий по строкам, но «тяжёлый» по объёму файл (длинные строки, вставленные данные) обрежется по 25KB раньше, чем упрётся в 200 строк.

Как это выглядит на практике: пользователи ловили служебное предупреждение прямо в контексте — например (кейс из разбора vc.ru, июнь 2026) файл на 208 строк / 52.9KB, из которого загрузилась лишь часть. Агент физически не видел половину собственной памяти и повторял ошибку, которую ранее «запомнил» как исправленную. Важная оговорка: поведение при переполнении в источниках расходится — часть авторов сообщает о тихом обрезании без предупреждения, часть видит явный warning. Вероятно, это версионный дрейф или разное поведение для превышения по строкам и по килобайтам. Точную формулировку и наличие предупреждения проверяйте на своей версии.

Практический вывод: держите MEMORY.md компактным. Всё ценное должно помещаться в загружаемую часть индекса, иначе оно мёртвым грузом лежит на диске.

Команда /memory

/memory — главный инструмент диагностики. Она:

• показывает все загруженные в текущей сессии файлы CLAUDE.md, CLAUDE.local.md и rules-файлы;
• переключает auto memory (вкл/выкл);
• даёт ссылку открыть папку памяти.

Правило простое: нет файла в списке /memory — агент его не видит. Когда кажется, что Claude игнорирует запомненное, первым делом смотрят этот экран.

Как включить, выключить и что делает —bare

Auto memory работает по умолчанию. Отключить можно тремя способами:

• тумблером в /memory внутри сессии;
• ключом autoMemoryEnabled: false в настройках проекта или профиля;
• переменной окружения CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.

Отдельно — флаг --bare для скриптовых вызовов -p: он полностью отключает авто-обнаружение: хуки, скиллы, плагины, MCP-серверы, auto-memory и CLAUDE.md. Нужен, когда автоматический прогон должен стартовать «чистым», без накопленного состояния.

Что Claude реально пишет в память: 4 типа записей

Здесь начинается недокументированная часть. В официальных доках Anthropic не перечисляет внутренние категории записей, но два независимых исследователя вычитали их из реального YAML-frontmatter своих memory-файлов — и списки совпали дословно. Четыре типа (metadata.type):

Совпадение двух независимых методов (grep реальных файлов против разбора внутренностей) исключает случайную ошибку одного автора — но помните, что официально Anthropic этот список не подтверждала.

По данным независимого анализа внутренностей, само извлечение памяти работает как фоновый форк основного агента: он запускается после «тихих» ходов (без вызовов инструментов), ограничен максимум 5 ходами на извлечение, а права записи у него — только в папку памяти. Это уже недокументированная механика: воспринимайте её как реконструкцию, а не как гарантию вендора.

«Auto Dream»: что это и почему вокруг него столько путаницы

Короткий прямой ответ: по состоянию на 11 июля 2026 «Auto Dream» / «AutoDream» как функция Claude Code CLI официально Anthropic не задокументирована. Мы проверили это напрямую — не по пересказам: полнотекстовый просмотр официальной страницы памяти и поиск по всему CHANGELOG.md репозитория anthropics/claude-code не дают ни одного упоминания dream / dreaming применительно к терминальному Claude Code.

Откуда же волна статей «Anthropic quietly shipped Auto Dream»? Термин распространяется только через сторонние источники: блогеров, пересказы YouTube-разборов, AI-сгенерированную wiki по неофициальному форку репозитория и репозиторий, который сами эти материалы описывают как слитый исходный код. Показательно, что источники противоречат друг другу в датах и обстоятельствах «запуска» (март, май, «discovered by developers reading system prompts») — единого официального анонса просто нет.

А что тогда есть на самом деле: Dreams в Managed Agents API

Путаница не на пустом месте. У Anthropic есть реальная, официально задокументированная фича с похожим именем — Dreams. Но она относится к отдельному продукту: Managed Agents API, для тех, кто строит собственных агентов через API. Это не интерактивный терминал Claude Code, которым пользуется рядовой читатель.

Что известно из официальной API-документации:

• Статус — research preview с доступом по заявке; требуются бета-заголовки managed-agents-2026-04-01 и дополнительно dreaming-2026-04-21.
• «Dream» — асинхронная задача: на входе один memory store и от 1 до 100 сессий-транскриптов, на выходе — консолидированная память.
• Выполнение занимает от нескольких минут до десятков минут в зависимости от объёма; поддерживаемые модели — claude-opus-4-8, claude-opus-4-7, claude-sonnet-4-6.

Идея — «агент во сне переосмысливает опыт и уплотняет память», как человек за ночь раскладывает впечатления. Отсюда красивое имя. На конференции Code with Claude 2026 (6 мая) Anthropic привела кейс Harvey (legal AI) — рост завершения задач в 6 раз после внедрения dreaming. Но это маркетинговое заявление без раскрытой методологии: цифра идёт из вторичного освещения события, независимого подтверждения нет — подавать её как факт нельзя.

Итог по «Auto Dream»: если вы пользуетесь обычным Claude Code в терминале — никакого «Auto Dream» у вас нет и включить его негде. Есть Auto Memory (то, что описано выше) и есть Dreams в закрытом API-превью для разработчиков агентов. Смешивать их — фактическая ошибка, которую тиражирует половина обзоров.

Memory rot против context rot: два разных «гниения»

Ещё одна пара терминов, которую регулярно путают как синонимы. Это две разные проблемы.

Context rot — задокументированное Anthropic явление: исследования needle-in-a-haystack показали, что с ростом числа токенов в окне способность модели точно извлечь нужный факт падает. Это про деградацию recall внутри сессии.

Memory rot — формулировка комментаторов для другой беды: со временем папка auto memory обрастает markdown-файлами с дублями, взаимными противоречиями и протухшими ссылками, и агент начинает опираться на устаревшее. Это накопление мусора между сессиями. Именно «лечением» memory rot сторонние источники и объявляют мифический «Auto Dream» — но, как разобрано выше, официального решения в CLI для этого пока нет; чистить память приходится руками.

Частичная защита от протухания в продукте всё же есть: при чтении устаревших файлов Claude Code, по воспроизведённым наблюдениям (readysolutions.ai, воспроизведено на файлах возрастом 3, 6 и 15 дней), вставляет в контекст недокументированное предупреждение вида «This memory is N days old». То есть агента предупреждают, что заметка — снимок на момент, а не живое состояние. Но это костыль, а не консолидация.

Риски и безопасность памяти

Память, которую агент ведёт сам и подмешивает в контекст, — это новая поверхность атаки и новый класс багов.

Отравление памяти (OWASP ASI06). OWASP Top 10 for Agentic Applications, опубликованный 9 декабря 2025 года, выделяет отдельный именованный класс угроз — ASI06 «Memory & Context Poisoning». Суть: если злоумышленник смог записать в персистентную память агента вредные инструкции или ложные факты, они перекраивают поведение спустя долгое время после исходного взаимодействия — уже в новых сессиях, когда о вредоносном вводе никто не помнит. Для auto memory это не абстракция: агент сам решает, что сохранить, и потом сам это подгружает.

«Claude сказал, что запомнил» ≠ реально запомнил. Задокументированный баг (GitHub issue #36973, закрыт как not_planned 18 апреля 2026) показал разрыв: системный промпт годами инструктировал модель писать память по одному пути внутри дерева проекта, а реальный код грузит MEMORY.md из ~/.claude/projects/<hash>/memory/ — по другому. Файлы, записанные «по инструкции», оказывались в месте, которое никогда не автозагружается. Автор проследил это через декомпилированный бинарник. Мораль: подтверждение «запомнил» от агента — не гарантия, что запись попадёт в загружаемую часть индекса.

Приватность и локальность. Плюс machine-local хранения — данные не улетают в облако и не расшариваются. Минус — тот же: у команды нет единой памяти, а на диске в ~/.claude/projects/ копится всё, что агент счёл нужным записать о вас и о проекте (тип user — это буквально «кто вы и как работаете»). Стоит понимать, что там лежит, и periodically заглядывать в папку через /memory.

Конфликт двух слоёв. Когда auto memory противоречит CLAUDE.md, агент может опереться на устаревшую заметку вместо актуального правила — жалобы на это встречаются в трекере. Это плата за автономность: чем больше агент помнит сам, тем внимательнее нужно следить, что именно он помнит — ровно та зона, где автономные агенты и ломаются на практике.

Практический чек-лист диагностики «агент забыл»:

1. Открыть /memory — файл вообще в списке загруженных?
2. Проверить размер MEMORY.md — не ушло ли нужное за 200 строк / 25KB?
3. Посмотреть саму папку ~/.claude/projects/<project>/memory/ — что там реально записано (и не дубли ли).
4. Сверить с CLAUDE.md — нет ли конфликта, где память перебивает правило.
5. Помнить про баг пути: запись могла уйти не туда, откуда идёт загрузка.

FAQ

Нужна ли отдельная подписка или настройка, чтобы включить память? Нет. Auto memory включена по умолчанию начиная с Claude Code v2.1.59. Нужен только сам обновлённый CLI; проверить версию — claude --version, состояние памяти — /memory.

Синхронизируется ли память между моими устройствами и с командой? Нет. Память machine-local: у каждого устройства и каждого разработчика — своя папка ~/.claude/projects/<project>/memory/. Общий репозиторий и worktree делят одну папку только в пределах одной машины. Для команды это означает расхождение памяти между участниками.

Где физически хранятся файлы памяти и можно ли их редактировать руками? В ~/.claude/projects/<project>/memory/: индекс MEMORY.md плюс тематические заметки. Это обычные markdown-файлы, их можно открыть и вычистить вручную — что и есть основной способ бороться с накоплением устаревших записей. Держите индекс в пределах 200 строк / 25KB, иначе часть не загрузится.

Есть ли в Claude Code функция «Auto Dream», которая сама наводит порядок в памяти? На 11 июля 2026 — нет официально задокументированной «Auto Dream» в Claude Code CLI. Реальная фича Dreams существует, но относится к Managed Agents API (research preview по заявке), а не к терминалу. Всё, что пишут про «Auto Dream в Claude Code», опирается на сторонние источники и утечки, не на анонс Anthropic.

Почему Claude забывает то, что я ему уже объяснял в прошлой сессии? Три частые причины. Первая: запись ушла за лимит загрузки MEMORY.md (200 строк / 25KB) и при старте не подгрузилась. Вторая: агент вообще не сохранил это в память — авто-извлечение выбирает, что счесть важным. Третья: context rot внутри длинной сессии — модель хуже вспоминает из переполненного контекста. Диагностика — через /memory и осмотр папки памяти.