Claude Code: память между проектами — 3 слоя (2026)

Побеждает трёхслойная схема: CLAUDE.md хранит стабильные факты, Claude Code Skills — повторяемые процедуры, а внешняя Agent Memory — изменяющиеся предпочтения и состояние задач. Такой подход подходит тем, кто ведёт несколько репозиториев и хочет уменьшить повторный ввод правил, но не готов смешивать архитектуру разных продуктов и переносить историю одного клиента в другой проект.

Кому подходит эта схема

Руководство рассчитано на разработчиков, которые одновременно поддерживают несколько репозиториев и хотят единообразно задавать команды, стиль кода и правила ревью.

Оно также полезно техническим руководителям, которым нужно отделить командные стандарты от личных предпочтений, а затем безопасно запускать кодирующего агента в удалённой или постоянно работающей среде.

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

Сначала разделите данные по сроку жизни

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

Перед настройкой стоит разложить информацию по трём вопросам:

1. Изменится ли это редко и должно ли применяться в каждом сеансе?
   Тогда информация относится к CLAUDE.md.
2. Нужно ли выполнять это только при конкретном запросе?
   Тогда лучше использовать Claude Code Skills.
3. Меняется ли это от задачи к задаче и должно ли восстанавливаться между сессиями?
   Тогда можно рассматривать внешнюю Agent Memory.

Тип сведений	Лучшее место	Пример для вымышленного проекта «Север»	Что не следует помещать
Стабильные факты	CLAUDE.md	структура каталогов, команда тестов, архитектурные ограничения	история всех обсуждений
Повторяемая процедура	SKILL.md	выпуск релиза, проверка миграций, шаблон ревью	случайное личное предпочтение
Динамическое состояние	внешняя Agent Memory	принятое решение по задаче, незавершённый план, предпочтения разработчика	секреты, ключи, необезличенные данные клиентов
Жёсткое ограничение доступа	settings.json, hooks, права среды	запрет чтения .env, ограничение опасных команд	надежда на текстовую инструкцию

Не следует переносить между проектами:

• ключи доступа, токены и содержимое файлов окружения;
• имена клиентов, внутренние идентификаторы и фрагменты закрытой переписки;
• временные URL тестовых стендов, если они относятся только к одному репозиторию;
• решения, принятые для конкретной версии продукта;
• полные логи диалогов без срока хранения и понятного основания для их использования.

Официальная документация разделяет инструкции CLAUDE.md и автоматически накапливаемые записи: первые задаются человеком, вторые отражают обнаруженные закономерности и предпочтения. При этом оба механизма загружаются как контекст, а не как неизменяемая политика.

Шаг 1. Настройте CLAUDE.md для одного репозитория

Начинать следует не с общего пользовательского файла, а с одного проекта. Это позволяет проверить, какие правила действительно нужны, прежде чем переносить их на все рабочие каталоги.

В корне проекта «Север» можно создать такой минимальный файл:

# Проект «Север»

## Структура
- API находится в `src/api/`.
- Фоновые задачи находятся в `src/workers/`.
- Изменения схемы базы данных находятся в `db/migrations/`.

## Команды
- Установка: `npm ci`
- Проверка типов: `npm run typecheck`
- Тесты: `npm test`
- Линтер: `npm run lint`

## Ограничения
- Не изменять файлы миграций после применения без отдельного плана отката.
- Перед изменением обработчиков API сначала проверить связанные тесты.
- Не читать `.env` и файлы с секретами.

Здесь записаны факты, которые полезны почти в каждом сеансе. Полную инструкцию по выпуску релиза, включая проверки, условия отката и порядок публикации, лучше вынести в Skill: она не нужна при каждом чтении кода и будет занимать контекст без пользы.

Официальная рекомендация — держать каждый CLAUDE.md короче 200 строк, использовать конкретные команды и избегать формулировок вроде «пиши качественный код». Это ограничение и рекомендации по содержанию приведены в официальном руководстве по памяти Claude Code. Чем длиннее общий файл, тем больше контекста он занимает и тем ниже вероятность, что агент одинаково заметит все правила.

