Команда Codex CLI /memories: управление воспоминаниями агента

Слеш-команда Codex CLI /memories применяется для управления использованием и созданием воспоминаний Codex — устойчивых заметок о предпочтениях пользователя, особенностях проекта, принятых технических решениях и повторяющихся правилах работы. Благодаря этому Codex может не начинать каждый новый сеанс «с чистого листа», а учитывать ранее сохранённый контекст там, где это действительно уместно.

Воспоминания — это не архив всей истории чата и не замена документации проекта. Их задача — сохранить небольшие, полезные и относительно стабильные факты, которые помогают Codex работать точнее в будущих сессиях.

Команда /memories особенно полезна в проектах, где одни и те же решения повторяются: используются нестандартные команды сборки, определённый стиль тестов, особая структура каталогов или предпочтительный формат ответов. При этом важно понимать границы механизма: память не должна превращаться в свалку случайных фрагментов, секретов и устаревших указаний. Ниже разберём, как применять /memories, когда она помогает, чем отличается от других слеш-команд Codex CLI и как не потерять контроль над контекстом.

Как использовать /memories

Команда /memories вызывается непосредственно в интерактивном сеансе Codex CLI. Она предназначена для просмотра или управления сохранёнными воспоминаниями, однако точный набор действий может зависеть от версии Codex CLI и включённых возможностей аккаунта. Поэтому перед практическим использованием стоит проверить справку текущей версии.

Хорошее воспоминание отвечает на вопрос: «Что Codex должен помнить в будущих сеансах, потому что это регулярно экономит время?»

В типичном сценарии работа выглядит так: пользователь открывает Codex CLI, вызывает /memories, просматривает доступные записи, затем просит создать новую память или уточнить существующую. Если интерфейс конкретной версии поддерживает отдельные подкоманды, Codex подскажет допустимый синтаксис. Не стоит механически копировать команды из старых публикаций: слеш-команды могут развиваться, а экспериментальные функции — переименовываться.

Действие	Что сделать	Зачем это нужно
Проверить поддержку	Взять описание /memories	Узнать синтаксис именно установленной версии
Открыть управление памятью	Ввести /memories	Посмотреть доступные операции и сохранённые сведения
Добавить факт	Явно попросить Codex сохранить конкретное правило	Сделать важную договорённость доступной в будущих сессиях
Проверить результат	Снова открыть список или сведения о памяти	Убедиться, что формулировка не искажена
Удалить устаревшее	Использовать доступную операцию удаления или попросить Codex забыть факт	Не допускать конфликтов между старым и новым правилом

Как попросить Codex создать воспоминание

Самый безопасный способ — сформулировать просьбу явно и указать, почему правило должно жить дольше текущего диалога. Фраза «запомни это» слишком расплывчата: лучше описать конкретный факт, его область действия и возможные исключения.

Запомни для будущих сессий этого проекта: перед отправкой изменений всегда запускай
тесты через команду `npm run test:ci`, а не через интерактивный `npm test`.

После такой просьбы полезно попросить Codex показать, что именно он собирается сохранить. Это снижает риск того, что короткая команда будет преобразована в слишком широкое правило. Например, указание «используем TypeScript» не равно правилу «никогда не добавляй JavaScript»: первое описывает предпочтение, второе запрещает допустимые исключения.

Неудачная формулировка	Проблема	Улучшенный вариант
«Запомни наш стиль»	Непонятно, о каком стиле речь	«В новых TypeScript-файлах используй одинарные кавычки и не ставь точки с запятой»
«Всегда делай правильно»	Нет проверяемого содержания	«Для API-ошибок используй объект с полями code и message»
«Запомни эту задачу»	Задача может быть одноразовой	«Запомни, что каталог legacy/ нельзя менять без отдельного согласования»
«Никогда не меняй конфиг»	Слишком жёсткое правило, мешающее работе	«Не изменяй CI-конфигурацию без явного подтверждения пользователя»

