Por qué Claude Code lo olvida todo en tu otra máquina y cómo solucionarlo (2026)

La memoria automática es un directorio, y el directorio es local

La memoria automática está activada por defecto y hace un trabajo real: Claude escribe sus propias notas a medida que avanza (comandos de compilación, ideas de depuración, convenciones que descubre) en un directorio por proyecto, con un índice MEMORY.md que se carga al inicio de cada conversación y archivos de temas que se leen bajo demanda.

Todo eso vive bajo tu directorio de inicio en un ordenador. La documentación es explícita al indicar que todos los worktrees y subdirectorios de un repositorio comparten un único directorio de memoria, y que los archivos no se comparten entre máquinas o entornos en la nube. Por lo tanto, "Claude aprendió nuestro comando de compilación" es una afirmación verdadera solo para un portátil.

Cada máquina mantiene su propia versión y se desvían

Debido a que cada máquina aprende por separado, no solo difieren en volumen, sino que no coinciden. Tu portátil aprendió el comando de compilación antes de que arreglaras el Dockerfile; tu ordenador de escritorio lo aprendió después. Ninguno sabe que el otro existe, por lo que no hay conflicto que notar ni paso de reconciliación.

Ten en cuenta lo que esto le hace a la confianza. No puedes saber a partir de una sesión si un dato faltante nunca se aprendió o si se aprendió en otro lugar. Ambos casos se ven idénticos desde dentro de la conversación.

Los worktrees lo comparten; las máquinas no

Hay un límite que funciona a tu favor, y conocerlo aclara el otro límite. La documentación indica que todos los worktrees y subdirectorios de un repositorio comparten un único directorio de memoria. Así que si mantienes tres worktrees para tres ramas, comparten una sola memoria, y algo aprendido mientras trabajabas en una rama de características estará disponible en la rama principal (main).

Ese es el diseño correcto y muestra cuál es realmente la unidad: el repositorio en este sistema de archivos. Cruza ese sistema de archivos y estarás en una memoria diferente, razón por la cual el mismo repositorio en un segundo ordenador comienza vacío mientras que cinco worktrees en el primero no lo hacen.

Una sesión web o en la nube es otra máquina

Esta es la parte que sorprende a quienes pensaban que lo habían solucionado. Las sesiones de Claude Code pueden ejecutarse en lugares que no son tu terminal: los clientes web y móviles, Remote Control y, desde la versión v2.1.224, claude self-hosted-runner, que convierte tus propias máquinas o contenedores en lugares donde se ejecutan esas sesiones.

Cada uno de ellos es un sistema de archivos independiente en lo que respecta a la memoria. La frase en la documentación es "máquinas o entornos en la nube", y un runner self-hosted en un contenedor es exactamente eso: no es tu portátil, por lo tanto, no es la memoria de tu portátil.

También es una carpeta que el mantenimiento puede tocar

Los archivos locales vienen con ciclos de vida de archivos locales. La retención del directorio ~/.claude se rige por la misma configuración cleanupPeriodDays que limpia los historiales de las sesiones, por lo que el directorio de memoria vive dentro de un régimen de limpieza normal en lugar de fuera de él.

And puede verse afectado por errores, lo cual vale la pena afirmar con precisión en lugar de dramatismo. El registro de cambios para la versión v2.1.228, lanzada el 11 de agosto de 2026, incluye: "Se solucionó el problema por el cual la limpieza de sesiones eliminaba el contenido dentro de la carpeta de memoria de un proyecto". Una versión lo solucionó. Pero la lección estructural se mantiene por sí sola: un directorio generado administrado por la propia lógica de limpieza de una herramienta es una caché, no un registro, y debe tratarse de esa manera incluso cuando no haya errores en él.

La mensajería entre sesiones tampoco transfiere el conocimiento

Las sesiones de Claude Code ahora pueden enviarse mensajes entre sí, incluso a través de tus máquinas, lo que parece que debería solucionar esto. No lo hace, por diseño. Un mensaje es texto, no historial ni archivos. La mensajería entre máquinas es solo de respuesta (la sesión de otra máquina puede responderte, no ser contactada en frío) y el descubrimiento depende de archivos locales y sockets, por lo que un contenedor y su host no pueden verse en absoluto.

Ese es un canal de coordinación que funciona según lo previsto. Mueve una frase, no una memoria.