Для личных настроек, которые нельзя отправлять в репозиторий, используются пользовательский файл ~/.claude/CLAUDE.md или локальные инструкции проекта. Проектный CLAUDE.md предназначен для командных правил, а пользовательский — для личного стиля, предпочтительного редактора или привычных инструментов.

Проверка после создания:

claude
/context

В списке загруженных файлов должна появиться запись с CLAUDE.md. Команда /init помогает сгенерировать первоначальный файл на основе структуры репозитория.

Действительно ли Claude Code запоминает прошлые проекты

Нет, не в том смысле, в котором обычно понимают постоянную память. Новая сессия начинается с нового контекстного окна. Claude Code может снова прочитать пользовательские и проектные инструкции, а также доступные записи автоматической памяти, но это не означает, что он автоматически знает историю всех ранее открытых репозиториев.

Если требуется общее правило для нескольких проектов, его можно разместить в пользовательской области. Пользовательские инструкции находятся в ~/.claude/CLAUDE.md и действуют во всех проектах текущего пользователя, а проектные инструкции находятся в CLAUDE.md или .claude/CLAUDE.md внутри репозитория.

Практическая проверка должна проходить в новом сеансе и в другом репозитории:

Откройте новый сеанс.
Попросите перечислить загруженные файлы памяти.
Попросите назвать команду тестов текущего проекта.
Перейдите в другой репозиторий.
Повторите проверку и убедитесь, что проектные правила не смешались.

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

Шаг 2. Перенесите процедуры в Claude Code Skills

Когда раздел в CLAUDE.md превращается в длинный алгоритм, это сигнал для переноса в Claude Code Skills. Skill — это каталог с файлом SKILL.md, содержащим описание назначения и инструкции для конкретного действия. Формат и области действия описаны в официальной документации по Skills.

Пример Skill для проверки изменений:

---
name: review-changes
description: Проверяет изменения перед ревью, запускает безопасные проверки и перечисляет риски.
disable-model-invocation: true
---

1. Выполнить `git diff --stat`.
2. Запустить `npm run typecheck`.
3. Запустить целевые тесты изменённых модулей.
4. Проверить отсутствие секретов и отладочных логов.
5. Сформировать список найденных рисков с указанием файлов.

В отличие от постоянного текста CLAUDE.md, тело Skill загружается при использовании. Это особенно важно для процедур деплоя, миграций и выпуска: они могут быть подробными, но не должны добавляться к каждому обычному запросу о коде.

Область Skill	Путь	Область действия	Когда выбирать
Личная	~/.claude/skills/<имя>/SKILL.md	Все проекты пользователя	личный шаблон ревью или формат коммитов
Проектная	.claude/skills/<имя>/SKILL.md	Один репозиторий	деплой и тестирование конкретного продукта
Вложенная	<каталог>/.claude/skills/<имя>/SKILL.md	Подкаталог или пакет	отдельный процесс для веб-клиента
Плагинная	каталог подключённого плагина	Проекты, где включён плагин	общая команда с несколькими компонентами

При одинаковом имени правила более высокого уровня могут заменить вариант ниже: корпоративный уровень имеет приоритет над личным, личный — над проектным, а проектный вариант способен заменить встроенный Skill с тем же именем. Поэтому команде стоит использовать явные имена вроде north-release и north-api-review, а не слишком общие deploy или test. Дополнительные границы плагинов и их компонентов описаны в официальной документации по плагинам Claude Code.

Важная особенность — отслеживание изменений. Claude Code может подхватить изменения в тексте SKILL.md во время текущей сессии без перезапуска. Однако новый верхнеуровневый каталог Skills, которого не существовало при старте, может потребовать перезапуска. Поэтому это нужно проверять отдельно, а не считать любую правку «горячей загрузкой».

Шаг 3. Разделите личные, командные и плагинные правила

Для нескольких проектов удобна следующая схема:

• пользовательские Skills — личные способы ревью, формат сообщений и локальные привычки;
• проектные Skills — процедуры, которые должны быть одинаковыми у всех участников конкретного репозитория;
• плагинные Skills — повторно используемые наборы, включающие не только инструкции, но и дополнительные файлы или интеграции;
• вложенные Skills — правила отдельных пакетов в монорепозитории.

