Claude Code действительно помнит проект между сессиями, но не через один огромный постоянный memory-store. В актуальной документации Anthropic, проверенной 8 апреля 2026 года, это разложено на две встроенные поверхности: CLAUDE.md для инструкций, которые пишете вы, и auto memory для паттернов, которым Claude учится по повторяющимся правкам.
Проблема начинается в тот момент, когда под словами "Claude Code memory" пытаются спрятать три разные задачи. Одни вещи нужно сохранить как явные правила. Другие разумнее отдать на обучение по повторяющейся коррекции. Третьи вообще не относятся к встроенной памяти Claude Code, если речь идет о кросс-инструментальной или кросс-машинной непрерывности. Когда эти задачи разделены, memory перестает казаться магией и становится настраиваемой системой.
Самое полезное правило простое. Если потеря этого знания дорого обойдется, запишите его в CLAUDE.md. Если Claude может выучить это по повторяющимся коррекциям, пусть это делает auto memory. Если же вам нужна память между несколькими инструментами, машинами или более широкими retrieval-потоками, это уже повод думать о внешнем слое. Прежде чем говорить, что Claude "забыл", откройте /memory и /context и проверьте, что вообще было загружено.
Что должна помнить Claude Code, а что нет
Правильный вопрос здесь не "есть ли у Claude Code память", а "какая поверхность должна помнить что".
CLAUDE.md — это слой явных правил. Сюда стоит класть долговечные инструкции: workflow репозитория, обязательные тест-команды, чувствительные директории, стиль ревью, ограничения на опасные действия. Если правило должно присутствовать в контексте с самого первого хода, его место здесь. Но важная оговорка из текущих docs Anthropic: CLAUDE.md — это контекст, а не жесткое принуждение. Если файл распух, противоречит сам себе или написан слишком расплывчато, Claude все равно может вести себя нестабильно.
auto memory — это слой обучаемых привычек. Он лучше подходит для повторяющихся паттернов: каким образом обычно запускать тесты, какие внутренние сокращения использовать, как проект предпочитает оформлять изменения. В текущем официальном контракте auto memory — это machine-local хранилище, а не универсальная облачная память. Это делает систему проверяемой и полезной, но одновременно задает четкую границу.
Плагины и внешние memory-слои — это уже третья категория. Anthropic сейчас показывает в marketplace memory-extension продукты, и именно поэтому поиск часто смешивает встроенную память Claude Code с внешними second-brain решениями. Но это не значит, что плагин — первая правильная настройка. Если ваш реальный вопрос звучит как "как сделать так, чтобы Claude стабильно помнил правила проекта и мои повторяющиеся правки", встроенный слой должен быть стартовой точкой. Плагин — это не дефолт, а осознанная эскалация.
Практическая схема выглядит так:
| Поверхность | Для чего подходит | Ошибочное ожидание |
|---|---|---|
CLAUDE.md | явные долговечные правила | ждать, что это будет абсолютная policy-система |
| auto memory | привычки, коррекции, повторяющиеся паттерны | думать, что оно облачное или всегда загружено целиком |
| plugin / external layer | кросс-инструментальная или кросс-машинная память | включать раньше, чем понятны встроенные границы |
Если нужна одна строка на память, то вот она: важное и хрупкое записывайте явно, повторяющееся отдавайте на обучение, а расширяйтесь наружу только тогда, когда встроенная граница действительно мешает работе.
Что попадает в контекст на старте, а что нет
Не все memory-файлы входят в сессию одинаково. Именно здесь ломается большая часть интуитивных ожиданий.
Согласно текущим docs Anthropic, CLAUDE.md загружается в начале каждой беседы. Поэтому все, что должно присутствовать до первого действия Claude, лучше держать именно там. Не стоит рассчитывать, что критичное правило само всплывет позже через inference или случайное чтение файла.
Со встроенной auto memory моделью все точнее и строже. В папке памяти есть MEMORY.md и topic-файлы. На старте в контекст попадает только первые 200 строк MEMORY.md или первые 25KB. Topic-файлы не подгружаются автоматически целиком, а читаются по запросу, когда задача делает их релевантными. Это полезно для экономии контекста, но ломает распространенное заблуждение: файл может существовать на диске, но не присутствовать в текущей сессии.
Именно поэтому /memory и /context — это не второстепенные команды. /memory показывает, какие CLAUDE.md, CLAUDE.local.md и rules-файлы реально загружены, а также открывает доступ к memory-папке. /context показывает живую раскладку контекстного бюджета. Если Claude ведет себя так, будто "забыл", сначала надо выяснить, был ли нужный слой загружен вообще.
Отдельно важно не терять machine-local границу. Документация Anthropic прямо указывает локальный путь хранения auto memory. Это хорошо для inspectability, но не поддерживает фантазию о том, что одна и та же память автоматически переедет на другую машину или в другой runtime.
Как организовать CLAUDE.md так, чтобы он не превратился в свалку
Лучший CLAUDE.md — не самый длинный, а самый дисциплинированный.
Проектный CLAUDE.md должен нести то, что нужно репозиторию каждый раз: workflow, обязательные тесты, принципы изменений, опасные зоны, архитектурные ограничения. Это командный слой. Он не должен превращаться в энциклопедию всех возможных случаев. Текущая рекомендация Anthropic о разумной длине файла существует не для красоты, а потому что длинные и конфликтные инструкции хуже соблюдаются.
Пользовательский ~/.claude/CLAUDE.md логично использовать для личных предпочтений между проектами: как вы хотите видеть объяснения, когда Claude должен спрашивать разрешение заранее, какой тон ответов вам подходит. Это не repo-policy, а ваши дефолты.
CLAUDE.local.md — хороший выбор для приватных проектных заметок, которые нужны только вам и не должны попадать в version control. Его сила не в том, чтобы стать второй глобальной инструкцией, а в том, чтобы держать точные local-оговорки.
Если правило относится только к одному пути или узкому workflow, .claude/rules/ почти всегда лучше, чем еще один пласт в основном файле. Так инструкция остается ближе к задаче и не превращает общий контекст в шум.
Еще одна деталь, которую легко пропустить: если репозиторий уже использует AGENTS.md, Claude Code не читает его автоматически. Текущая рекомендация Anthropic — импортировать AGENTS.md из CLAUDE.md. Если этот мост не сделать, возникает типичная жалоба: "в репо же есть правила, почему Claude их не учитывает?"
Если вы все еще на этапе настройки CLI, сначала удобнее пройти наш гайд по установке Claude Code. Структурировать память намного проще после того, как сама установка и аутентификация уже стабильны.
Как auto memory работает на практике
auto memory легко идеализировать, но полезнее смотреть на него как на контролируемый и ограниченный обучаемый слой.
Во-первых, он не скрыт. Anthropic документирует путь хранения, структуру MEMORY.md и topic-файлов. Это значит, что память можно инспектировать и чистить, а не только надеяться, что Claude "сам как-нибудь разберется".
Во-вторых, это не безграничный слой. На старте загружается только часть MEMORY.md, а topic-файлы читаются по мере необходимости. Поэтому критичное правило, которое обязано присутствовать всегда, нельзя прятать в глубокий topic-файл. Его место — в правильном CLAUDE.md.
В-третьих, у вас есть встроенные рычаги управления. В текущих docs Anthropic указаны /memory, настройка autoMemoryEnabled: false и переменная CLAUDE_CODE_DISABLE_AUTO_MEMORY=1. Эти переключатели полезны не потому, что память нужно выключать постоянно, а потому что они позволяют диагностировать: это реальная граница системы или просто грязная конфигурация.
Почему Claude забывает после /compact или между сессиями
Большинство историй про "Claude забыл" сводится не к отсутствию memory, а к неправильному слою, плохому scope или разговорной памяти, которую приняли за постоянную.
Первая ветка — ничего не было загружено. Начните с /memory. Был ли нужный CLAUDE.md вообще в этой сессии? Не ожидали ли вы, что topic-файл загрузится на старте, хотя docs говорят обратное?
Вторая ветка — правила слишком расплывчаты или конфликтуют. Anthropic прямо пишет, что CLAUDE.md — это контекст, а не жесткая policy-машина. Слабые и спорящие друг с другом формулировки легко выглядят как "память сломалась", хотя на деле Claude просто не получает четкого приоритета.
Третья ветка — инструкция жила только в разговоре. Это, пожалуй, самое полезное правило диагностики во всей системе. Если после /compact что-то исчезло, значит, это, вероятно, так и не было вынесено в долговечный memory-layer. Для того, что должно пережить сессию, одного чата недостаточно.
Четвертая ветка — вы действительно уперлись в границу встроенной памяти. Если нужен кросс-инструментальный или кросс-машинный continuity-layer, плагин может быть разумным шагом. Но это правильный вывод только после того, как вы исключили загрузку, качество правил и conversation-only persistence.
Надежный порядок проверки такой:
- Открыть
/memoryи посмотреть, что реально загружено. - Решить, должна ли эта информация жить в
CLAUDE.md, а не в auto memory или разговоре. - Переписать расплывчатые и конфликтующие правила.
- Проверить
/context, если сессия выглядит перегруженной. - Только потом спрашивать себя, уперлись ли вы в границу встроенной модели.
Если проблема ощущается скорее как контекстное давление или расход usage, а не как memory-split, у нас есть отдельный гайд по usage Claude Code. Снаружи эти проблемы легко перепутать.
Когда плагин действительно помогает, а когда только усложняет все
Плагин имеет смысл тогда, когда ваш вопрос уже больше встроенной memory-модели Claude Code. Нужна память между инструментами, между машинами, общий retrieval-слой для команды или более широкая orchestration-логика? Тогда внешний слой действительно уместен.
Плагин почти всегда лишний, когда встроенная память еще даже не разложена по ролям. Если вы не разделили явные правила и обучаемые паттерны, не проверяли /memory и все еще доверяете разговору как долговременной памяти, внешний memory-layer скорее скроет путаницу, чем решит ее.
Самая безопасная стратегия консервативна: сначала довести до ума встроенный слой, потом назвать точную границу, в которую вы уперлись, и только после этого решать, нужен ли внешний инструмент.
Частые вопросы
Claude Code помнит проект между сессиями?
Да, но через слоистую встроенную память, а не через один постоянный универсальный store.
Что нужно писать в CLAUDE.md?
Все долговечные инструкции, которые должны переживать сессии: workflow, тесты, ограничения, важные архитектурные правила.
Где лежит MEMORY.md?
В текущем официальном контракте — под ~/.claude/projects/<project>/memory/. Это machine-local путь.
Почему после /compact он как будто забыл?
Потому что /compact перечитывает долговечный слой с диска. Если правило жило только в чате, оно могло исчезнуть.
Нужен ли memory-плагин?
Обычно нет. Сначала используйте встроенные поверхности правильно, и только потом решайте, нужна ли внешняя память.
Память Claude Code работает лучше всего тогда, когда вы перестаете ждать от нее одного гигантского мозга. Пишите явные правила в CLAUDE.md, отдавайте привычки на auto memory, проверяйте загрузку через /memory и /context, а наружу выходите только там, где внутренняя граница действительно мешает работе.