Sistema de memoria (Memories y Chronicle): hacer que Codex te recuerde entre sesiones

📚 Navegación de la serie: El artículo anterior [18 · Configuración detallada en config.toml] detalló todos los interruptores de comportamiento: modelos, sandboxing y aprobaciones en un solo archivo. Este artículo abordará un tema más profundo: cómo permitir que Codex te recuerde entre sesiones. No nos limitamos a las reglas que escribes en AGENTS.md, sino también al cuaderno de notas privado que el modelo genera al trabajar: si lo corriges una vez, lo registrará en segundo plano para recordarlo automáticamente en el futuro. Además, explicaremos Chronicle, la herramienta experimental exclusiva de Codex que alimenta la memoria con el contenido de la pantalla.

Comencemos con un fragmento de una conversación real que tuve con un compañero.

Compañero: "Tu Codex tiene la memoria activada, ¿verdad? Le acabo de pedir 'usa siempre pnpm para este proyecto' y aun así ejecutó npm install de inmediato".

Yo: "¿Esperabas que lo recordara nada más decírselo?"

Compañero: "Claro, la interfaz no arrojó ningún error".

Yo: "La memoria no se escribe en tiempo real; requiere esperar a que la sesión esté inactiva un tiempo para resumir los datos en segundo plano. Si lo evalúas justo después de decírselo, no lo habrá registrado aún. Además, las reglas estrictas de 'aplicar siempre' deben escribirse en AGENTS.md y no depender de la memoria".

Esta conversación ilustra los dos malentendidos más comunes de los principiantes respecto a la memoria de Codex: pensar que la memoria se aplica al instante tras decírselo, y creer que la memoria puede sustituir a AGENTS.md. Ambos son erróneos y causan problemas en momentos críticos. En este artículo explicaremos el funcionamiento del sistema de memoria de Codex: cuándo registra, dónde almacena, cómo gestionarlo y qué tareas no deben delegarse en él.

Al terminar este artículo, obtendrás:

• Las dos vertientes de la "memoria" en Codex: la que escribes tú (AGENTS.md) frente a la que genera el sistema por su cuenta (Memories), detalladas en una tabla comparativa.
• Si Memories está activo por defecto, qué regiones tienen restringido su uso, cómo activarlo, en qué directorio se guarda y por qué no se actualiza en tiempo real.
• Cómo controlar sesión a sesión con /memories si usar la memoria existente o permitir la generación de nuevas, junto con los interruptores útiles en config.toml.
• Una lista de pautas sobre qué guardar y qué no, y una línea roja que nunca debes cruzar.
• Chronicle: la capacidad experimental exclusiva de Codex que alimenta la memoria con la pantalla: qué hace, sus restricciones de uso (solo con ChatGPT Pro y macOS, no disponible en la UE, Reino Unido y Suiza) y las tres advertencias de privacidad oficiales.
• Un proceso paso a paso para activarlo y verificar el correcto funcionamiento de la memoria.

ℹ️ Compáralo con el mecanismo de memoria de Claude Code: allí la "memoria automática" viene activa por defecto, organizada por directorios de Git y cargando las primeras 200 líneas o 25 KB de MEMORY.md; el sistema de Codex difiere: está desactivado por defecto, cuenta con restricciones geográficas, se genera en segundo plano de forma asíncrona y utiliza otras rutas y controles. Detallaremos estas diferencias a continuación.

---

01 Distinguir primero: existen dos sistemas de memoria independientes

Definamos el concepto de entrada: Codex utiliza dos sistemas de memoria independientes para almacenar información: la que escribes tú (AGENTS.md) y la que genera el modelo por su cuenta (Memories). Muchos piensan solo en Memories al hablar de recordar cosas, pero eso es solo la mitad y, por lo general, la opción menos predecible.

