FIMemory

Un almacén local que tus herramientas de IA pueden leer, una vez conectadas y avisadas.

FIMemory (FI Memory, de Future Industries) guarda tus notas en tu propio ordenador y conecta tus herramientas de IA a ellas para que dejes de reexplicar el mismo proyecto en cada sesión. El almacén es una carpeta normal con tus propios archivos: sin formato propietario, sin servidor, sin cuenta, sin subir nada a ningún sitio. Los nuevos almacenes están cifrados en reposo por defecto. Tú eliges una frase de contraseña, una frase de recuperación de 24 palabras se imprime una sola vez, y los archivos permanecen privados dondequiera que viajen: un host de git, una copia de seguridad en la nube, un USB. ¿Prefieres archivos que puedas abrir directamente en un editor de texto? El texto plano es una elección explícita en la configuración, y un almacén cifrado se exporta de vuelta a Markdown legible en cualquier momento, protegido únicamente por tu clave.

Empieza aquí

Dos comandos.

npm i -g fimemory
fimemory setup

Si ese primer comando falla con EACCES: permission denied (común en macOS, donde la carpeta global por defecto de npm pertenece a root), dale a npm una carpeta que te pertenezca y reintenta. No se necesita sudo:

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

Luego cierra y vuelve a abrir cualquier herramienta de IA que ya estuviera ejecutándose, porque leen su configuración al iniciarse.

Esa es toda la instalación. setup crea el almacén si no tienes uno, conecta todas las herramientas de IA que encuentra en esta máquina, luego verifica su propio trabajo e imprime qué se instaló y qué no. Ejecutarlo de nuevo es seguro y aburrido: todo lo que ya está en su sitio informa unchanged y no se reescribe nada. Cuando no estés seguro de si funcionó, ejecútalo de nuevo.

Al crear un almacén en una terminal, setup te guía a través del cifrado: eliges una frase de contraseña (o pulsas una tecla para optar por no cifrar con --plaintext), imprime tu frase de recuperación de 24 palabras una vez y te pide que demuestres que la has anotado, luego deja el almacén desbloqueado en esta máquina durante unas 8 horas. En un script o en CI no hay aviso: pasa --passphrase "...", establece GESTALT_PASSPHRASE, o di --plaintext. Sin ninguna de esas opciones, se niega limpiamente en lugar de adivinar. Pierde tanto la frase de contraseña como la frase de 24 palabras y los datos desaparecen, por diseño; eso es lo que cuesta "tu clave, no nuestros servidores", y la ejecución guiada no permitirá que ocurra en silencio.

Un paso que setup no puede completar por ti es Claude Code, que gestiona su propio archivo de configuración. setup comprueba si el comando claude existe en esta máquina: si existe, imprime una única línea claude mcp add para que la pegues. Si no existe (la extensión de VSCode y la aplicación de escritorio no instalan una línea de comandos), imprime el bloque JSON exacto y el archivo donde ponerlo en su lugar. En cualquier caso, aparece en "Próximos pasos" en lugar de pasar de largo.

Si un paso falla, la ejecución continúa y el fallo recibe su propia línea. Corrige esa línea, ejecuta fimemory setup de nuevo, y los pasos que ya funcionaron permanecen en su sitio.

Tres comandos que querrás más adelante:

• fimemory onboard es el primer paso guiado DESPUÉS de setup: te guía para aprobar tu primera edición sugerida, hace tres preguntas sobre cómo trabajas y escribe las respuestas en el almacén, luego muestra una búsqueda que responde con tus propios hechos. Un almacén conectado que no contiene nada sobre ti parece roto incluso cuando no lo está; esta es la forma más corta de superar eso.

• fimemory doctor lee toda la configuración y te dice en palabras claras qué falta y qué hacer al respecto. Una instalación a medias es la forma más común de que esto salga mal.

