FIMemory

Локальное хранилище, которое ваши ИИ-инструменты смогут читать после подключения и по вашей команде.

FIMemory (FI Memory, от Future Industries) хранит ваши заметки на вашем собственном компьютере и подключает к ним ваши ИИ-инструменты, чтобы вам не приходилось заново объяснять один и тот же проект в каждой сессии. Хранилище — это обычная папка с вашими файлами: никакого проприетарного формата, сервера, аккаунта, ничего никуда не загружается. Новые хранилища по умолчанию зашифрованы в состоянии покоя. Вы выбираете кодовую фразу, одноразово выводится 24-словесная фраза восстановления, и файлы остаются приватными, где бы они ни находились: в git-хостинге, облачном бэкапе, на USB-флешке. Предпочитаете файлы, которые можно открыть в текстовом редакторе? Обычный текст — это один явный выбор при настройке, а зашифрованное хранилище в любой момент экспортируется в читаемый Markdown, защищённый только вашим ключом.

Начнём здесь

Две команды.

npm i -g fimemory
fimemory setup

Если первая команда завершится с ошибкой EACCES: permission denied (часто бывает в macOS, где глобальная папка npm по умолчанию принадлежит root), укажите npm папку, которая принадлежит вам, и повторите попытку. Sudo не нужен:

npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc
npm i -g fimemory

Затем закройте и снова откройте все уже запущенные ИИ-инструменты, потому что они читают свои настройки при запуске.

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

При создании хранилища в терминале setup проведёт вас через шифрование: вы выбираете кодовую фразу (или нажимаете одну клавишу, чтобы отказаться с помощью --plaintext), он один раз выводит вашу 24-словесную фразу восстановления и просит подтвердить, что вы её записали, а затем оставляет хранилище разблокированным на этом компьютере примерно на 8 часов. В скрипте или CI подсказок нет: передайте --passphrase "...", установите GESTALT_PASSPHRASE или укажите --plaintext. Если ничего из этого не задано, он аккуратно откажется, а не будет угадывать. Потеряете и кодовую фразу, и 24-словесную фразу — данные исчезнут, это предусмотрено дизайном; такова цена «ваш ключ, а не наши серверы», и интерактивный запуск не даст этому случиться молча.

Один шаг, который setup не может выполнить за вас, — это Claude Code, который управляет собственным конфигурационным файлом. setup проверяет, существует ли команда claude на этом компьютере: если да, он выводит одну строку claude mcp add для вставки. Если нет (расширение VSCode и десктопное приложение не устанавливают командную строку), он выводит точный JSON-блок и файл, в который его нужно поместить. В любом случае это появится в разделе «Следующие шаги», а не проскочит мимо.

Если какой-то шаг не удался, выполнение продолжается, и ошибка получает собственную строку. Исправьте эту строку, запустите fimemory setup снова, и уже выполненные шаги останутся на месте.

Три команды, которые понадобятся позже:

• fimemory onboard — это пошаговый первый шаг ПОСЛЕ setup: он проведёт вас через одобрение первого предложенного изменения, задаст три вопроса о том, как вы работаете, и запишет ответы в хранилище, а затем покажет поиск, отвечающий на основе ваших собственных фактов. Подключённое хранилище, в котором о вас нет ничего, кажется сломанным, даже если ничего не сломано; это самый короткий путь это исправить.

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

• fimemory setup --plaintext выполняет ту же установку, но с НЕзашифрованным хранилищем: каждый файл читается в текстовом редакторе — и вами, и любым человеком или программой с доступом к папке. Это реальный выбор, о котором сказано прямо, а не скрытое ухудшение. Хранилище, начавшее с обычного текста, позже можно зашифровать с помощью fimemory encrypt (дешевле всего до накопления реального контента).

Раньше рабочая установка и мёртвая выглядели одинаково. Теперь установка сама сообщает, какая у вас.

Related MCP server: Munin Memory

Честные ожидания

• Установлено и используется человеком на Windows, macOS и Linux. Это не заявление на бегу: это ручные установки на реальных машинах, которые затем выполняли реальную работу, причём два разных ИИ-инструмента ежедневно в течение месяцев читали и писали в одно хранилище. Windows-машина и Mac запускают Claude Code и Grok; Linux-машина работает без головы. CI дополнительно собирает, проверяет типы, тестирует и глобально устанавливает упакованный пакет на Linux- и macOS-раннерах при каждом пуше. Чего это по-прежнему не покрывает, так это длинного хвоста хост-приложений: у раннера нет десктопной сессии, поэтому для любого клиента, кроме перечисленных ниже, мы не видели, чтобы конфиг, записанный setup, действительно загружался. В Linux командам буфера обмена нужен xclip или wl-clipboard на Wayland, и ни один из них не установлен по умолчанию. Запустите fimemory doctor, если что-то выглядит не так, и, пожалуйста, сообщите об этом.