Analogía: La pizarra de tácticas frente al cuaderno de notas del observador en un equipo. El entrenador detalla en la pizarra cómo colocarse, a quién marcar o cómo ejecutar los saques de esquina antes del partido, y todo el equipo debe seguir las tácticas; esto es AGENTS.md: instrucciones tuyas, por escrito, que se leen en cada sesión. La otra parte es el bloc de notas del observador en la grada: "la defensa izquierda del rival es débil", "el delantero suele recortar hacia el centro"; son anotaciones que nadie le pide registrar, sino que recopila por su cuenta para consultarlas la próxima vez que se enfrenten; esto es Memories. Ambas herramientas son útiles: una es "las instrucciones que le ordenas seguir" y la otra es "los patrones que el modelo detecta por sí mismo".

La documentación oficial detalla la funciones de ambos sistemas, resumidos en esta tabla comparativa; esta es la tabla más importante a recordar en esta sección:

Dimensión	AGENTS.md	Memories (Memoria)
Autor	Tú (escrito manualmente)	Codex (generado por su cuenta)
Contenido	Instrucciones y reglas a aplicar obligatoriamente	Contexto consolidado aprendido de sesiones pasadas
Casos típicos	Comandos de compilación o pruebas, convenciones, áreas restringidas	Tu pila tecnológica, convenciones, flujos repetidos o fallos depurados
Comportamiento por defecto	Activo (se lee al guardarse en el repositorio)	Desactivado por defecto, requiere habilitación manual
Fiabilidad	Determinista: se lee en cada sesión	Probabilista: generado de forma asíncrona, no se garantiza su carga
Control de versiones	Se añade a Git para compartirse en equipo	Excluido de Git, guardado localmente en tu máquina

Guarda las reglas del equipo que deban aplicarse siempre en AGENTS.md o en documentos del repositorio. Trata la memoria como una capa útil de contexto local y no como la única fuente de reglas que deban ejecutarse de forma permanente.

En lenguaje sencillo: Memories añade comodidad pero no es un seguro de vida. El incidente del pnpm que conté al inicio es el caso típico: si confías una regla estricta de "usar solo pnpm" a Memories, tarde o temprano fallará (podría no haberse generado aún, no cargarse en el contexto o descartarse al unificar); el método correcto es guardarla en AGENTS.md, que es un flujo determinista obligatorio en cada sesión. El artículo 11 · Manual de instrucciones AGENTS.md desglosó su estructura, y este artículo se enfocará en el cuaderno de notas que el modelo escribe por su cuenta.

Observa cómo ambos flujos de memoria se unifican en el "contexto de la nueva sesión":

A la izquierda figura la ruta obligatoria y determinista de AGENTS.md guardada en el repositorio; a la derecha está Memories (desactivada por defecto), generada asíncronamente en segundo plano dentro de ~/.codex/memories/; abajo a trazos se ilustra Chronicle, que alimenta opcionalmente a Memories con el contenido de la pantalla (sección 05). Ambos flujos confluyen en el "contexto de la nueva sesión" para que recuerde tus hábitos al iniciar.

💡 Resumen en una frase: Codex gestiona dos sistemas de memoria: AGENTS.md (manual, determinista, obligatorio y compartido en Git) y Memories (automático, probabilista, desactivado por defecto y local en tu máquina); las reglas estrictas deben guardarse en AGENTS.md en lugar de confiar en Memories.

---

02 Memories: el cuaderno de notas automático, cómo activarlo, dónde se guarda y su ciclo de vida

Detallemos ahora Memories (Memoria), el cuaderno de notas que Codex escribe para sí mismo al trabajar. Su utilidad es inmediata: evita tener que repetir en cada sesión "uso TypeScript, no añado punto y coma al final y las pruebas se ejecutan así". Al activarse, permite transferir a las siguientes sesiones tus preferencias estables, convenciones, pila tecnológica y fallos depurados.

Analogía: El entendimiento implícito con un compañero de confianza. A un becario nuevo debes enseñarle todo constantemente; a un compañero de tres años le basta con una mirada, ya que recuerda tus hábitos de trabajo. Memories es el recurso para llevar a Codex de becario nuevo a compañero de confianza: tú trabajas y corriges con normalidad, y el sistema compila la información en segundo plano para consolidar la afinidad en tus próximas sesiones.

Activarlo primero (desactivado por defecto)