• fimemory setup --plaintext hace la misma instalación con un almacén SIN CIFRAR: cada archivo legible en un editor de texto, por ti y por cualquier persona o programa con acceso a la carpeta. Es una elección real, declarada claramente, no una degradación oculta. Un almacén que comenzó en texto plano puede adoptar cifrado más tarde con fimemory encrypt (más barato antes de que se acumule contenido real).

Antes, una instalación funcional y una muerta parecían idénticas. Ahora la instalación te dice cuál tienes.

Related MCP server: Munin Memory

Expectativas honestas

• Instalado y usado por una persona en Windows, macOS y Linux. No es una afirmación de un runner: son instalaciones manuales en máquinas reales que luego hicieron trabajo real, con dos herramientas de IA diferentes leyendo y escribiendo un almacén compartido diariamente durante meses. La máquina Windows y la Mac ejecutan Claude Code y Grok contra él; la máquina Linux lo ejecuta sin interfaz gráfica. CI además compila, verifica tipos, ejecuta pruebas e instala globalmente el paquete empaquetado en runners de Linux y macOS en cada push. Lo que eso aún no cubre es la larga cola de aplicaciones host: un runner no tiene sesión de escritorio, así que para cualquier cliente que no sea los mencionados a continuación, no hemos visto que la configuración que setup escribió realmente se cargue. En Linux, los comandos de portapapeles necesitan xclip, o wl-clipboard en Wayland, y ninguno está instalado por defecto. Ejecuta fimemory doctor si algo parece mal, y por favor repórtalo.

• No es más barato que no recordar. Es correcto por un pequeño sobreprecio, y mucho más barato que pegar todo.

• Los agentes lo leen cuando están conectados y se les dice. setup escribe la configuración de MCP, el texto de reglas y el hook de recuperación por ti, pero ningún producto de memoria puede obligar a un host a consultarlo sin que se le pida en cada turno.

• La sincronización automática no está incluida. El trabajo con varias máquinas funciona a través de tu propio remoto de git, bajo tu propia cuenta. Aún no existe un servicio de Sync, así que nada de lo que escribas sale de tu máquina a menos que configures un remoto tú mismo.

• El alcance incluido son tus máquinas, varios agentes. Apunta dos máquinas a un remoto de git privado: fimemory join <url> en la segunda máquina, luego fimemory pull antes y después de las sesiones. Las ediciones a la misma nota nunca se fusionan en silencio; el lado perdedor se convierte en una propuesta pendiente para que la revises. Las funciones de equipo más allá de tu propio remoto no están incluidas.

Lo que setup realmente ejecuta

Cinco pasos, en este orden:

1. init, solo cuando no hay un almacén en ~/.fimemory (un ~/.gestalt existente de una instalación anterior se detecta y se conserva). Se omite, nunca se sobrescribe, cuando ya hay uno.

2. install-mcp, que escribe la entrada del servidor MCP en cada archivo de configuración del host que encuentra. Esto es lo que le da a un asistente la capacidad de leer el almacén.

3. install-hooks, que escribe el hook de recuperación de Claude Code en ~/.claude/settings.json. Se omite cuando ~/.claude no existe.

4. install-rules, que escribe el bloque de reglas de memoria en el archivo de reglas de cada host. Esto es lo que hace que un asistente realmente use el almacén.

5. doctor, que lee todo de nuevo y lo informa.

Los hooks se ejecutan antes que las reglas a propósito. El texto de reglas shim le dice al modelo que las notas relevantes pueden ya estar en el turno, inyectadas por el hook de recuperación. Esa frase solo es cierta una vez que el hook está instalado, así que el hook va primero y su resultado elige la redacción: hook instalado significa que Claude Code recibe la redacción shim, hook omitido significa que cada host recibe la redacción de búsqueda primero, que es verdadera incondicionalmente. Escribir la redacción shim sin el hook le diría al modelo que deje de buscar a cambio de una inyección que nunca llega, lo cual es peor que no hacer nada.