Hacer commit de `CLAUDE.md`. Correcto, y todos deberían hacerlo. El archivo del proyecto está bajo control de versiones, por lo que viaja con el repositorio a cada máquina y a cada compañero de equipo. Su límite es que es el archivo que tú mantienes: contiene tus reglas permanentes, no las cien cosas que Claude descubrió mientras trabajaba.

Ejecutar `/init` nuevamente en la nueva máquina. Te da un CLAUDE.md inicial desde el repositorio, lo cual es genuinamente útil y también es solo una nueva derivación de lo que ya es visible en el código. No puede recuperar el conocimiento sobre la prueba inestable, porque eso nunca estuvo en el repositorio.

Sincronizar `~/.claude` con Dropbox o un repositorio de dotfiles. El intento más popular y con el que hay que tener cuidado. Estarías sincronizando un estado generado junto con datos de sesión y credenciales, en una ruta que la herramienta asume que posee exclusivamente, con la posibilidad de que dos máquinas escriban a la vez. Algunos profesionales lo hacen; no es una configuración documentada, y que "la carpeta de memoria de mi agente haya sido escrita a medias por otro host" es una mala tarde. Si lo intentas, sincroniza de manera muy específica y nunca mientras las sesiones estén activas.

Pedirle al agente que vuelva a aprender. Funciona, cuesta una sesión de exploración y produce un conjunto de notas ligeramente diferente al que tiene la otra máquina. Estás pagando tokens para reconstruir algo que ya posees.

Usar Remote Control para que solo haya una sesión. Una estrategia real: mantén el trabajo en un host y conéctate desde otro lugar. Realmente evita la desviación y significa que tu conocimiento ahora reside en un solo lugar en un portátil que se puede perder, borrar o limpiar.

Cada una de estas opciones gestiona una caché local. Ninguna de ellas hace que el conocimiento exista independientemente de una máquina.

Divide lo que hay en esa carpeta según quién lo necesite, porque las dos mitades tienen hogares diferentes.

El estado específico de la máquina debe seguir siendo específico de la máquina. Rutas locales, qué contenedor se está ejecutando, las peculiaridades de tu propio entorno. Deja que la memoria automática lo conserve y que sea desechable.

Todo lo que una segunda máquina o una segunda persona necesitaría debería vivir fuera de cualquier máquina. El comando de compilación que realmente funciona. La razón por la que un directorio está fuera de los límites. La decisión y su fecha. La prueba inestable y por qué es inestable. Nada de eso tiene que ver con tu portátil; tiene que ver con el proyecto.

Dos movimientos hacen que esto sea real. Primero, usa los ámbitos que ya están bajo control de versiones: CLAUDE.md confirmado en la raíz del repositorio, .claude/rules/ para reglas con ámbito de ruta y, si usas subagentes, memory: project, que escribe en .claude/agent-memory/<name-of-agent>/ y se puede compartir a través del control de versiones en lugar de estar en tu directorio de inicio. Segundo, coloca el conocimiento que no tiene forma de regla en un almacén que cada máquina pueda leer.

MemoryLake es una capa de memoria para esa segunda parte: decisiones, informes de incidentes y documentos de origen en un solo almacén, accesible a través de MCP desde Claude Code en cualquier máquina, desde Codex y desde ChatGPT a través de la API. El portátil conserva su caché; el conocimiento deja de vivir en él.

Paso 1: Crea una clave de API

Genera una clave y realiza tu primera solicitud en unos 30 segundos. Mantenla en tu entorno o en un gestor de secretos en lugar de pegarla en una sesión, y ten en cuenta que esto también es lo que hace que configurar una nueva máquina tome cinco minutos en lugar de ser un ejercicio de reaprendizaje.

Paso 2: Sube tus primeras memorias

Sube los documentos, imágenes y archivos que tu otra máquina tuvo que redescubrir: el manual de procedimientos, las decisiones de arquitectura, los informes de incidentes, los contratos de API, las notas de "por qué esta prueba es inestable". Sube las fuentes en lugar de un resumen; un resumen es lo que la carpeta de memoria local ya contiene, y es la parte que no viaja bien.

Paso 3: Conecta tu IA y agentes

Dale a Claude, Codex, OpenClaw y otros agentes de IA acceso a la memoria a través de MCP o la API. Configura el servidor MCP una vez por máquina y cada sesión leerá el mismo almacén, ya sea tu portátil, tu ordenador de escritorio, una sesión web o un runner self-hosted en un contenedor. Esa es la propiedad que la memoria local no puede tener.