Esta es una de las diferencias principales entre Codex y Claude Code:

Memories está desactivado por defecto y no está disponible en el Espacio Económico Europeo (EEE), el Reino Unido y Suiza en su lanzamiento. Habilítalo en los ajustes de la aplicación o añadiendo memories = true en la tabla [features] de ~/.codex/config.toml.

Elige uno de los dos métodos de activación:

Método 1: Desde el archivo de configuración (añadido en ~/.codex/config.toml de forma permanente):

[features]
memories = true

Método 2: Desde los ajustes de la app de Codex (mediante la interfaz visual).

⚠️ Las restricciones de región están configuradas en el propio sistema por geolocalización y no por red: si te encuentras en el EEE, Reino Unido o Suiza, no podrás usar la función incluso utilizando una VPN. OpenAI aplica el mismo límite geográfico para Chronicle.

Cómo se escribe: asíncrono y en segundo plano, no en tiempo real

Esta es la solución a la confusión del inicio y el comportamiento más contraintuitivo de la memoria de Codex. La documentación oficial detalla tres mecanismos:

1. Filtra las sesiones de origen útiles, no las registra todas. Al activarse, Codex consolida en archivos de memoria las sesiones pasadas de utilidad, omitiendo las sesiones activas en ejecución o demasiado breves para evitar compilar información a medias.

2. Se actualiza en segundo plano y requiere inactividad. La documentación oficial detalla: la memoria no se escribe al finalizar la sesión, sino que Codex espera a que la sesión esté inactiva un tiempo suficiente para confirmar que has terminado antes de compilarla. De ahí que la prueba de mi compañero fallara: la sesión seguía activa y no se había iniciado el guardado.

3. Se cancela si el saldo o cuota son reducidos. Si el porcentaje restante de tu límite de peticiones (rate-limit) en Codex está por debajo del umbral de configuración, se cancelará la generación de memoria para priorizar tus peticiones activas.

Diseño de seguridad adicional: al compilar la memoria, Codex aplica de forma automática una máscara de desofuscación (redact) sobre claves detectadas. Sin embargo, esto es un filtro de prevención por si acaso y no una autorización para almacenar credenciales (ver sección de la línea roja).

Dónde se guarda

La documentación oficial especifica una ruta fija local en tu máquina:

Esta es la estructura del directorio (los nombres de archivos específicos los genera el sistema):

~/.codex/memories/
├── (摘要文件)
├── (持久条目文件)
├── (近期输入文件)
└── (过往会话佐证文件)

Puntos clave:

Se guarda en tu carpeta personal de Codex. Por defecto en ~/.codex o en la ruta alternativa definida en la variable de entorno CODEX_HOME. Los archivos principales se compilan en ~/.codex/memories/, incluyendo resúmenes, registros de persistencia y fragmentos de sesiones.

Trátalos como "estado generado". La recomendación oficial insiste: estos archivos son el resultado del estado de Codex; puedes revisarlos para auditar problemas o antes de compartir tu carpeta general, pero evita modificarlos manualmente como método principal de gestión; usa los comandos /memories y los interruptores explicados a continuación. Esto difiere de Claude Code, que promueve editar los archivos directamente; en Codex tú regulas las reglas y dejas al sistema gestionar los archivos.

Compara las diferencias principales en esta tabla:

	AGENTS.md	Memories
Estado por defecto	Activo siempre	Desactivado por defecto, requiere activación manual
Momento de guardado	Al guardar el archivo	En segundo plano tras inactividad de la sesión
Ubicación	En el repositorio (Git)	En ~/.codex/memories/ (local y excluido de Git)
Control y gestión	Edición directa del archivo	Mediante comandos /memories y variables de config, evitando la edición manual

💡 Resumen en una frase: Memories es el bloc de notas local que Codex genera por su cuenta: desactivado por defecto (usa memories = true o actívalo en los ajustes) y guardado en ~/.codex/memories/; no se actualiza al instante, sino de forma asíncrona tras inactividad de la sesión y cancelándose si la cuota es reducida; se aplica desofuscación a claves pero evita guardarlas; gestiona el comportamiento con variables y comandos en lugar de editar los archivos manualmente.

