OpenAI Codex supero los 3 millones de usuarios activos semanales el 8 de abril de 2026, con un crecimiento del 70% mes a mes y un crecimiento de 5x desde enero. El producto tiene memoria ahora, después de la actualización del 16 de abril. Pero la memoria con la que llega es de alcance de proyecto, solo en la nube y bloqueada dentro de OpenAI. Tres enfoques realmente resuelven el problema de dar a Codex memoria que sobreviva a las sesiones, te siga entre maquinas y se conecte a la misma memoria que usan tus otras herramientas de IA: memoria integrada con archivos de proyecto, un servidor MCP de memoria, o una configuración híbrida que mantiene la memoria de OpenAI para código sensible y un servidor MCP para todo lo demás. La ruta MCP toma unos 30 segundos para configurar y funciona con Claude, ChatGPT, Cursor y otros siete clientes en el mismo almacén de memoria.
Cuando los números de uso de Codex alcanzan los 3 millones de usuarios semanales, lo que estas viendo es OpenAI enviando la historia de productividad que Anthropic envio hace 18 meses, a una escala que Anthropic nunca alcanzo. Codex Web, Codex Desktop en macOS y Windows, la app Codex dentro de ChatGPT iOS, el CLI Codex, la extension VS Code. Cinco superficies, una cuenta, el mismo modelo detrás de todas. Para el 16 de abril OpenAI añadió memoria persistente a la app Desktop, junto con Computer Use, un navegador integrado, generación de imágenes y un mercado de mas de 90 plugins. Si Codex es nuevo para ti: nuestra guía de ChatGPT Codex explica el acceso, las superficies y la configuración.
Si lees el anuncio, la "memoria persistente" suena resuelta. No lo esta. Hay tres problemas diferentes escondidos detrás de esa etiqueta, y la memoria integrada de Codex solo resuelve uno de ellos. Aquí esta lo que realmente esta pasando, y tres caminos prácticos a traves de ello.
Que significa "memoria de Codex" hoy#
La memoria de Codex de OpenAI, lanzada el 16 de abril, es de alcance de proyecto. Puedes fijar instrucciones, convenciones de código y preferencias personales dentro de un solo proyecto Codex. La memoria persiste entre sesiones de Codex para ese proyecto. Si cambias de proyecto, empiezas de cero. Si cambias de Codex a ChatGPT, empiezas de cero otra vez. Si cambias de Codex Web a Codex Desktop, se supone que la memoria sigue pero en la practica los usuarios siguen reportando deriva entre superficies.
Este es el mismo modelo que ChatGPT usa para su función de memoria de consumidor. Es bueno para lo que hace. No es lo que la mayoría de desarrolladores quieren decir cuando preguntan si Codex se acuerda de ellos.
Lo que los desarrolladores realmente quieren tiene tres capas:
La primera es la memoria de sesión. Dentro de una sola conversación, puede el modelo recordar lo que hizo hace tres turnos? Esto era un problema en 2023. Esta resuelto.
La segunda es la memoria de proyecto. A traves de multiples sesiones en la misma tarea, recuerda el modelo las convenciones de la base de código, las personas en el equipo, las decisiones que tomaste la semana pasada? La memoria integrada de Codex resuelve esto para proyectos que viven enteramente dentro de Codex. No lo resuelve si la mitad de tu trabajo esta en Claude Code o Cursor.
La tercera es la memoria de operador. A traves de cada herramienta de IA que usas, puede el modelo recordar quien eres, que construyes, que les importa a tus clientes, que errores no quieres repetir? Esta es la capa que nadie en los proveedores de modelos quiere resolver, porque su incentivo es bloquearte a su stack.
Las tres soluciones a continuación abordan las capas dos y tres. Usa lo que encaje.
Solución 1: Memorias integradas de Codex con archivos de proyecto#
Codex tiene dos formas de recordar. La función Memorias almacena preferencias especificas del usuario. Los archivos de configuración a nivel de proyecto almacenan contexto compartido por el equipo. Juntos, para código que vive enteramente dentro de Codex, esto es suficiente.
La configuración es directa. Dentro de cualquier proyecto Codex, crea un archivo AGENTS.md en la raíz del repositorio. Codex lo lee en cada tarea. Esto es el equivalente al patron CLAUDE.md que Anthropic estableció. Entradas comunes: stack tecnológico, convenciones de código, comandos de despliegue, reglas de PR, reglas de nomenclatura, advertencias de "nunca hacer X".
# AGENTS.md
## Stack
Next.js 15, TypeScript estricto, Prisma, Postgres en puerto 5433.
## Convenciones
- Server Actions sobre rutas API cuando sea posible
- Tailwind utility-first, sin modulos CSS
- Tests via Vitest para unitarios, Playwright para e2e
## Nunca
- `prisma db push --force-reset` en ninguna rama
- Saltar el hook read-before-edit
- Empujar a main sin `pnpm typecheck`
Para preferencias personales que cruzan proyectos, usa el panel de Memorias dentro de Configuración de Codex. Fija cosas como "prefiero respuestas concisas con código primero, explicación después" o "siempre cita los números de linea cuando hagas referencia a código".
El limite de este enfoque es lo que describí antes. Funciona dentro de Codex. No te sigue a Claude o Cursor. Si vives enteramente en Codex, eso esta bien. Si no, sigue leyendo.
Solución 2: Un servidor MCP de memoria conectado a Codex#
Esta es la ruta en la que estoy. Toma 30 segundos para configurar y le da a Codex acceso a la misma memoria que Claude Code, Claude Desktop, Cursor, Codex CLI y otros siete clientes MCP leen y escriben.
Codex soporta servidores MCP de forma nativa desde la actualización de finales de marzo. La configuración vive en ~/.codex/config.toml. Anade un bloque como este:
[mcp_servers.memory]
url = "https://memory.studiomeyer.io/mcp"
type = "http"
Eso es todo. Sin token bearer. Sin clave API en tu config. Reinicia Codex, ejecuta cualquier herramienta que toque la memoria, y tu navegador abre una pagina de inicio de sesión Magic Link. Introduce tu email, haz clic en el enlace en el correo que llega, y el flujo OAuth termina silenciosamente. Codex ahora tiene acceso permanente al mismo almacén de memoria que cada otro cliente tuyo usa.
Los números que importan: de "abrir archivo de configuración" a "Codex consulta memoria" fueron 30 segundos en nuestra prueba. El token de actualización OAuth se almacena en el almacén seguro de credenciales de Codex. Ningún token vive jamas en un repo git. La misma memoria es accesible desde Claude Desktop, Claude Code, Cursor, el CLI Codex y Goose con el mismo inicio de sesión de un clic.
Lo que puedes pedir a Codex una vez que la memoria esta conectada:
- "Busca en mi memoria decisiones pasadas sobre autenticación."
- "Que decidí sobre el rate limiter el mes pasado?"
- "Recuerda que prefiero enviar commits pequeños."
- "Que clientes onboardee en abril?"
El modelo ahora lee y escribe hechos a un backend que sobrevive a traves de superficies. Si cambias de opinion sobre el rate limiter en Claude Code el martes, Codex ve la nueva decision el miércoles.
La parte que vale la pena marcar: hay una clase conocida de bugs en Codex Desktop ahora mismo donde multiples chats engendran pilas completas de procesos MCP por hilo (los issues de GitHub 11324, 14548, 18333, 20980 todos rastrean variantes). La memoria crece linealmente con los chats abiertos. Si ejecutas mas de 10 pestañas de Codex a la vez, veras el problema. La solución alternativa es usar servidores MCP de transporte HTTP (como el ejemplo arriba) en lugar de servidores stdio. Los servidores HTTP se ejecutan una vez en la red, no una vez por pestaña.
Solución 3: La configuración híbrida que la mayoría de equipos deberían ejecutar#
Si construyes con Codex en código de cliente que tiene requisitos de cumplimiento y también usas Codex para proyectos personales, probablemente quieres ambos. Memoria integrada para el proyecto del cliente que necesita permanecer bloqueado dentro del entorno de OpenAI. Memoria MCP para todo lo demás.
La forma de cablear esto: usa el panel de Memorias de Codex para preferencias personales cross-proyecto. Usa archivos AGENTS.md para convenciones de proyecto. Usa un servidor MCP de memoria para la memoria de nivel operador que te sigue a traves de herramientas. Las tres capas no entran en conflicto. Cubren diferentes alcances.
Concretamente, en nuestra configuración de equipo, la memoria MCP contiene aprendizajes de sesiones anteriores, decisiones sobre arquitectura, perfiles de clientes, patrones de despliegue y advertencias "nunca hagas esto otra vez". Los archivos AGENTS.md contienen el stack y reglas especificas del proyecto. El panel de Memorias contiene las preferencias personales de comunicación. Cuando Codex inicia una tarea, tiene acceso a las tres.
Limitaciones honestas#
Si vas por la ruta de la memoria MCP, tres cosas que deberías saber.
Primero, el backend de memoria importa. Operamos el nuestro en memory.studiomeyer.io porque lo construimos. Hay alternativas: Mem0, Letta, Zep, MemNexus. Cada uno tiene opiniones diferentes sobre que almacenar, como recuperar, y como facturar. Prueba al menos dos antes de comprometerte.
Segundo, la calidad de la recuperación no es gratis. Un mal backend de memoria da a Codex contexto obsoleto o irrelevante que puede degradar la calidad de la salida. Busca backends que soporten búsqueda semántica (recuperación vectorial) mas texto completo mas grafo de conocimiento. La recuperación de modalidad única es demasiado frágil.
Tercero, la función de memoria de OpenAI envía rápido. Para diciembre de 2026 esperamos que la memoria integrada de Codex sea mucho mas cercana en capacidad a lo que ofrece un backend MCP. Si estas apostando por una configuración a largo plazo, la pregunta es menos "cual es mejor ahora mismo" y mas "cual es portable cuando el panorama cambie de nuevo." La memoria basada en MCP es portable a traves de proveedores. La memoria de OpenAI no lo es.
Que significa esto para los constructores#
Los 3 millones de usuarios semanales de Codex se dividen en dos grupos. Un grupo esta contento con la memoria integrada y nunca piensa en MCP. El otro grupo es el que se dio cuenta de que su flujo de trabajo de IA no se ejecuta dentro de los muros de un proveedor. Usan Claude para algunas cosas, Codex para otras, Cursor para código, ChatGPT para investigación. Para ese segundo grupo, la memoria MCP es la pieza estructural que hace coherente el flujo de trabajo multi-herramienta en lugar de fragmentado.
Si estas en el primer grupo, estas bien. La función Memorias es solida para lo que cubre.
Si estas en el segundo grupo, la configuración de 30 segundos arriba es el movimiento que se acumula para el resto de 2026. La memoria es la capa donde vive el contexto. Una vez cableada, cada herramienta de IA que anades después comienza con el contexto ya presente, no desde cero.
Pruebalo#
Si quieres probar la ruta de memoria MCP con nuestro backend, el inicio de sesión OAuth esta abierto en memory.studiomeyer.io. El nivel gratuito es de 200 operaciones de memoria por mes, suficiente para evaluar. Lanza el bloque de configuración arriba en ~/.codex/config.toml, reinicia Codex, inicia sesión una vez, y estas cableado.
Si quieres un backend diferente, el mismo patron de configuración de Codex funciona con cualquier servidor de memoria conforme a MCP. El protocolo es abierto. El bloqueo no esta en la capa de memoria. Esta en la capa de modelo arriba. Elige tu backend de memoria por portabilidad, no por que fabricante de modelos promete memoria a continuación.