Cada paso está envuelto para que un fallo se convierta en la línea de ese paso y la ejecución continúe. Un archivo de reglas que no puedas escribir nunca debe costarte el registro de MCP, y ninguno de los dos puede costarte el veredicto de doctor que dice cuál de ellos se instaló. setup también se ejecuta en un almacén cifrado y bloqueado, que es el caso normal en una segunda máquina, y permite que doctor informe del bloqueo.

Los verbos individuales aún existen y funcionan por sí solos: init, install-mcp, install-hooks, install-rules, doctor.

Qué herramienta recibe qué

* Documentado por el proveedor, no verificado en disco. Windsurf, Cursor y Claude Desktop no están instalados en ninguna máquina que hayamos comprobado, así que nunca hemos visto que estas rutas existan. Si uno de ellos ignora el almacén después de que setup diga installed, eso es lo primero que hay que sospechar: comprueba en la configuración de la propia aplicación dónde guarda realmente las reglas, y vuelve a ejecutar fimemory install-rules --file <path>. Cada otra fila de la tabla se ha visto en disco.

• Claude Code es el único host para el que install-mcp no escribe. La CLI de Claude Code es dueña del esquema de ~/.claude.json, así que imprimimos claude mcp add fimemory -s user -- ... en su lugar. Su bloque de reglas y su hook se escriben por ti.

• Cursor: no escribimos ningún archivo de reglas de Cursor. Dónde guarda Cursor las reglas a nivel de usuario, y si carga ~/.cursor/rules, está sin verificar. Cursor no está instalado en ninguna máquina que hayamos comprobado y no hay documentación de Cursor en este disco. Una versión anterior de esta página afirmaba esos límites como hechos; nunca se habían leído de una fuente, que es el mismo error que el de ~/.grok/GROK.md más abajo, así que han desaparecido. La evidencia de terceros apunta en la otra dirección: el propio 12-project-rules.md de Grok lista ~/.cursor/rules/ como un directorio de reglas que escanea. Si conoces el archivo que lee Cursor, install-rules --file <path> escribe el mismo bloque allí.

• Claude Desktop: no escribimos ningún archivo de reglas de Claude Desktop. Si tiene un archivo de reglas en disco en absoluto está sin verificar. No está instalado en ninguna máquina que hayamos comprobado. Su configuración de MCP se escribe.

• Gemini CLI te permite renombrar su archivo de contexto con contextFileName en ~/.gemini/settings.json. install-rules lo lee y lo respeta, así que el bloque cae en el archivo que Gemini realmente lee.

• Cualquier otra cosa, incluidos hosts de los que nunca hemos oído hablar: install-mcp imprime un fragmento JSON genérico para pegar en la configuración de ese cliente.

Verificado de extremo a extremo por una persona: Claude Code y Grok, en Windows 11 y macOS. Esas son las combinaciones que se han instalado y usado para trabajo real, a diario, contra un almacén compartido. Cada otro host en la tabla recibe su configuración y reglas escritas; una matriz honesta por host se envía tal como se mide, no antes.

Si un host vive en un lugar inusual: install-rules, install-mcp y doctor siguen CODEX_HOME, GEMINI_CLI_HOME y GROK_HOME cuando están establecidas, así que los tres coinciden sobre dónde vive un host. La ruta de configuración de Claude Desktop depende de tu plataforma (y de APPDATA en Windows). Las rutas restantes, las de Cursor y Windsurf, son fijas.

El hook, con precisión

install-hooks escribe exactamente un archivo: el ~/.claude/settings.json de Claude Code. Esa es una declaración sobre este software. No es una afirmación de que otras herramientas carezcan de hooks, y la versión de esta frase que hacía esa afirmación se comprobó el 2026-07-31 y era falsa.