---

03 El comando /memories y sus variables: cómo gestionar el comportamiento de lectura y escritura

Una vez habilitado Memories, surge la duda: ¿quiero que esta sesión consuma la memoria existente y permita compilar nuevos registros? Por ejemplo, si estás depurando un código de prueba temporal, no te interesará que lo aprenda; o si gestionas tareas sensibles, preferirás no heredar contextos pasados. Codex ofrece dos niveles de control: el comando /memories a nivel de sesión y las variables globales.

Analogía: Los botones de reproducir y grabar en una grabadora. "Reproducir" define si usar grabaciones pasadas (consumir memoria existente) y "Grabar" define si registrar la conversación actual (generar nuevos registros). Son controles independientes: puedes reproducir sin grabar (usar la memoria pero no aprender de esta sesión), grabar sin reproducir o apagar ambos. El comando /memories es la consola de esta grabadora.

A nivel de sesión: /memories

Escribe /memories en la app de Codex o en la CLI; afectará únicamente a la sesión activa:

/memories

Se despliega el selector para decidir: si usar la memoria existente en esta sesión, si permitir que compile nuevos registros en el futuro o desactivar la memoria por completo para esta conversación. La documentación oficial aclara: el ajuste a nivel de sesión no altera tu configuración global, aplicando solo al chat actual. Al abrir una nueva sesión volverán a usarse tus valores globales.

Este diseño es muy práctico. Mi hábito de trabajo: dejarlo registrar con normalidad en tareas de desarrollo convencionales y, ante tareas temporales, experimentales o de seguridad, usar /memories para desactivar el registro al iniciar, evitando que compile datos temporales o sensibles en el historial permanente.

A nivel global: variables en config.toml

Para reglas permanentes a nivel global, añádelas bajo el bloque [memories] en ~/.codex/config.toml:

Variable	Función	Valor por defecto
memories.use_memories	Asignar false evita cargar la memoria existente en las nuevas conversaciones	true
memories.generate_memories	Asignar false evita compilar registros de las nuevas conversaciones en la memoria	true
memories.disable_on_external_context	Asignar true evita compilar registros si la sesión consumió contextos externos (MCP, web search o herramientas)	false
memories.min_rate_limit_remaining_percent	Detiene el guardado de memoria si la cuota de peticiones restante cae por debajo de este porcentaje	25
memories.extract_model	Permite especificar un modelo alternativo para la extracción de memoria por sesión	Omitido (usa modelo por defecto)
memories.consolidation_model	Permite especificar un modelo alternativo para la unificación general de memoria	Omitido (usa modelo por defecto)

Un ejemplo habitual: permitir que Codex consuma la memoria acumulada pero impedir que aprenda nuevos registros (cuando consideres que la memoria es óptima y no quieres que acumule datos redundantes):

[memories]
generate_memories = false
use_memories = true

ℹ️ La variable memories.disable_on_external_context conserva el alias antiguo memories.no_memories_if_mcp_or_web_search por compatibilidad. En el artículo [20 · Habilitar herramientas externas con MCP] detallaremos el uso de MCP; los contextos que interactúan con herramientas externas pueden no estar limpios, por lo que es una medida segura excluirlos de la memoria.

💡 Resumen en una frase: Controla a nivel de sesión con /memories si usar o generar memoria (sin alterar el valor global); a nivel global ajusta bajo el bloque [memories] en config.toml: use_memories y generate_memories como interruptores principales, disable_on_external_context para excluir sesiones con herramientas externas y min_rate_limit_remaining_percent con 25 por defecto.

---

04 Qué guardar y qué no: pautas de uso y la línea roja absoluta

Explicados los mecanismos, definamos qué conviene delegar a Memories y qué evitar. Por defecto, Memories actúa con prudencia (buscando contextos estables y omitiendo sesiones efímeras), pero debes conocer sus límites, especialmente en cuanto a la línea roja.

Comparemos los casos de uso en esta tabla:

