Por qué Claude Code olvida tus correcciones y cómo solucionarlo (2026)

La corrección casi nunca se escribe

Una corrección escrita en un chat es contexto conversacional. Da forma al resto de esa sesión y luego la sesión termina. Claude Code inicia la siguiente a partir de tus archivos (CLAUDE.md, el repositorio, lo que sea que le indiques) y tu corrección no estaba en ninguno de ellos.

Este es el caso mayoritario y es algo común. Se siente como olvidar una lección porque lo experimentaste como una enseñanza. Mecánicamente, nunca se guardó nada. Es la misma brecha detrás de que Claude Code inicie cada sesión sin el contexto de tu proyecto — la herramienta es sin estado por diseño, y solo los archivos sirven de puente entre sesiones.

Que esté escrito no es lo mismo que se actúe en consecuencia

Aquí está la parte que cambia el consejo, y está documentada en lugar de ser anecdótica.

El 22 de marzo de 2026, se registró un problema en el repositorio anthropics/claude-code titulado "Claude repeatedly fails to apply its own memory/feedback — same mistakes recur across sessions" (Claude falla repetidamente al aplicar su propia memoria/retroalimentación: los mismos errores se repiten entre sesiones). La descripción del reportero es precisa: "El sistema de memoria de Claude Code almacena correctamente la retroalimentación y las reglas, pero el modelo falla constantemente al aplicarlas. El mismo tipo de errores se repite entre sesiones a pesar de que los archivos de memoria se actualizaron varias veces (más de 5 actualizaciones para el mismo problema)".

Sus ejemplos son del tipo que cualquiera reconoce:

• La memoria dice hacer siempre `cd` a `backend/` antes de ejecutar comandos del backend y hacer siempre `cd` a `frontend/` antes de `vite build`. Los comandos se siguen ejecutando desde el directorio incorrecto, lo que produce fallos de compilación o ejecuciones silenciosas sin efecto.
• La memoria dice recompilar siempre `dist` después de cambios en `App.jsx` y copiar siempre los archivos de `public/` a `dist/`. Los pasos se omiten y se sirve un bundle obsoleto.
• La memoria dice los cambios no confirmados se pierden al sincronizar. Los archivos se siguen copiando de forma ad-hoc a producción sin un commit, y el cambio se revierte silenciosamente en la siguiente sincronización.
• Una solución de una sesión anterior (cambiar marmot.svg por marmot.png) nunca se confirmó, se revirtió y tuvo que solicitarse de nuevo.

El resumen del reportero es la frase que hay que recordar: "El sistema de memoria captura el conocimiento pero no influye de manera confiable en el comportamiento". Lo llamaron un "problema de Alzheimer" en Claude Code CLI con Opus 4.6 y memoria basada en archivos.

Dos cosas para ser claros. El problema fue cerrado como no planificado, por lo que se trata de un reporte de usuario más que de un defecto reconocido. Y demuestra algo inconveniente para la conclusión obvia: en ese caso, agregar más almacenamiento no habría ayudado. La regla estaba guardada. Cinco veces.

Las sesiones largas entierran la regla que estableciste al principio

Hay un tercer mecanismo que parece rebeldía y no lo es. En una sesión larga, una instrucción del principio puede quedar fuera del alcance confiable; los profesionales que escriben sobre esto lo describen con precisión: el modelo no está ignorando lo que dijiste al inicio de la sesión, simplemente ya no puede verlo lo suficientemente bien como para recuperarlo. La corrección que diste hace una hora está técnicamente en la conversación y funcionalmente desaparecida.

Por eso la misma corrección puede mantenerse durante veinte minutos y evaporarse en el minuto noventa, y por eso también es el mecanismo detrás de que los archivos de conocimiento queden fuera del contexto a medida que la sesión se alarga.

Una corrección sin su activador es solo un dato curioso

La mayoría de las correcciones son condicionales: cuando se despliega, antes de ejecutar comandos del backend, si tocaste App.jsx. Escrita en un archivo de instrucciones en constante crecimiento, la condición sobrevive como prosa que el modelo tiene que notar que se aplica. No hay ningún mecanismo que haga surgir el "hacer siempre cd primero" en el momento en que un comando está a punto de ejecutarse.

Así que el fallo no se debe solo a si la regla existe. Es que la regla existe en un lugar que no tiene relación con el momento en que se necesita.