Как просматривать и проверять воспоминания

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

/memories

Проверь, какие воспоминания относятся к текущему проекту, и перечисли те,
которые влияют на выбор команд тестирования или формат кода.

Если запись сформулирована слишком широко, её лучше уточнить или удалить и создать заново. Память «проект использует строгие правила» почти бесполезна, а запись «для публичных методов требуется JSDoc с описанием параметров» уже может направлять поведение агента.

Признак качественной памяти	Пример	Почему это хорошо
Конкретность	«Для миграций используй pnpm db:migrate»	Правило можно однозначно применить
Ограниченная область	«В сервисе платежей…»	Правило не распространяется на весь монорепозиторий
Стабильность	«Основной язык проекта — TypeScript»	Факт редко меняется от задачи к задаче
Проверяемость	«Тесты запускаются через make test»	Результат можно быстро проверить
Отсутствие секретов	«Токены лежат в локальном менеджере секретов»	В памяти нет паролей и ключей

Как обновлять и удалять устаревшие сведения

Любая память со временем может стать неверной. Команда сборки меняется, команда переходит с REST на GraphQL, каталог переезжает, а временное ограничение внезапно начинает восприниматься как вечный закон. Поэтому управление памятью включает не только создание, но и регулярную ревизию.

Не оставляй старое правило без проверки.

Текущее правило: тесты запускаются через `yarn test`.
Новое правило: после перехода на pnpm используй `pnpm test`.
Удали или замени старую память, чтобы Codex не выбирал между двумя командами.

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

Ситуация	Рекомендуемое действие	Чего избегать
Изменился скрипт сборки	Обновить память с новой командой	Добавлять вторую запись, не удаляя старую
Правило больше не действует	Удалить его	Оставлять пометку «временно не использовать» на неопределённый срок
Правило относится только к одному модулю	Уточнить область действия	Распространять его на весь проект
Непонятно происхождение записи	Проверить её по документации и истории проекта	Слепо считать память истинной

Что нельзя сохранять в память

Память не предназначена для хранения конфиденциальных данных. В неё не должны попадать пароли, API-ключи, токены, приватные URL с параметрами доступа, персональные данные и содержимое закрытых документов. Даже если запись кажется удобной, риск утечки обычно значительно выше сиюминутной пользы.

Плохо:
Запомни API-ключ staging: sk-live-xxxxxxxxxxxxxxxx

Хорошо:
Для доступа к staging используй переменные окружения из локального менеджера секретов.
Никогда не вставляй значения секретов в команды, ответы и коммиты.

Тип информации	Можно сохранять?	Безопасная альтернатива
Стиль именования	Да	Сохранить краткое правило
Команды тестирования	Да	Указать команду и область применения
Пароли и токены	Нет	Использовать Secret Manager или переменные окружения
Пути к локальным файлам	Осторожно	Сохранять только стабильные проектные пути без личных данных
Персональные данные клиентов	Нет	Использовать обезличенные примеры

Когда применять /memories

/memories лучше всего подходит для повторяющихся и долгоживущих сведений. Если правило нужно один раз, его достаточно написать в текущем сообщении. Если оно должно быть видно каждому разработчику и проверяться в ревью, его следует разместить в документации или конфигурации репозитория. Память находится между этими двумя вариантами: она персонализирует работу Codex, но не заменяет коллективный источник истины.

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

Хороший кандидат для памяти — устойчивое предпочтение пользователя или рабочая привычка команды, которая не отражена в автоматических проверках. Например, разработчик может предпочитать сначала получать план изменений, а уже потом патч. Но если правило касается безопасности, релизов или обязательных проверок, его лучше дополнительно закрепить в репозитории, CI или инструкции проекта.

Сценарий	Подходит ли память	Лучшее место для правила
Предпочтительный стиль ответа	Да	Память пользователя
Команда запуска тестов	Да, если она стабильна	Память плюс package.json или документация
Обязательная проверка перед merge	Недостаточно	CI и правила репозитория
Одноразовая задача	Нет	Текущий чат
Архитектурное решение команды	Ограниченно	ADR, README или проектная документация