Не следует помещать в личный Skill процедуру, которую команда должна выполнять одинаково: коллеги его не увидят. И наоборот, не стоит коммитить личные тестовые URL или локальные пути в проектный Skill.

Для командного процесса полезно ввести небольшой контрольный лист:

• [ ] В описании Skill указано, когда его следует применять.
• [ ] Процедура запускается вручную, если она может менять данные или публиковать код.
• [ ] Команды разделены на безопасные и требующие подтверждения.
• [ ] В Skill нет ключей, токенов и клиентских данных.
• [ ] Результат можно проверить фиксированным тестовым сценарием.
• [ ] Изменения Skill проходят ревью так же, как изменения исходного кода.

Шаг 4. Подключайте внешнюю Agent Memory только при необходимости

Внешняя Agent Memory нужна не для копирования всей истории диалогов. Она оправдана, когда нужно восстановить динамическое состояние:

• почему команда выбрала конкретный архитектурный вариант;
• какие предпочтения разработчика были подтверждены несколько раз;
• на каком шаге остановилась длительная задача;
• какие ограничения были временно согласованы для конкретного проекта;
• какие решения нужно показать при повторном обращении к задаче.

Это уже не стандартный проектный факт и не повторяемая процедура. Однако на 10 августа 2026 года внешнюю память следует рассматривать как отдельный компонент, а не как безусловное встроенное обещание Claude Code. Официальная документация описывает файлы CLAUDE.md и автоматическую память, но стороннее хранилище, база заметок или собственный сервис требуют отдельной политики доступа, хранения и удаления.

Минимальная модель записи должна содержать:

{
  "project_id": "sever-api",
  "user_id": "developer-17",
  "type": "decision",
  "content": "Для фоновых задач сохраняется очередь с повторной доставкой.",
  "source": "task-184",
  "created_at": "2026-08-10",
  "expires_at": null
}

Здесь важны не конкретные названия полей, а четыре свойства:

1. Идентификатор проекта — исключает случайный поиск по общей коллекции.
2. Идентификатор пользователя или команды — отделяет личные предпочтения от общих решений.
3. Источник записи — позволяет проверить, откуда взялось утверждение.
4. Правило удаления — определяет, когда устаревшая запись перестаёт использоваться.

Вопрос контроля	Безопасный вариант	Опасный вариант
Разделение проектов	отдельный project_id и фильтр до поиска	одна общая коллекция без обязательного фильтра
Разделение пользователей	отдельный user_id и права доступа	общий профиль для всей команды
Точность	ссылка на задачу, коммит или решение	запись без происхождения
Срок хранения	срок действия для временных сведений	бессрочная история по умолчанию
Удаление	команда удаления и журнал операции	удаление только из интерфейса без проверки копий
Возврат контекста	показывать источник и дату	возвращать текст без объяснения

Опыт эксплуатации подсказывает: чем «умнее» автоматическая запись, тем важнее возможность удалить её вручную. Если разработчик не может увидеть, исправить и удалить сохранённое предпочтение, система быстро начинает подмешивать старые решения в новые задачи.

Как избежать утечки кода между проектами

Нельзя считать, что наличие разных каталогов автоматически обеспечивает изоляцию. Ошибка может появиться на нескольких уровнях:

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

Для снижения риска следует:

1. Присваивать каждому репозиторию отдельный идентификатор.
2. Проверять фильтр проекта до выполнения семантического поиска.
3. Запрещать чтение .env, каталогов секретов и временных экспортов.
4. Не помещать исходный код в долговечную память, если достаточно краткого решения.
5. Хранить ссылку на коммит или задачу вместо полного фрагмента файла.
6. Ограничить внешнее хранилище правами конкретного пользователя или команды.
7. Ввести срок удаления для временных сведений.
8. Проверить, что после удаления запись не возвращается из резервной копии или индекса.

Наличие текстового запрета «не читай секреты» не должно быть единственной защитой. Разрешения следует настраивать отдельно для чтения файлов, выполнения команд и доступа к каталогам; соответствующие сценарии и правила подтверждения разобраны в официальной документации по разрешениям Claude Code. Где необходимо, ограничения стоит дублировать перехватывающими hooks.

Шаг 5. Проведите проверку после перезапуска и обновления