Añadirlo a `CLAUDE.md`. El primer paso correcto, y realmente funciona para convenciones estables e incondicionales. Sus límites son los mencionados anteriormente: el archivo crece, se carga por completo y una línea enterrada en la posición 180 compite con todo lo demás por la atención. El reporte #37314 es cómo se ve el extremo de este enfoque.

Repetir la corrección con más fuerza. MAYÚSCULAS, "IMPORTANTE:", "NUNCA". Ligeramente efectivo, pero no escala: una vez que hay seis reglas gritando, ninguna destaca.

`/clear` después de dos correcciones fallidas. Una técnica real que recomiendan los usuarios experimentados: si una corrección no ha funcionado tras dos intentos, limpia la sesión en lugar de acumular un contexto lleno de fallos. Efectivo y contundente, aunque también pierdes todo lo útil de esa sesión.

`/compact` para mantener la sesión ágil. Ayuda con el mecanismo de sesiones largas al comprimir la conversación para que el modelo pueda continuar. Sin embargo, la compactación tiene pérdidas por definición, por lo que también puede ser lo que elimine tu corrección.

Convertir la corrección en código. Subestimado, y para un tipo específico de corrección es simplemente la respuesta correcta; más sobre esto a continuación.

Un archivo de notas activas desde el que copias y pegas. Funciona porque es externo y duradero, pero tú eres el sistema de recuperación, decidiendo en cada sesión qué correcciones son relevantes y pegándolas.

Primero, clasifica tus correcciones en dos grupos. Este es el paso que marca la diferencia.

Grupo uno: correcciones que se pueden mecanizar. "Hacer siempre cd a backend/ primero". "Recompilar siempre dist después de cambiar App.jsx". "Confirmar (commit) antes de desplegar". Cada ejemplo en ese problema de GitHub está en este grupo, y para estos, la recomendación honesta no es una capa de memoria. Es un script de npm que haga el cd por ti, un target de Makefile que recompile, un gancho de pre-commit, una comprobación de CI que falle en un despliegue no confirmado. Una regla que un agente no puede violar supera a una regla que se supone que debe recordar, y además te protege de tu propio yo del futuro. Si te quedas con una sola cosa de este artículo, que sea esta.

Grupo dos: correcciones que no se pueden mecanizar. "Permitimos ese patrón en la capa del adaptador porque el upstream devuelve 200 en caso de fallo". "El cliente rechazó el enfoque modal en marzo". "No refactorices el importador heredado, se reemplazará en el cuarto trimestre (Q4)". Ningún script impone el criterio. Estas son las que deben escribirse en algún lugar duradero, mantenerse breves y mostrarse cuando sean relevantes; y aquí es donde una capa de memoria externa hace un trabajo real: la corrección vive fuera de cualquier sesión individual, se recupera cuando surge el tema en lugar de cargarse en cada solicitud y se mantiene lo suficientemente corta como para competir realmente por la atención.

MemoryLake está diseñado para el grupo dos: un almacén del que tus agentes leen a través de MCP o la API, que contiene las decisiones y restricciones que produjo tu trabajo en lugar de acumularlas en un archivo de instrucciones que se hace más largo cada semana.

El límite debe establecerse claramente, porque el caso #37314 es exactamente el que lo demuestra: una capa de memoria no garantiza que el modelo cumpla. Que un agente actúe según lo que lee es un comportamiento del modelo, y ningún sistema de almacenamiento controla eso. Lo que cambia es la disponibilidad y la forma: la restricción está presente, actualizada y es breve en el momento en que es relevante, en lugar de faltar por completo o estar enterrada en la línea 180. Eso es una mejora real y no es una garantía. Cualquiera que te diga lo contrario te está vendiendo algo.

Paso 1: Crea una clave de API

Genera una clave y realiza tu primera solicitud en unos 30 segundos. Manténla en tu entorno o en un gestor de secretos en lugar de en un archivo de configuración que podrías confirmar (commit).

Paso 2: Sube tus primeras memorias

Arrastra los documentos, imágenes y archivos que contienen tus correcciones del grupo dos: el documento de decisiones con sus motivos, las notas de arquitectura, los informes de "probamos esto y falló porque". Sube las fuentes en lugar de un resumen ordenado; el motivo detrás de una corrección suele ser la parte que se elimina al resumir, y el motivo es lo que evita que se vuelva a discutir.

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. Claude Code admite servidores MCP, por lo que esto es una entrada de configuración. El mismo almacén es luego legible desde tus otros agentes, lo cual es importante porque las correcciones no dejan de ser ciertas cuando cambias de herramienta.