Повторяющиеся рабочие процессы

Если вы регулярно просите Codex выполнять один и тот же набор действий, память может убрать лишние уточнения. Это особенно заметно в тестировании, генерации миграций, подготовке pull request и анализе логов.

Запомни: при работе с изменениями в API сначала проверь типы,
затем запусти unit-тесты затронутого модуля, а полный набор тестов
запускай только после успешной локальной проверки.

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

Личные предпочтения пользователя

Команда полезна, когда Codex должен учитывать индивидуальный стиль работы: отвечать по-русски, показывать сначала краткий план, не менять файлы без подтверждения или давать команды для Linux вместо Windows. Такие сведения редко принадлежат конкретной задаче, но часто влияют на качество взаимодействия.

Запомни моё предпочтение: перед изменением нескольких файлов
сначала показывай краткий план, список затронутых путей и риски.
Изменения выполняй только после моего подтверждения.

Здесь важно отделять предпочтение от обязательного правила проекта. Личное пожелание может быть сохранено в памяти пользователя, но командное требование вроде «все изменения должны проходить через форматтер» должно быть зафиксировано в проектной конфигурации.

Нестандартная структура проекта

В больших репозиториях Codex может потратить время на поиск очевидных для команды вещей: где лежат контракты, какие каталоги являются сгенерированными, какой сервис отвечает за авторизацию. Краткая память помогает быстрее ориентироваться, если структура стабильна и не описана достаточно ясно в README.

Запомни для этого проекта:
каталог `services/auth` содержит сервер авторизации,
`packages/contracts` — общие API-контракты,
а файлы в `generated/` нельзя редактировать вручную.

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

Повторяющиеся технические ограничения

Воспоминание может напомнить о техническом ограничении, которое легко забыть: совместимость с определённой версией Node.js, запрет на конкретную библиотеку, необходимость поддерживать старый формат данных или особый порядок миграций.

Запомни: сервис платежей пока работает на Node.js 18.
Не используй API, доступные только в Node.js 20 и новее,
пока файл совместимости проекта не будет обновлён.

Такое воспоминание не заменяет поле engines, файл CI или автоматическую проверку версии. Если ограничение критично, его нужно дублировать там, где машина сможет гарантированно его проверить.

Переход между сессиями

Память особенно заметна после паузы в работе. Вчера вы объяснили, что тестовый сервер запускается отдельной командой и использует мок внешнего платёжного шлюза, а сегодня открыли новый сеанс. Если факт действительно сохранён, его не придётся повторять — но всё равно стоит проверить, не изменились ли обстоятельства.

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

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

Примеры использования /memories

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

Пример 1. Сохранение команды тестирования

Команда проекта использует нестандартный скрипт, и разработчику приходится напоминать его Codex почти в каждом диалоге. В память можно сохранить название команды, но желательно также указать, для каких случаев она предназначена.

/memories

Запомни для проекта:
для быстрых проверок используй `pnpm test:unit`,
для полного набора проверок — `pnpm test:ci`.
Не запускай `pnpm test:watch` в автоматическом режиме.

Такое описание лучше, чем простое «используй pnpm», потому что разделяет быстрый и полный сценарии и предотвращает запуск интерактивной команды.

Пример 2. Запрет на изменение сгенерированных файлов

Генерируемые файлы часто выглядят как обычный исходный код. Codex может попытаться исправить их напрямую, если не знает принятого процесса. Память помогает напомнить об ограничении, но рядом с ней должна быть команда генерации.

Сохрани правило проекта:
файлы в `src/generated/` не редактируются вручную.
После изменения схемы запускай `pnpm generate:api`,
а затем проверяй получившийся diff.

Наличие команды генерации делает правило практичным: Codex получает не только запрет, но и допустимый следующий шаг.