• Это не дешевле, чем не помнить. Это оправданная небольшая наценка и гораздо дешевле, чем вставлять всё вручную.

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

• Автоматическая синхронизация не входит в комплект. Работа с несколькими машинами осуществляется через ваш собственный git-remote под вашей учётной записью. Сервиса синхронизации пока нет, поэтому ничто из написанного вами не покидает ваш компьютер, если вы сами не настроите удалённый репозиторий.

• Поставляемый объём — ваши машины, несколько агентов. Направьте две машины на один приватный git-remote: fimemory join <url> на второй машине, затем fimemory pull до и после сессий. Правки одной и той же заметки никогда не сливаются молча; проигравшая сторона становится ожидающей предложением для вашего ревью. Командных функций помимо вашего собственного remote в нём нет.

Что именно делает setup

Пять шагов, в таком порядке:

1. init, только если в ~/.fimemory нет хранилища (существующий ~/.gestalt от более ранней установки обнаруживается и сохраняется). Пропускается, никогда не перезаписывается, если он уже там.

2. install-mcp, который записывает запись MCP-сервера в каждый найденный файл конфигурации хоста. Именно это даёт ассистенту возможность читать хранилище.

3. install-hooks, который записывает хук извлечения Claude Code в ~/.claude/settings.json. Пропускается, если ~/.claude не существует.

4. install-rules, который записывает блок правил памяти в файл правил каждого хоста. Именно это заставляет ассистента действительно использовать хранилище.

5. doctor, который считывает всё это обратно и сообщает.

Хуки выполняются до правил намеренно. Текст правила shim сообщает модели, что релевантные заметки уже могут быть в ходе, внедрённые хуком извлечения. Это предложение истинно только после установки хука, поэтому хук идёт первым, и его результат выбирает формулировку: установлен хук — Claude Code получает формулировку shim, пропущен хук — все хосты получают формулировку «сначала поиск», что верно безоговорочно. Запись формулировки shim без хука сказала бы модели прекратить поиск в обмен на внедрение, которое никогда не произойдёт, что хуже, чем ничего не делать.

Каждый шаг обёрнут так, что сбой становится строкой этого шага, а выполнение продолжается. Файл правил, который нельзя записать, никогда не должен стоить вам регистрации MCP, и ни то, ни другое не должно лишать вас вердикта doctor о том, что именно сработало. setup также работает с зашифрованным запертым хранилищем, что обычно для второй машины, и позволяет doctor сообщить о блокировке.

Отдельные команды по-прежнему существуют и работают сами по себе: init, install-mcp, install-hooks, install-rules, doctor.

Какой инструмент что получает

* Подтверждено вендором, не проверено на диске. Windsurf, Cursor и Claude Desktop не установлены ни на одной проверенной нами машине, поэтому мы никогда не видели, чтобы эти пути существовали. Если какой-то из них игнорирует хранилище после того, как setup сообщил installed, это первое, что следует заподозрить: проверьте в настройках самого приложения, где оно действительно хранит правила, и заново запустите fimemory install-rules --file <path>. Каждая остальная строка таблицы была увидена на диске.

• Claude Code — единственный хост, в который install-mcp не пишет. CLI Claude Code владеет схемой ~/.claude.json, поэтому мы выводим claude mcp add fimemory -s user -- .... Его блок правил и его хук записываются за вас.

• Cursor: мы не пишем файл правил Cursor. Где Cursor хранит пользовательские правила и загружает ли он ~/.cursor/rules, не проверено. Cursor не установлен ни на одной проверенной нами машине, и на этом диске нет документации Cursor. Более ранняя версия этой страницы утверждала эти ограничения как факт; они никогда не были прочитаны из источника, что является той же ошибкой, что и ~/.grok/GROK.md ниже, поэтому они удалены. Сторонние свидетельства указывают в другую сторону: собственный 12-project-rules.md Grok перечисляет ~/.cursor/rules/ как каталог правил, который он сканирует. Если вы знаете файл, который читает Cursor, install-rules --file <path> записывает туда тот же блок.