El cambio más inmediato es que tu CLAUDE.md deja de crecer. Las reglas mecanizables se convierten en scripts y ganchos (hooks); las correcciones basadas en el criterio se trasladan al almacén. Lo que queda es un archivo corto de reglas permanentes a las que el modelo realmente puede prestar atención, lo cual es la solución al problema de la atención, no un parche para el mismo.

Lo segundo es que la quinta repetición se detiene. No porque el modelo se haya vuelto más obediente, sino porque las dos categorías ahora se manejan mediante mecanismos que se adaptan a ellas: los errores en el orden de compilación no pueden ocurrir, y las decisiones basadas en el criterio son recuperables en lugar de tener que ser recordadas.

Lo tercero es que las correcciones sobreviven al límite de la sesión en un formato que puedes auditar. Cuando algo está mal, editas un solo registro en lugar de buscar dónde lo escribiste, y puedes ver si la corrección se llegó a capturar alguna vez, lo que suele ser la respuesta.

And they survive the tool. "Don't refactor the legacy importer" is true in Cursor and Codex too. Kept in CLAUDE.md, it's a Claude Code fact; kept in a shared store, it's a project fact — the same reason añadir una capa de memoria a Claude Code tiende a sobrevivir a cualquier agente que estés usando este trimestre.

Mecaniza todo lo que sea mecanizable

Antes de escribir una corrección, pregúntate si un script, un gancho (hook) o una comprobación de CI podría hacer que fuera imposible equivocarse. Si es así, haz eso en su lugar. Cada ejemplo en el caso reportado anteriormente era mecanizable, y el reportero actualizó la memoria cinco veces en lugar de agregar un script de npm de una sola línea. Esto no es una crítica hacia ellos; es la trampa que tiende todo el flujo de trabajo, porque escribir una regla se siente como el mismo tipo de acción que escribir código.

Escribe el activador, no solo la instrucción

"Usa snake_case para las columnas de la base de datos" es débil. "Al agregar una migración en db/migrations/, usa snake_case para los nombres de las columnas; el mapeo del ORM lo asume" le da al modelo una condición para reconocer y una razón para no dudar. Las correcciones que nombran su activador sobreviven mejor que las correcciones expresadas como meras preferencias.

Mantén corto a propósito el archivo que siempre se carga

Cada línea en CLAUDE.md se carga en cada tarea y compite con todas las demás líneas. Trátalo como un recurso escaso: solo reglas permanentes, limitadas a algo que tú mismo volverías a leer. Todo lo demás pertenece a la recuperación. Un archivo de instrucciones largo no es más minucioso, es menos efectivo, y el problema de atención en sesiones largas empeora esto, no lo mejora.

Detente después de dos correcciones fallidas y cambia de enfoque

Si una corrección no ha funcionado dos veces, la tercera repetición no lo solucionará. O bien mecanízala, muévela a un registro corto recuperable, o limpia la sesión y comienza de nuevo. Repetir una corrección en un contexto que ya está lleno de fallos de esa misma corrección es la opción menos efectiva disponible.

Confirma (commit) la solución antes de continuar

Vale la pena interiorizar el caso de marmot.svg en ese reporte: la corrección se aplicó, pero luego se perdió porque nunca se confirmó (commit). Algunos casos de "se le olvidó" son en realidad "nunca se persistió en ningún lado", y eso incluye a git.

Claude Code olvida tus correcciones por dos razones diferentes y las soluciones no son intercambiables. Por lo general, la corrección nunca se escribió en ningún lugar duradero, por lo que no había nada que recordar. A veces, como documentó un reporte de marzo de 2026 en el repositorio claude-code, con archivos de memoria actualizados cinco o más veces para el mismo problema y el reportero concluyendo que el sistema de memoria "captura el conocimiento pero no influye de manera confiable en el comportamiento", estaba escrita y aun así no se aplicó.

Así que divídelas. Mecaniza lo que un script o un gancho (hook) pueda imponer, porque una regla que no se puede violar supera a una regla que se tiene que recordar. Coloca las correcciones basadas en el criterio en un almacén que las mantenga cortas, actualizadas y recuperables en el momento en que se apliquen, y mantén tu archivo de instrucciones que siempre se carga lo suficientemente pequeño como para que el modelo realmente pueda prestarle atención. Esa combinación maneja ambos modos de fallo. Ninguno de los dos por sí solo lo hace.