Проверка должна имитировать реальную эксплуатацию, а не ограничиваться просмотром файлов.

Проверка загрузки правил

• [ ] Запустить Claude Code из корня проекта.
• [ ] Выполнить /context.
• [ ] Убедиться, что загружен нужный CLAUDE.md.
• [ ] Проверить отсутствие инструкций соседнего репозитория.
• [ ] Открыть новый сеанс и повторить проверку.

Проверка Skills

• [ ] Запросить процедуру, которая соответствует описанию Skill.
• [ ] Убедиться, что нужный Skill загружается автоматически или запускается вручную.
• [ ] Изменить текст SKILL.md и проверить, подхватывается ли правка.
• [ ] Создать новый каталог Skill и отдельно проверить необходимость перезапуска.
• [ ] Проверить конфликт имён между личным и проектным уровнем.

Проверка динамической памяти

• [ ] Сохранить тестовое решение с фиктивным project_id.
• [ ] Перезапустить процесс.
• [ ] Убедиться, что запись восстанавливается только в нужном проекте.
• [ ] Выполнить запрос из второго проекта с похожими словами.
• [ ] Убедиться, что первая запись не возвращается.
• [ ] Удалить запись и повторить поиск.
• [ ] Проверить журнал источника, дату и результат удаления.

Конфигурацию стоит резервировать перед обновлением. Claude Code автоматически создаёт резервные копии конфигурационных файлов и хранит пять последних копий; это поведение и связанные с ним параметры описаны в официальной документации по настройкам. Однако автоматические копии не заменяют отдельную резервную копию проектных CLAUDE.md, Skills и внешнего хранилища.

Для каждой версии инструмента полезно держать фиксированный регрессионный сценарий: открыть проект, проверить архитектурное правило, вызвать Skill ревью, завершить процесс, запустить его снова, восстановить тестовое состояние памяти и подтвердить изоляцию второго проекта. Если после обновления меняется порядок загрузки или область действия, результат должен быть зафиксирован до перехода команды на новую версию.

Готовый шаблон распределения памяти

Для большинства команд подходит следующая стартовая конфигурация:

~/.claude/CLAUDE.md
  Личные предпочтения, общие для всех проектов.

project-a/CLAUDE.md
  Архитектура, команды, ограничения и командные соглашения.

project-a/.claude/skills/
  Деплой, ревью, миграции и другие повторяемые процедуры.

Внешняя Agent Memory
  Только подтверждённые решения, незавершённые задачи и динамические предпочтения
  с обязательными project_id, user_id, источником и правилом удаления.

Если информация нужна в каждом сеансе, но относится только к одному продукту, она остаётся в проектном CLAUDE.md. Если информация нужна редко и описывает действие, её следует перенести в Skill. Если она меняется и должна пережить завершение сессии, можно подключать внешнюю память — после проверки изоляции и политики хранения.

Локальная машина удобна для первого эксперимента, но плохо подходит команде, которой нужен постоянно доступный агент: состояние зависит от одного компьютера, перезапусков и локальных прав доступа. При работе с удалённой Mac-средой можно заранее разделить каталоги, пользователей и резервные копии; варианты аренды Mac для разработки можно сопоставить на странице удалённой аренды Mac, а сведения о формате работы Zutcloud — в разделе об инфраструктуре Zutcloud.

При этом аренда не является универсальной заменой собственной инфраструктуре. Для длительной стабильной нагрузки с постоянным объёмом работ выгоднее рассмотреть собственный Mac, а при необходимости физического оборудования, локальных устройств или специальных сетевых каналов удалённая среда может не подойти. Но для временного запуска Claude Code, проверки трёхслойной памяти, изолированного командного эксперимента или восстановления окружения после обновления удалённый Mac обычно практичнее локального компьютера: не требуется привязывать тест к одному рабочему месту, проще отделить проекты и быстрее удалить временную среду. Именно в таких сценариях аренда Mac у Zutcloud даёт более управляемый путь к длительно работающему кодирующему агенту, если заранее определить доступы, сроки хранения и процедуру удаления данных.

Читать также

• Как выбрать хранилище для Agent Memory: Redis, Postgres или SaaS
• Файловая система AI Agent: изоляция workspace и отдельный слой памяти