Grok CLI, verificado de primera mano contra grok 0.2.117 en disco, 2026-07-31. Grok escanea ~/.claude/settings.json en busca de hooks por defecto ([compat.claude] hooks = true, documentado en ~/.grok/docs/user-guide/05-configuration.md, y la tabla Hook Locations de 10-hooks.md enumera ese archivo como una fuente global de confianza total). Sí carga nuestros dos manejadores. No puede suministrar una inyección, por dos razones independientes:

1. Grok descarta el stdout del hook. Esta es la que importa, porque no se puede evitar. Lo medimos: cuatro formas de salida (hookSpecificOutput de Claude, un additionalContext de nivel superior, texto plano y systemMessage), cada una confirmada como disparada de verdad por un archivo marcador que escribió, y cada una sin producir contexto inyectado, junto a un control positivo que demostró que el entorno de pruebas podía exponer contexto inyectado. Se midió en modo -p headless; la TUI interactiva no se midió. La documentación propia de Grok no lo resuelve. 10-hooks.md dice que solo PreToolUse y los eventos stop pueden decidir, y que «cualquier otro evento es pasivo», y su sección Passive Hooks dice que stdout se ignora «para eventos como SessionStart o PostToolUse», citando ejemplos en lugar de UserPromptSubmit; por eso la autoridad aquí es el experimento, no la documentación.

2. Su formato de manejador no tiene campo args. La tabla Key Fields de 10-hooks.md enumera type, command, url, timeout y env, y toda nuestra invocación vive en args. Grok lanza el intérprete sin argumentos y ese proceso muere de inmediato. Este sí parece reparable, porque command acepta un comando de shell en línea, pero arreglarlo solo hace que el hook se ejecute; no inyectaría nada igualmente, porque la razón es (1).

No se bloquea nada en ningún caso: Grok falla abierto. Pero «fallar abierto» no es «ser silencioso». 10-hooks.md dice que cada fallo de hook queda registrado en el scrollback de la interfaz, así que verás una línea de fallo de hook en cada prompt de Grok. Si quieres que desaparezca, pon [compat.claude] hooks = false en ~/.grok/config.toml. No borres los manejadores de ~/.claude/settings.json. Ese es el archivo que Claude Code usa de verdad, y al quitarlos ahí apagas el único host donde el hook funciona.

Grok también lee ~/.claude/CLAUDE.md. Un archivo de reglas no es privado del host en cuyo directorio está. El 12-project-rules.md de Grok dice que, con la compatibilidad de Claude activada (la opción por defecto), escanea tu ~/.claude/ de nivel de usuario en busca de CLAUDE.md entre otros, y grok inspect --json en una máquina real enumer ý ese archivo exacto. Así, en una máquina con Claude Code y Grok, el texto del shim escrito «para Claude Code» llegaba también a Grok. Ya no es así: cuando un host detectado que no puede ejecutar el hook comparte un archivo de reglas, ese archivo recibe la redacción de búsqueda primero, sea quien sea quien nominalmente lo posea. fimemory doctor informa de qué contenido lleva cada archivo de reglas, no solo de que hay un bloque.

Codex CLI tiene hooks. Leído en su binario incluido, @openai/codex 0.145.0, 2026-08-01: el conjunto de eventos incluye user_prompt_submit, session_start, pre_tool_use y stop; el binario contiene rutas de código de hooks/src/events/ y un cargador de hooks/hooks.json. No escribimos ninguna configuración de hooks para Codex, así que nuestro hook no se ejecuta ahí. Si nuestro manejador funcionaría bajo Codex, es decir, su esquema de manejador y si se inyecta el stdout de un hook user_prompt_submit, está sin verificar, y no se hace ninguna afirmación en ninguno de los dos sentidos.