❌ Evita delegarlo aquí (debe ir en AGENTS.md / temporal / sensible)	✅ Escenario ideal (estable / reutilizable / aprendizaje autónomo)
"Usar siempre pnpm, prohibido npm" (debe cumplirse siempre → usar AGENTS.md)	Tu pila tecnológica habitual (TypeScript + PostgreSQL + pytest)
"Usar puerto 8081 para esta sesión" (temporal, será redundante después)	Flujos repetidos (ejecutar lint por costumbre antes de abrir PR)
"Estoy depurando la vista de acceso" (estado de la sesión activa)	Convenciones del proyecto (este repo requiere levantar un servicio local para pruebas)
Contraseñas, API keys o tokens (¡Sensible! ¡Línea roja!)	Errores depurados (aquel bug intermitente se debió a no asignar zona horaria)

Tres reglas de decisión:

1. ¿Debe aplicarse en cada sesión? Esta es la pauta de oro en Codex. Si una regla debe cumplirse de forma estricta en cada inicio, escríbela en AGENTS.md y no dependas de Memories. Memories es probabilista: podría no haberse guardado aún, no cargarse en el contexto o descartarse al unificar. El incidente de mi compañero con pnpm ocurrió por confiar una directriz obligatoria a una herramienta probabilista.

2. ¿Es variable o reutilizable? Datos puntuales que cambiarán en breve (puertos, variables efímeras, estados activos) no aportan valor; flujos que reutilizarás en el futuro (pila de desarrollo, convenciones del repositorio, fallos resueltos) son su fuerte.

3. ¿Contiene datos sensibles? Esta es la línea roja absoluta:

No almacenes credenciales en la memoria. Codex aplicará desofuscación sobre claves detectadas, pero aun así debes auditar los archivos de memoria antes de compartir tu directorio personal o exportar registros.

Analiza la implicación de esta advertencia: que aplique desofuscación no te autoriza a guardar credenciales. La memoria se almacena en archivos Markdown de texto plano sin cifrado locales; el filtro es una medida de prevención secundaria. Por tanto, nunca permitas contraseñas, tokens o API keys en la memoria, cumpliendo con la regla de seguridad general: si no debe estar en el código, confirmaciones ni registros, tampoco debe estar en la memoria. Como hábito específico en Codex: antes de compartir tu directorio ~/.codex o exportar datos de memoria, revisa la carpeta memories/ para confirmar que no contenga información privada.

💡 Resumen en una frase: Tres pautas de filtrado: si es obligatorio escríbelo en AGENTS.md; si es temporal u efímero no lo registres; nunca guardes credenciales en la memoria (se almacena en plano); y audita memories/ antes de compartir ~/.codex. El valor de Memories está en el contexto reutilizable y estable.

---

05 Chronicle: alimentar la memoria con la pantalla (experimental)

Esta sección describe una capacidad exclusiva de Codex frente a Claude Code: Chronicle. Claude Code no ofrece ninguna alternativa similar.

⚠️ Experimental, sujeto a cambios. Chronicle es una funcionalidad del tipo "vista previa de investigación que requiere activación expresa (opt-in research preview)"; cualquier referencia a menús, comportamientos por defecto o accesos se rige por tu interfaz y la documentación oficial de Codex.

Qué es y qué hace

En pocas palabras: mientras que Memories aprende del chat con Codex, Chronicle avanza y aprende del "contenido de tu pantalla". Incorpora capturas y contextos de la pantalla recientes para alimentar la memoria, permitiendo al modelo saber a qué te refieres, qué fuentes consultar o qué herramientas de consola usar.

Analogía: Un asistente que puede mirar tu monitor. Un asistente convencional solo sabe lo que le explicas por chat; el asistente de Chronicle además puede echar un vistazo a la pantalla: "veo que estás examinando esta alerta de error", "acabas de editar código en esta PR", evitando tener que explicárselo de cero. Tres ventajas principales señaladas oficialmente: asociar lo que estás mirando (evita cambiar de ventana para documentarlo), completar contextos omitidos (ahorra redactar antecedente largos) y aprender herramientas y flujos (aprende por su cuenta qué utilidades emplear sin explicárselo).

