Пам’ять 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 починається з чистого контекстного вікна — агент не пам’ятає минулу розмову. За офіційною документацією знання через цей розрив переносять рівно два механізми, і різниця між ними принципова.

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. Вона не синхронізується між пристроями та хмарними середовищами. У колеги на іншому ноутбуці — своя, окрема тека пам’яті. Для розподіленої команди це прямий ризик розсинхронізації: агент в одного розробника «знає» одне, в іншого — інше.

Чому агент «забуває»: ліміт завантаження 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 — це буквально «хто ви і як працюєте»). Варто розуміти, що там лежить, і періодично заглядати в теку через /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 й огляд теки пам’яті.