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, despues de la actualizacion 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 configuracion hibrida que mantiene la memoria de OpenAI para codigo sensible y un servidor MCP para todo lo demas. La ruta MCP toma unos 30 segundos para configurar y funciona con Claude, ChatGPT, Cursor y otros siete clientes en el mismo almacen de memoria.
Cuando los numeros 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 detras de todas. Para el 16 de abril OpenAI anadio memoria persistente a la app Desktop, junto con Computer Use, un navegador integrado, generacion de imagenes y un mercado de mas de 90 plugins.
Si lees el anuncio, la "memoria persistente" suena resuelta. No lo esta. Hay tres problemas diferentes escondidos detras de esa etiqueta, y la memoria integrada de Codex solo resuelve uno de ellos. Aqui esta lo que realmente esta pasando, y tres caminos practicos 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 codigo 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 funcion de memoria de consumidor. Es bueno para lo que hace. No es lo que la mayoria 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 sesion. Dentro de una sola conversacion, 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 codigo, 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 continuacion abordan las capas dos y tres. Usa lo que encaje.
Solucion 1: Memorias integradas de Codex con archivos de proyecto
Codex tiene dos formas de recordar. La funcion Memorias almacena preferencias especificas del usuario. Los archivos de configuracion a nivel de proyecto almacenan contexto compartido por el equipo. Juntos, para codigo que vive enteramente dentro de Codex, esto es suficiente.
La configuracion es directa. Dentro de cualquier proyecto Codex, crea un archivo AGENTS.md en la raiz del repositorio. Codex lo lee en cada tarea. Esto es el equivalente al patron CLAUDE.md que Anthropic establecio. Entradas comunes: stack tecnologico, convenciones de codigo, 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 Configuracion de Codex. Fija cosas como "prefiero respuestas concisas con codigo primero, explicacion despues" o "siempre cita los numeros de linea cuando hagas referencia a codigo".
El limite de este enfoque es lo que describi antes. Funciona dentro de Codex. No te sigue a Claude o Cursor. Si vives enteramente en Codex, eso esta bien. Si no, sigue leyendo.
Solucion 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 actualizacion de finales de marzo. La configuracion 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 sesion 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 almacen de memoria que cada otro cliente tuyo usa.
Los numeros que importan: de "abrir archivo de configuracion" a "Codex consulta memoria" fueron 30 segundos en nuestra prueba. El token de actualizacion OAuth se almacena en el almacen seguro de credenciales de Codex. Ningun 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 sesion de un clic.
Lo que puedes pedir a Codex una vez que la memoria esta conectada:
- "Busca en mi memoria decisiones pasadas sobre autenticacion."
- "Que decidi sobre el rate limiter el mes pasado?"
- "Recuerda que prefiero enviar commits pequenos."
- "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 miercoles.
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 pestanas de Codex a la vez, veras el problema. La solucion 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 pestana.
Solucion 3: La configuracion hibrida que la mayoria de equipos deberian ejecutar
Si construyes con Codex en codigo de cliente que tiene requisitos de cumplimiento y tambien 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 demas.
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 configuracion 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 comunicacion. Cuando Codex inicia una tarea, tiene acceso a las tres.
Limitaciones honestas
Si vas por la ruta de la memoria MCP, tres cosas que deberias 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 recuperacion 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 busqueda semantica (recuperacion vectorial) mas texto completo mas grafo de conocimiento. La recuperacion de modalidad unica es demasiado fragil.
Tercero, la funcion de memoria de OpenAI envia rapido. 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 configuracion 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 codigo, ChatGPT para investigacion. 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 funcion Memorias es solida para lo que cubre.
Si estas en el segundo grupo, la configuracion 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 despues comienza con el contexto ya presente, no desde cero.
Pruebalo
Si quieres probar la ruta de memoria MCP con nuestro backend, el inicio de sesion 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 configuracion arriba en ~/.codex/config.toml, reinicia Codex, inicia sesion una vez, y estas cableado.
Si quieres un backend diferente, el mismo patron de configuracion 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 continuacion.