Пример 3. Сохранение формата ответов

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

Запомни моё предпочтение:
отвечай на русском языке, сначала давай краткий план,
после выполнения перечисляй изменённые файлы и команды проверки.
Не вставляй полный diff, если я отдельно его не попросил.

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

Пример 4. Обновление устаревшей памяти

Предположим, проект перешёл с npm на pnpm. Оставшаяся старая запись способна приводить к неверным командам. В этом случае важно не просто добавить новое сведение, а явно устранить старое.

Устарело: зависимости устанавливаются через `npm install`.

Актуально: проект использует `pnpm install --frozen-lockfile`.
Замени старое воспоминание и не оставляй две противоречивые инструкции.

После обновления стоит открыть /memories и проверить, что в списке не осталось конкурирующих правил.

Пример 5. Безопасная работа с секретами

Задача может требовать доступа к staging-среде, но память не должна содержать сам токен. В неё можно записать только способ получения секрета и запрет на его вывод.

Запомни:
секреты staging берутся из 1Password через внутренний скрипт,
их нельзя печатать в терминал, добавлять в diff или вставлять в ответы.
Самих значений секретов в памяти не сохраняй.

Это полезное правило поведения, не раскрывающее конфиденциальные данные. При этом доступы всё равно должны контролироваться отдельными средствами безопасности.

Чем /memories отличается от других команд

Слеш-команды Codex CLI похожи по форме, но решают разные задачи. /memories работает с долговременными сведениями, /skills подключает специализированные инструкции и рабочие возможности, /init помогает подготовить инструкции проекта, а /compact уменьшает объём текущего контекста чата. Ошибка в выборе команды приводит к путанице: временное решение пытаются сохранить навсегда, а проектное правило — спрятать в личной памяти.

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

Команда	Что меняет	Срок действия	Основное назначение
/memories	Сохранённые сведения и предпочтения	Между подходящими сессиями	Не повторять стабильные факты
/skills	Доступные специализированные навыки	Пока навык доступен и применим	Использовать описанный рабочий процесс
/init	Инструкции проекта и стартовую настройку	В пределах репозитория	Зафиксировать правила для работы с кодовой базой
/compact	Представление текущего контекста	Текущий чат	Уменьшить объём истории и освободить контекст

/skills: специализированные навыки

Команда /skills связана с навыками — наборами инструкций, которые помогают Codex выполнять определённые типы задач. Навык может описывать процесс работы с документацией, тестированием, миграциями, дизайном или другим направлением. Это не то же самое, что короткое воспоминание вроде «пользователь предпочитает русский язык».

Если память отвечает на вопрос «что полезно знать о моём обычном контексте?», то навык отвечает на вопрос «как выполнять определённый класс работы?». Навык обычно содержит более подробный процесс, условия применения и ожидаемый результат.

Критерий	/memories	/skills
Содержание	Короткий устойчивый факт	Инструкции и методика выполнения задачи
Пример	«Отвечай на русском»	«Как подготовить и проверить миграцию базы»
Масштаб	Обычно небольшой	Может включать несколько шагов и файлов
Использование	Фоновая персонализация	Осознанное применение подходящего процесса

/skills

Покажи доступные навыки, связанные с тестированием API.
Для постоянного личного предпочтения используй `/memories`,
а не создавай отдельный навык.

/init: постоянные инструкции проекта

Команда /init предназначена для начальной настройки работы Codex с репозиторием. В зависимости от версии и конфигурации она может помогать создать или подготовить файл с инструкциями проекта. Такие инструкции находятся рядом с кодом и предназначены не только одному пользователю, но и самому проекту как рабочей среде.

Если правило должно быть одинаковым для всей команды, его обычно лучше оформить через /init и проектный файл инструкций. Например, порядок запуска тестов, запрет на редактирование сгенерированных файлов и требования к миграциям должны быть видны в репозитории и проходить обычный review.