Un detalle clave: Chronicle no necesariamente procesa todo el contenido de la pantalla, sino que lo usa como "pista". La documentación aclara: si existe una fuente de datos adecuada (un archivo específico, un mensaje en Slack, un documento de Google o una PR), Chronicle usará el contexto visual para localizar el recurso original e interactuar directamente con él.

Restricciones estrictas: región y plataforma

Detallemos primero las limitaciones de acceso, que definen si puedes habilitarlo o no:

Chronicle está disponible únicamente para suscriptores de ChatGPT Pro en macOS, y no es compatible en la UE, el Reino Unido y Suiza en su lanzamiento.

Tres requisitos indispensables:

• Suscripción: requiere el plan ChatGPT Pro (no compatible con Plus convencional).
• Plataforma: únicamente en macOS (sin soporte para Windows o Linux; la aplicación de escritorio de Codex carece de versión para Linux, como detallamos en el artículo 07).
• Regiones: no compatible en la UE, Reino Unido y Suiza (coincidiendo con las restricciones de Memories).

Además, requiere dos permisos del sistema en macOS: Grabación de pantalla (Screen Recording) y Accesibilidad (Accessibility); el primero para ver la pantalla y el segundo para interactuar. Ruta de activación: Ajustes de la app de Codex → Personalization → confirma que Memories esté activo → activa Chronicle abajo → pulsa Continue tras leer las condiciones → otorga ambos permisos del sistema.

Tres advertencias de privacidad

Esta es la sección crítica. La documentación oficial lo advierte al inicio: comprende los riesgos antes de activarlo. Revisa estas tres advertencias detalladamente:

1. Consume cuota rápidamente. Chronicle ejecuta agentes de sandbox en segundo plano para procesar capturas y generar memoria; estos agentes consumen la cuota de peticiones a gran velocidad. Activar la opción reducirá tu saldo restante más rápido que el uso convencional.
2. Incrementa el riesgo de inyección de prompts (prompt injection). El uso de Chronicle aumenta la exposición a ataques de inyección de prompts basados en lo que se muestra en pantalla: por ejemplo, si visualizas un sitio web con instrucciones maliciosas ocultas dirigidas a agentes, Codex podría seguiros. Coincide con las brechas de seguridad del artículo 16, pero con mayor superficie al analizar contenido en pantalla que tú no controlas.
3. Almacenamiento local sin cifrado. Los registros compilados por Chronicle se guardan como archivos Markdown de texto plano sin cifrado locales, al igual que Memories.

Compara estas tres advertencias con la comodidad que aporta. Mi recomendación coincide con la del artículo 02: puedes probarlo, pero pausa el servicio de inmediato si en la pantalla se muestra información sensible (contraseñas, mensajes privados, datos de clientes o reuniones). Para pausarlo, usa el icono de Codex en la barra de menús y selecciona Pause Chronicle (para restablecer usa Resume Chronicle). La documentación oficial insiste: pausa el servicio antes de reuniones o al acceder a recursos privados; y establece la regla estricta: no uses Chronicle para registrar reuniones o conversaciones sin el consentimiento de los participantes (no graba audio, pero las capturas registrarán los elementos visuales).

Gestión de datos y privacidad en OpenAI

Detalles clave sobre el flujo de datos:

• Las capturas son temporales: se conservan localmente en tu sistema por poco tiempo bajo la ruta $TMPDIR/chronicle/screen_recording/, eliminándose de forma automática tras 6 horas.
• La memoria generada se guarda localmente: bajo la ruta $CODEX_HOME/memories_extensions/chronicle/ (típicamente ~/.codex/memories_extensions/chronicle/) en archivos Markdown editables. Para borrar un registro, elimina el archivo correspondiente o edita el Markdown para borrar el fragmento de interés; la documentación oficial advierte: no agregues información manual aquí.
• Procesamiento de capturas: para compilar la memoria, Chronicle inicia una sesión temporal de Codex para analizar fotogramas, texto extraído por OCR, marcas de tiempo y rutas de archivos locales relacionados. Las capturas se eliminan de los servidores de OpenAI inmediatamente después del procesamiento: no se conservan (salvo requisitos legales) y nunca se usan para entrenamiento.