Gemini CLI tiene hooks e incluye una importación de primera parte del mismo archivo que nosotros escribimos. Leído en @google/gemini-cli 0.52.0, 2026-08-01: UserPromptSubmit se asigna al evento BeforeAgent de Gemini, y gemini hooks migrate lee <cwd>/.claude/settings.json e importa sus hooks. Un aviso si usas ese comando: su importador copia solo command, type y timeout, y descarta args, exactamente como Grok. Si lo ejecutas en un directorio cuyo .claude/settings.json contenga nuestros manejadores, obtienes un proceso de Node que falla en todos los prompts. No escribimos configuración de hooks para Gemini, así que esto solo ocurre si ejecutas tú la migración.

Windsurf y Claude Desktop: si tienen soporte de hooks en absoluto está sin verificar. Ninguno de los dos está instalado en ninguna máquina que hayamos comprobado. No escribimos configuración de hooks para ninguno de ellos, y no afirmamos ninguna limitación más allá de eso.

Cursor: los documentos de Grok registran un archivo de hooks de Cursor (~/.cursor/hooks.json). No lo escribimos y no hemos probado nuestro manejador con él.

fimemory install-rules --list-hosts imprime todo esto para tu máquina: qué hosts se detectan, dónde guarda cada uno su archivo de reglas, y la razón del hook por host con su fuente.

Por qué el bloque de reglas es la parte que importa

install-mcp da a tu asistente la capacidad de leer el almacén. install-rules --mode shim es lo que hace que lea el almacén sin que se lo pidan, inyectando las notas relevantes antes de tu prompt. En nuestras propias mediciones, eso cuesta una fracción de lo que cuesta dejar que el asistente busque en el almacén con llamadas a herramientas. Sin switch, las herramientas están presentes y, en su mayoría, inactivas.

El texto del shim se escribe solo dentro de un archivo que leen exclusivamente los hosts donde el hook de recuperación se ejecuta de verdad, lo que hoy significa Claude Code en una máquina sin Grok CLI. Todos los demás archivos reciben en su lugar la redacción de búsqueda primero, la que dice a esos asistentes que llamen a fimemory_search ellos mismos, porque para ellos no se inyecta nada. Si instalas Grok CLI, ~/.claude/CLAUDE.md vuelve a la redacción de búsqueda primero en la siguiente ejecución de setup, porque Grok también lee ese archivo. Grok failure lines silenciosas.

Cuando algo parece mal

fimemory doctor comprueba el modo del almacén, las fuentes de la clave, el trabajo MCP en cada configuración de host, los bloques de reglas, el hook de recuperación, el índice del catálogo y cuándo se hizo la última lectura del almacén. Nombra lo que falta y qué hacer al respecto, y sale con código distinto de cero cuando una característica realmente falla. Un almacén cuyo índice falta o no incluye notas que se encuentran en el disco es un fallo, no una advertencia: la búsqueda trabaja con el índice, así que un índice ciego significa que un asistente encuentra nada en silencio.

Cifrado en reposo (the default)

Los almacenes nuevos se sellan con XChaCha20-Poly1305 detrás de una passphrase Argon2id, y una frase de 24 palabras de recuperación se imprime función vez al crearlos (mnesio --encrypt lleva un almacén anterior o --plaintext al mismo estado). Si pierdes la passphrase y esa frase, los datos se pierden; es la elección de diseño. No hay cuenta ni restablecimiento, nada más el motivo por el que esa frase importa.

Las herramientas abren el almacén con GESTALT_PASSPHRASE. Fíjala lo que tu propio shell la quiera:

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

Un único desbloqueo mantiene los comandos en modo rápido durante unas 8 horas (sessionKeyCacheTtlHours, 0 lo desactiva). fimemory lock lo termina anticipadamente.

La realidad del día 2, para que no te lleves sorpresas: cuando la ventana expira y no hay passphrase en el entorno, la línea de comandos pregunta ese de nuevo; las herramientas MCP responden a cada llamada con un error claro «store is locked» y explican la solución (poner GESTALT_PASSPHRASE en el lugar donde se ejecuten, o fimemory unlock en cualquier terminal; un servidor en ejecución vea en desbloquear en la próxima llamada, no need para reiniciar), y el hook de recuperación de cada prompt permanece silendo como no bloquear tu prompt. fimemory doctor lo expresa en voz alta en ese estado exacto. Las aplicaciones de escritorio (Claude y los demás) leen el entorno de usuario del sistema operativo, no el perfil de tus shell, así que coloca la variable donde la sesión de escritorio pueda verla.