Правило	Память	Инструкции через /init
«Показывай сначала план»	Подходит	Обычно избыточно
«Не меняй схему без миграции»	Недостаточно	Подходит
«Команда команды — pnpm test:ci»	Можно как напоминание	Лучше закрепить в проекте
«Я предпочитаю короткие ответы»	Подходит	Не стоит навязывать всей команде

/init

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

Важно просмотреть результат работы /init. Автоматически созданные инструкции могут быть неполными или слишком общими. Файл проекта — часть коллективного контракта, поэтому его следует редактировать так же внимательно, как исходный код.

/compact: сжатие контекста текущего чата

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

Сжатие контекста не означает создание воспоминания. После завершения или смены рабочего сценария краткое резюме чата не становится автоматически постоянным правилом проекта.

Мы обсудили три варианта миграции, выбрали второй,
изменили `src/db/schema.ts` и ещё не запускали интеграционные тесты.

/compact

Ситуация	Нужная команда	Почему
Чат стал слишком длинным	/compact	Нужно освободить место в текущем контексте
Нужно сохранить команду тестов на будущее	/memories	Факт должен пережить текущую сессию
Нужно задать правила всему репозиторию	/init	Инструкция должна находиться рядом с кодом
Нужно выполнить специализированный процесс	/skills	Требуется набор профильных инструкций

Разница между воспоминаниями и постоянными инструкциями проекта

Воспоминание обычно связано с пользователем или устойчивым рабочим контекстом, а постоянная инструкция проекта — с самой кодовой базой. Например, предпочтение «объясняй изменения простыми словами» персонально. Правило «перед merge запускай линтер» относится к проекту и должно быть доступно каждому участнику.

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

Вопрос	Если ответ «да»	Куда помещать правило
Оно относится к личному стилю пользователя?	Да	Память
Оно обязательно для всех участников?	Да	Инструкции проекта
Оно проверяется автоматически?	Да	CI, конфигурация или тесты
Оно нужно только сегодня?	Да	Текущий чат
Оно описывает многошаговую методику?	Да	Навык или документация

Практическая стратегия работы с воспоминаниями

Чтобы /memories приносила пользу, достаточно соблюдать несколько простых принципов: сохранять только стабильные факты, указывать область действия, не помещать секреты, периодически пересматривать записи и дублировать критические правила в проверяемых инструментах. Это превращает память из «магии на фоне» в управляемый слой контекста.

Чем важнее правило, тем меньше следует полагаться только на память модели: критические ограничения должны подтверждаться кодом, CI или документацией.

Перед сохранением нового факта задайте себе три вопроса:

• Понадобится ли это в нескольких будущих сессиях?
• Можно ли сформулировать правило одной-двумя точными фразами?
• Не лучше ли разместить его в репозитории, чтобы его видела вся команда?

Шаг	Проверка	Результат
1. Определить факт	Это действительно повторяется?	Отсекаются одноразовые детали
2. Ограничить область	К какому проекту, модулю или пользователю относится правило?	Снижается риск неправильного применения
3. Убрать секреты	Нет ли токенов, паролей и персональных данных?	Сохраняется безопасная версия
4. Проверить формулировку	Можно ли выполнить правило однозначно?	Codex получает практичную инструкцию
5. Пересмотреть позже	Факт всё ещё актуален?	Память не накапливает технический мусор

Итоговая рекомендация проста: используйте /memories для небольших устойчивых сведений и личных рабочих предпочтений, /skills — для специализированных процессов, /init — для постоянных инструкций репозитория, а /compact — когда нужно облегчить текущий длинный диалог. Такое разделение помогает Codex понимать не только что делать, но и где должна жить соответствующая информация.

Память: личные предпочтения и стабильные факты.
Навык: подробная методика специализированной работы.
Инструкции проекта: общие правила репозитория.
Сжатие: компактное продолжение текущего чата.

Не сохраняй секреты и не делай память единственным механизмом контроля безопасности.