💡 Resumen en una frase: Chronicle es la función experimental de Codex para alimentar la memoria con la pantalla, disponible solo en macOS con ChatGPT Pro (excluyendo la UE, Reino Unido y Suiza) y requiriendo permisos de grabación y accesibilidad; considera sus riesgos (cuota, inyecciones, guardado en plano); usa Pause Chronicle antes de acceder a datos privados; las capturas se limpian a las 6 horas, la memoria se guarda localmente y el procesamiento en el servidor es temporal sin entrenamiento.

Compara ambos sistemas en la siguiente imagen:

Este diagrama ilustra los dos sistemas: a la izquierda, Memories aprende del chat con Codex, se almacena en ~/.codex/memories/ y está desactivado por defecto (se activa con memories = true); a la derecha, Chronicle aprende de la pantalla, se guarda en ~/.codex/memories_extensions/chronicle/ y es una opción experimental exclusiva de macOS con ChatGPT Pro. Ambos alimentan el "contexto de la nueva sesión" para recordar tus preferencias.

---

06 Manos a la obra: activar Memories, guardar un registro y comprobar que funciona

La teoría sin práctica no sirve. Recorreremos la secuencia mínima: activar Memories → dejar que aprenda en una sesión → comprobar la generación de archivos → controlar con /memories. No requiere dependencias.

Diferencias de plataforma: los comandos mkdir y similares se ejecutan directamente en Mac / Linux; en Windows se recomienda usar Git Bash o WSL. La ruta ~ apunta al directorio de usuario (en Windows corresponde a C:\Users\usuario\). Además, si te encuentras en el EEE, Reino Unido o Suiza, no podrás usar la función; no es un fallo del sistema.

Primer paso: Activar Memories

Edita el archivo ~/.codex/config.toml y añade (crea el archivo si no existe):

[features]
memories = true

Resultado esperado: tras guardar el archivo, la función queda activa. También puedes activarla desde los ajustes de la app.

Segundo paso: Crear un directorio de prueba e iniciar Codex

mkdir memory-demo
cd memory-demo
codex

Resultado esperado: accedes a la sesión de Codex.

Tercer paso: Añadir una preferencia estable en la sesión

Indica al modelo una preferencia estable durante la conversación. Por ejemplo:

这个项目以后统一用 pytest 跑测试,提交前先跑一遍。记住这个习惯。

Resultado esperado: Codex responde con normalidad y registra la preferencia. Sin embargo, ten en cuenta: no se escribirá de inmediato en el archivo. Como explicamos en la sección 02, la memoria se compila asíncronamente; Codex requiere esperar a que la sesión esté inactiva un tiempo suficiente (por defecto 6 horas) para confirmar que has terminado. Evita buscar el registro en el archivo de inmediato; comprueba este comportamiento para asimilar el incidente de la introducción.

Cuarto paso: Controlar el comportamiento de la sesión con /memories

Para una verificación inmediata, realizaremos el control a nivel de sesión. Escribe en el chat:

/memories

Resultado esperado: se abre el selector para elegir: si usar la memoria existente, permitir generar nuevos registros o desactivar la memoria. Elige una opción (por ejemplo, desactivar la generación de nuevos registros). Esta opción aplica solo a la sesión activa sin alterar los valores globales, siendo un cambio inmediato que puedes validar en el acto sin esperas.

Quinto paso: Comprobar la generación de los archivos de memoria

Debido a la naturaleza asíncrona, realiza esta comprobación pasado un tiempo (una vez enfriada la sesión). Revisa el directorio de almacenamiento:

ls ~/.codex/memories/

Resultado esperado: se listan los archivos compilados por Codex (resúmenes, persistencia, etc.). Visualizar los archivos = Memories está compilando tu contexto. Abre los archivos Markdown (texto plano) si deseas auditar el contenido, pero recuerda la directiva oficial: trátalos como estado generado y evita modificarlos manualmente; gestiona su comportamiento con /memories o en config.toml.