• Claude Desktop: мы не пишем файл правил Claude Desktop. Есть ли у него вообще файл правил на диске, не проверено. Он не установлен ни на одной проверенной нами машине. Его MCP-конфиг записывается.

• Gemini CLI позволяет переименовать свой контекстный файл с помощью contextFileName в ~/.gemini/settings.json. install-rules читает это и учитывает, поэтому блок попадает в файл, который Gemini действительно читает.

• Всё остальное, включая неизвестные нам хосты: install-mcp выводит универсальный JSON-фрагмент для вставки в собственный конфиг этого клиента.

Проверено человеком от начала до конца: Claude Code и Grok на Windows 11 и macOS. Это те комбинации, которые были установлены и использовались для реальной работы ежедневно с общим хранилищем. Каждый другой хост в таблице получает свой конфиг и правила; честная матрица по хостам поставляется по мере измерения, а не раньше.

Если хост находится в необычном месте: install-rules, install-mcp и doctor следуют за CODEX_HOME, GEMINI_CLI_HOME и GROK_HOME, когда они заданы, так что все трое сходятся в том, где находится хост. Путь к конфигу Claude Desktop зависит от вашей платформы (и от APPDATA в Windows). Остальные пути, Cursor и Windsurf, фиксированы.

Хук, если точно

install-hooks записывает ровно один файл: ~/.claude/settings.json от Claude Code. Это утверждение о данном программном обеспечении. Это не заявление о том, что у других инструментов нет хуков, и версия этого предложения, в которой такое утверждение было, была проверена 2026-07-31 и оказалась ложной.

Grok CLI, проверено лично на диске с grok 0.2.117, 2026-07-31. Grok сканирует ~/.claude/settings.json на предмет хуков по умолчанию ([compat.claude] hooks = true, описано в ~/.grok/docs/user-guide/05-configuration.md, а таблица Hook Locations в 10-hooks.md перечисляет этот файл как глобальный источник, которому всегда доверяют). Он загружает наши два обработчика. Он не может доставить инъекцию по двум независимым причинам:

1. Grok отбрасывает stdout хука. Это та причина, которая имеет значение, потому что её нельзя обойти. Мы это измерили: четыре формы вывода (Claude'овский hookSpecificOutput, верхнеуровневый additionalContext, обычный текст, systemMessage), каждая из которых, как подтверждено, действительно срабатывала по маркерному файлу, который она записывала, не давала никакого инъектированного контекста, при положительном контроле, который доказал, что обвязка вообще может выводить инъектированный контекст на поверхность. Измерено в headless-режиме -p; интерактивный TUI не измерялся. Собственная документация Grok этого не проясняет. 10-hooks.md говорит только, что PreToolUse и события остановки могут принимать решения, и «все остальные события пассивны», а в разделе Passive Hooks говорится, что stdout игнорируется "для таких событий, как SessionStart или PostToolUse", называя примеры, а не UserPromptSubmit, поэтому именно эксперимент здесь является авторитетом, а не документация.

2. В его формате обработчика нет поля args. Таблица Key Fields в 10-hooks.md перечисляет type, command, url, timeout и env, а весь наш вызов живёт в args. Grok запускает интерпретатор без аргументов, и этот процесс немедленно умирает. Это выглядит исправимым, потому что command принимает встроенную shell-команду, но исправление лишь заставит хук выполняться. Он всё равно ничего не инъектирует из-за (1).

Ничто не блокируется в любом случае: Grok не работает в режиме fail-open. Но "fail-open" — это не "молчание". 10-hooks.md говорит, что каждый сбой хука записывается в прокрутку UI, так что вы увидите строку сбоя хука на каждом запросе Grok. Если хотите от неё избавиться, установите [compat.claude] hooks = false в ~/.grok/config.toml. Не удаляйте обработчики из ~/.claude/settings.json. Это файл, который на самом деле использует Claude Code, и их удаление отключает единственный хост, где хук работает.

Grok также читает ~/.claude/CLAUDE.md. Файл правил не является приватным для хоста, в чьём каталоге он лежит. 12-project-rules.md у Grok говорит, что при включённой совместимости с Claude (по умолчанию) он сканирует ваш домашний ~/.claude/ на предмет CLAUDE.md среди прочих, а grok inspect --json на реальной машине перечислил именно этот файл. Так что на машине с Claude Code + Grok формулировка шима, написанная "для Claude Code", тоже достигала Grok. Теперь это не так: когда обнаруженный хост, который не может выполнять хук, разделяет файл правил, этот файл получает формулировку "сначала поиск", кто бы его номинально ни владел. fimemory doctor сообщает, какое тело несёт каждый файл правил, а не просто то, что там есть блок.

Codex CLI имеет хуки. Прочитано в его поставляемом бинарнике, @openai/codex 0.145.0, 2026-08-01: набор событий включает user_prompt_submit, session_start, pre_tool_use и stop; бинарник несёт пути исходников hooks/src/events/ и загрузчик hooks/hooks.json. Мы не пишем конфигурацию хуков Codex, поэтому наш хук там не выполняется. Будет ли наш обработчик работать под Codex, то есть его схема обработчика и будет ли stdout хука user_prompt_submit инъектироваться, — не проверено, и никаких утверждений в ту или иную сторону не делается.

Gemini CLI имеет хуки и поставляет собственную импортную функцию для того самого файла, который мы пишем. Прочитано в @google/gemini-cli 0.52.0, 2026-08-01: UserPromptSubmit сопоставляется с событием BeforeAgent у Gemini, а gemini hooks migrate читает <cwd>/.claude/settings.json и импортирует его хуки. Одно предупреждение, если вы используете эту команду: её импортёр копирует только command, type и timeout и отбрасывает args, точно как Grok. Запустите её в каталоге, где .claude/settings.json содержит наши обработчики, и получите node-процесс, который падает на каждом запросе. Мы не пишем конфигурацию хуков для Gemini, так что это происходит только если вы сами запустите миграцию.

Windsurf и Claude Desktop: поддерживают ли они хуки вообще — не проверено. Ни один из них не установлен ни на одной проверенной нами машине. Мы не пишем конфигурацию хуков ни для того, ни для другого и не заявляем никаких ограничений сверх этого.

Cursor: документация Grok фиксирует файл хуков Cursor (~/.cursor/hooks.json). Мы его не пишем и не тестировали наш обработчик против него.

fimemory install-rules --list-hosts печатает всё это для вашей машины: какие хосты обнаружены, где каждый хранит свой файл правил, и причину хука для каждого хоста с его источником.

Почему блок правил — это та часть, которая важна

install-mcp даёт вашему ассистенту возможность читать хранилище. install-rules --mode shim — это то, что заставляет его читать хранилище без запроса, инъектируя соответствующие заметки перед вашим запросом. По нашим собственным измерениям это стоит доли того, что стоит позволить ассистенту искать в хранилище через вызовы инструментов. Без этого инструменты присутствуют и в основном простаивают.

Формулировка шима записывается только в файл, который читается исключительно хостами, где хук извлечения действительно выполняется, что сегодня означает Claude Code на машине без Grok CLI. Каждый другой файл получает блок "поиск первым" вместо этого — формулировку, которая говорит этим ассистентам вызывать fimemory_search самим, поскольку для них ничего не инъектируется. Установите Grok CLI, и ~/.claude/CLAUDE.md вернётся к формулировке "поиск первым" при следующем setup, потому что Grok читает этот файл тоже.

Когда что-то выглядит неправильно

fimemory doctor проверяет режим хранилища, источники ключей, регистрацию MCP в каждом конфиге хоста, блоки правил, хук извлечения, индекс каталога и когда хранилище последний раз читалось. Он называет, чего не хватает и что с этим делать, и завершается с ненулевым кодом, когда что-то действительно сломано. Хранилище, чей индекс отсутствует или не перечисляет заметки, которые есть на диске, — это сбой, а не предупреждение: поиск читает индекс, так что слепой индекс означает, что ассистент тихо ничего не находит.

Шифрование в покое (по умолчанию)

Новые хранилища запечатаны XChaCha20-Poly1305 за парольной фразой Argon2id, и 24-словная фраза восстановления печатается один раз при создании (fimemory encrypt приводит более старое или --plaintext хранилище в то же состояние). Потеряйте и парольную фразу, и эту фразу — и данные исчезнут, по замыслу. Нет аккаунта и нет сброса, и именно поэтому фраза важна.

Инструменты открывают хранилище с GESTALT_PASSPHRASE. Установите её так, как хочет ваша собственная оболочка:

$env:GESTALT_PASSPHRASE = 'your passphrase here'          # PowerShell
set "GESTALT_PASSPHRASE=your passphrase here"             # cmd.exe
GESTALT_PASSPHRASE='your passphrase here' fimemory list   # macOS, Linux

Одна разблокировка держит команды быстрыми около 8 часов (sessionKeyCacheTtlHours, 0 отключает это). fimemory lock завершает её досрочно.

Правда на второй день, чтобы вас ничего не удивило: когда это окно истекает и в окружении нет парольной фразы, CLI-команды спрашивают снова, MCP-инструменты отвечают на каждый вызов явной ошибкой "хранилище заблокировано", которая называет исправление (установите GESTALT_PASSPHRASE там, где работает инструмент, или fimemory unlock в любом терминале; работающий сервер подхватывает разблокировку при следующем вызове, без перезапуска), а хук извлечения на каждый запрос остаётся молчаливым, а не блокирует ваш запрос. fimemory doctor — это то, что называет ЭТО состояние вслух. GUI-приложения (Claude Desktop и другие) читают системное окружение пользователя, а не ваш профиль оболочки, так что поместите переменную туда, где её видит сессия рабочего стола.

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

Удаление

Одна команда на слой, и каждая касается только того, что написал её установщик:

fimemory uninstall-mcp      # remove the MCP entry from every host config
fimemory uninstall-rules    # remove the memory rule block, nothing else in the file
fimemory uninstall-hooks    # remove our two handlers from Claude Code's settings

Единого глагола удаления пока нет, поэтому uninstall-mcp печатает две другие команды, и весь откат остаётся на одном экране.

uninstall-mcp — это тот же скан, что и install-mcp, с пустой подстановкой: те же хосты, те же файлы, то же правило, что каталог конфига хоста решает, установлен ли он. Он удаляет нашу запись и ничего больше. Конфиг, который он не может разобрать, отклоняется и остаётся байт-в-байт идентичным, а не переписывается, и отказ — это выход 1, так что fimemory uninstall-mcp && rm -rf ~/.fimemory останавливается, а не продолжается. Хост, в котором нет ничего нашего, — это успех и выход 0.

Claude Code симметричен установке: мы печатаем claude mcp remove fimemory -s user и читаем ~/.claude.json только для чтения, чисто чтобы сказать вам, зарегистрирована ли там запись.

Порядок парольной фразы, прежде чем что-то удалять

Если вы когда-либо запускали install-mcp --env-passthrough GESTALT_PASSPHRASE, парольная фраза к вашему зашифрованному хранилищу лежит в этих конфигах хостов в открытом виде. Удаление нашей записи удаляет её вместе с записью, и для некоторых людей этот конфиг-файл — единственная существующая копия. Так что порядок важен в обе стороны:

• Сохранить хранилище: убедитесь, что вы всё ещё можете открыть его, с парольной фразой, которую вы помните, или вашей 24-словной фразой восстановления, ПРЕЖДЕ чем что-либо удалять. Сначала запустите fimemory uninstall-mcp --dry-run. Он называет переменные окружения, которые удалит, никогда их значения, и ничего не записывает.

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

• Собственный бинарник Claude Code утверждает, что claude mcp remove навсегда удаляет конфиг сервера, включая переменные окружения и заголовки, так что напечатанная команда забирает эти значения с собой тоже.

Само хранилище — это ваша папка, так что удаление его — это удаление каталога: ~/.fimemory (или ~/.gestalt на установке, предшествующей переименованию), или там, куда вы указали --home. Экспортируйте сначала, если хотите сохранить заметки.

Ваши файлы, ваш выход

fimemory export --plaintext <dir> записывает каждую заметку, лог и предложенное изменение как обычный Markdown вне хранилища. Запасной выход реален и работает с первого дня.

Примечание о названии

Всё, что видит пользователь, называется fimemory: команда, ключ MCP-сервера и идентификаторы инструментов (fimemory_search, fimemory_get, ...). Установки, предшествующие переименованию, продолжают работать: хранилище в ~/.gestalt, переменные окружения GESTALT_* и старая запись MCP gestalt — всё это по-прежнему обнаруживается и учитывается.

Лицензия

Исходный код доступен под FSL-1.1-ALv2 (см. LICENSE.md). Бесплатно для использования и модификации. Вы не можете продавать его или запускать как конкурирующий сервис. Каждая версия становится Apache-2.0 через два года после её выпуска.