Honestidad respecto al límite: en el momento en que se desbloquea tu almacén, un cliente MCP conectado tiene acceso de lectura equivalente a una tool de sistema de archivos. Eso es cierto en todos los MCP de memoria; lo presentamos claro.

Desinstalación

Un comando por capa, y cada uno toca solo el lugar que su instalador escribió:

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

No hay un único verbo de desarme todavía, así que uninstall-mcp imprime los otros dos comandos y tła lógica totalmente de una marcha atrás se ve en una sola pantalla.

uninstall-mcp es el mismo escaneo que install-mcp con una mediante de sustitución vacía: los mismos hosts, los mismos anin two leave no se modifican; solo el mismo que la eliminación depende del directorio de configuración de un host. Elimina nuestra entrada y nada más. Una parte del código de configuración que no puede analizar se rechaza y se deja idéntica byte a byte en lugar de si, y ese rechazo es un código de salida 1; es una sola fimemory uninstall-mcp && rm -rf ~/.fimemory se detiene en vez de seguir. Un host no son nada cambiado se convierte tiene un éxito y termina con 0.

Claude Code es simétrico con la instalación: imprimimos claude mcp remove fimemory -s user y leemos ~/.claude.json de solo lectura, solo para decirte si hay un elemento registrado ahí.

Ordenar la passphrase, antes de borrar algo

Si en algún momento ejecutaste install-mcp --env-passthrough GESTALT_PASSPHRASE, la frase de tu almacén cifrado se está metiendo en esos archivos de configuración de los hosts en texto plano. Quitar nuestra entrada la elimina con la propia entrada, para algunos personas ese archivo de configuración es la única copia que existe. El orden importa en las dos direcciones:

• Conservar el almacén: asegúrate antes de puedes abrir separado aún, con una passphrase que recuerdas o con tu frase de recuperación de 24 palabras, ANTES de quitar cualquier cosa. Puedes empezar ffimemory uninstall-mcp --dry-run primero. Nombra las variables de entorno que se quitarían, nunca sus valores, y no escribe nada en absoluto.

• Descartar el almacén: quita primero la configuración y después la carpeta del almacén. Ese es el orden único adecuado, y así no queda la passphrase en un archivo de configuración.

• El binario de Claude Code propio indica que claude mcp remove elimina definitivamente la configuración del servidor, incluidos las variables de entorno y cab escabezera. El comando impreso se lleva estos valores con él.

El almacén en sí es tu carpeta, por lo que dada su de sí tiene que borrarlo, es:borrar un archivo de carpetas./.fimemory(o/.gestalten una instalación arentes del cambio de nombre), o cualquier donde hayas posicionado--home`. Exporta primero si quieres conservar las notas.

Tus archivos, tu salida

fimemory export --plaintext <dir> escribe cada nota, log y edición sugerida como Markdown plano fuera del almacén. La vía de la salida es real, y funciona desde el primer día.

Nota sobre el nombre

Todo lo que se ve al usuario es fimemory: el comando, la clave del servidor MCP y los ID de herramienta (fimemory_search, fimemory_get, ...). Las instalaciones previas al cambio de nombre siguen de priedras: un almacén en ~/.gestalt, las variables de entorno GESTALT_* y una entrada MCP gestalt antigua siguen siendo detectadas y respetadas.

Licencia

Código fuente disponible bajo FSL-1.1-ALv2 (ver LICENSE.md). La uso y la modificación son medios libres. No puedes venderlo ni ejecutarlo como un servicio para competir. Cada versión se convierte en Apache-2.0 dos años después de su lanzamiento.