⚠️ Si el directorio ~/.codex/memories/ sigue vacío tras esperar, realiza las siguientes comprobaciones: 1) que memories = true esté definido bajo [features]; 2) que no te encuentres en el EEE, Reino Unido o Suiza; 3) que la sesión no haya sido descartada por ser efímera; y 4) que la cuota de peticiones restante esté por encima del umbral (25% por defecto). Auditar estas cuatro causas ayuda a diagnosticar el fallo.

Al completar este flujo, habrás comprobado por ti mismo el ciclo: "activar memoria → inyectar preferencia → comprender que es asíncrono → controlar con /memories → verificar los archivos locales".

💡 Resumen en una frase: Habilita memories = true en config.toml → inyecta una preferencia (que no se guardará al instante por ser asíncrona) → usa /memories para controlar la sesión activa → comprueba los archivos en ~/.codex/memories/ pasado un tiempo; si no existen, realiza las cuatro comprobaciones básicas.

---

07 Resumen

En este artículo hemos desglosado el funcionamiento de la memoria en Codex: consta de dos sistemas independientes y difiere notablemente de Claude Code.

Repasemos las pautas consolidadas:

Aspecto	Conclusión
Tipos de memoria	Dos sistemas: AGENTS.md (manual y determinista) + Memories (automático y probabilista)
Memories por defecto	Desactivado por defecto (activación con memories = true); sin soporte en el EEE/Reino Unido/Suiza
Momento de guardado	Asíncrono en segundo plano, compila tras inactividad; cancela ante cuota baja y aplica desofuscación
Ubicación	Directorio ~/.codex/memories/ (local y excluido de Git), guardado como estado generado
Controles de gestión	Comando /memories para la sesión y bloque [memories] en config.toml
Qué guardar y qué no	Las reglas estrictas deben ir en AGENTS.md; evita guardar datos variables o temporales; prohibido guardar credenciales
Chronicle	Habilidad experimental con la pantalla; solo con ChatGPT Pro en macOS, sin soporte en el EEE/Reino Unido/Suiza; advertencias sobre cuota, inyecciones y almacenamiento local en plano

Ahora deberías ser capaz de: distinguir las funciones de AGENTS.md y Memories y por qué las reglas estrictas pertenecen al primero; activar Memories sabiendo por qué es asíncrono y dónde almacena; controlar la lectura y escritura con /memories y variables; decidir qué información guardar evitando almacenar credenciales en plano; y evaluar el alcance y los riesgos de Chronicle. En resumen: puedes asegurar que Codex recuerde lo relevante y bloquear lo indebido sin confiar reglas estrictas a una herramienta probabilista.

El sistema de memoria permite a Codex recordar contextos ocurridos (se alimenta de tus correcciones y del trabajo). Sin embargo, para interactuar con recursos y sistemas que no se ubican localmente en tu máquina, se requiere una herramienta diferente.

💡 Resumen en una frase: Dos rutas de memoria: AGENTS.md para reglas estrictas obligatorias y Memories para contexto complementario, regulando el uso con /memories y config.toml; Chronicle es la función experimental con la pantalla para macOS con plan Pro, revisando sus advertencias antes de activarla.

---

El próximo artículo 20 · Habilitar herramientas externas con MCP: la memoria permite a Codex "comprenderte mejor", y MCP (Model Context Protocol) le permite "alcanzar más recursos": vincula bases de datos, API y servicios de terceros que no están en tu máquina local mediante un protocolo unificado para consultarlos o interactuar con ellos. En esa sección comprenderás por qué la variable disable_on_external_context de la sección 03 previene de inyecciones al interactuar con el exterior. Un pequeño pensamiento: con el fin de "dar información externa a Codex", ¿cuándo conviene pedirle recordar una preferencia y cuándo vincular una herramienta en tiempo real?

---

Lecturas recomendadas

• Escritura de prompts (Prompt): cómo expresarte para que Codex te comprenda
• Práctica real integral: añadir una función a una herramienta TODO desde cero y realizar un commit
• Introducción a la CLI de comandos