La primera diferencia es que una nueva máquina es aprovisionamiento, no inducción (onboarding). Clona el repositorio, apunta al almacén y el agente comenzará con lo que el equipo sabe en lugar de con lo que este ordenador en particular resulta que recuerda.

La segunda es que las sesiones en la nube y en contenedores dejan de ser de segunda clase. Una sesión en un runner self-hosted no tiene memoria local que heredar, lo que hoy significa que es el participante menos informado en tu flujo de trabajo. Al leer un almacén compartido, está tan informado como tu portátil, lo cual es sumamente importante precisamente para las ejecuciones automatizadas que tienes menos probabilidades de supervisar.

La tercera es que perder la carpeta deja de importar. Una limpieza de mantenimiento, una máquina borrada, un contenedor reinstalado: todo eso se convierte en un inconveniente en lugar de una pérdida, porque la mitad duradera nunca estuvo allí.

Y se complementa con lo que Claude Code hace de forma nativa. La memoria automática sigue escribiendo notas locales por repositorio, CLAUDE.md sigue llevando tus reglas permanentes a través del control de versiones, y ninguno tiene que convertirse en el sistema de registro, el rol para el que están menos capacitados, y la misma división del trabajo que mantiene coherentes a varios agentes en una sola memoria.

Haz commit de todo lo que se pueda subir al repositorio

CLAUDE.md en la raíz del repositorio, .claude/rules/ para reglas con ámbito y .claude/agent-memory/ para subagentes en el ámbito del proyecto. Cualquier cosa en el control de versiones es automáticamente para múltiples máquinas y se comparte automáticamente con los compañeros de equipo. Reserva CLAUDE.local.md y la memoria de ámbito local para cosas que realmente no deberían salir de tu máquina.

Trata la carpeta de memoria como una caché

Pregúntate qué perderías si ~/.claude/projects/<project>/memory/ desapareciera esta noche. Si la respuesta es algo que extrañarías, ese contenido está en el lugar equivocado: escríbelo en el repositorio o en un almacén compartido. La solución de la versión v2.1.228 es un recordatorio, no la razón.

Mantén MEMORY.md como un índice

Solo las primeras 200 líneas o 25 KB de MEMORY.md se cargan al inicio de la sesión, lo que ocurra primero. Una línea por entrada con detalles en los archivos de temas mantiene el índice dentro de ese límite; un índice sobrecargado se trunca silenciosamente, que es el modo de fallo que nunca notarías.

No sincronices ~/.claude a la ligera

Si decides sincronizarlo, sé muy específico y deliberado: nunca durante sesiones activas, nunca con dos máquinas escribiendo a la vez y nunca asumas que el estado generado es seguro de fusionar. Las rutas compatibles para múltiples máquinas son el control de versiones y un almacén compartido, no la replicación de archivos de un directorio que pertenece a la herramienta.

Dale a las sesiones automatizadas el mismo contexto que a tu terminal

Las sesiones web, Remote Control y los runners self-hosted comienzan sin memoria local. Si esas ejecuciones importan, asegúrate de que el almacén compartido y los archivos confirmados lleven todo lo que necesitan; de lo contrario, la sesión menos supervisada será la que trabaje con el menor contexto.

No esperes que nada de esto sea de cumplimiento obligatorio

La documentación de Claude Code describe los archivos de instrucciones y la memoria automática como contexto en lugar de una configuración obligatoria. Cualquier cosa que deba cumplirse en cada máquina (formateadores, rutas protegidas, no hacer push directo a main) pertenece a los hooks y a la CI, que también se suben al repositorio y, por lo tanto, también funcionan en múltiples máquinas.

Claude Code olvida en tu otra máquina porque su memoria es un directorio local, y la documentación lo dice directamente: los archivos no se comparten entre máquinas o entornos en la nube. Cada host aprende por separado, las sesiones en la nube y en contenedores son hosts adicionales, y la carpeta se encuentra dentro de una limpieza de retención normal, con la entrada del registro de cambios del 11 de agosto que corrige que la limpieza de sesiones elimine el contenido dentro de la carpeta de memoria de un proyecto como un recordatorio de que un directorio generado es una caché.

Así que conserva la caché y deja de depender de ella. Haz commit de lo que se pueda subir al repositorio: CLAUDE.md, .claude/rules/, memoria de agente con ámbito de proyecto. Luego, coloca el conocimiento que no tiene forma de regla (las razones, las decisiones, los detalles operativos ganados con esfuerzo) en un almacén que cada máquina lea. Así, la segunda máquina no es un nuevo comienzo, es solo otra forma de entrar.