Cómo migrar tus reglas de Cursor a Codex sin perder contexto (2026)

Cursor y Codex leen instrucciones en Markdown. Esa similitud oculta la diferencia que realmente importa.

El contenido de las reglas se transfiere textualmente. El cuerpo Markdown de un archivo .mdc son simplemente instrucciones para un modelo. No es necesario reescribir nada de la prosa.

La activación de las reglas no se transfiere, porque Codex no tiene un modelo de activación. Las reglas de proyecto de Cursor viven en .cursor/rules como archivos .mdc con frontmatter (description, globs, alwaysApply) y cuatro modos construidos encima:

• Always Apply (Aplicar siempre): se aplica a cada sesión de chat
• Apply Intelligently (Aplicar inteligentemente): se aplica cuando el Agent decide que es relevante según la descripción
• Apply to Specific Files (Aplicar a archivos específicos): se aplica cuando un archivo coincide con un patrón especificado
• Apply Manually (Aplicar manualmente): se aplica cuando se menciona con @ en el chat

Codex tiene un único mecanismo: AGENTS.md, resuelto jerárquicamente desde tu directorio de inicio de Codex (~/.codex/AGENTS.md o $CODEX_HOME), pasando por la raíz del repositorio y los directorios intermedios hasta tu directorio de trabajo, combinándose de arriba a abajo y teniendo prioridad los archivos más cercanos. El alcance es una función de dónde se encuentra el archivo, no de un glob o una descripción. No existe un nivel de "el agente decide si esto es relevante".

Ese es todo el problema de la migración en una sola frase. Cuatro modos condicionales tienen que aplanarse en un único mecanismo posicional.

`AGENTS.md` se transfiere directamente, y es posible que ya lo tengas. Cursor admite AGENTS.md en la raíz del proyecto como alternativa a .cursor/rules, incluyendo archivos anidados en subdirectorios. Si tus reglas ya están ahí, la mayor parte de esta migración no requiere ninguna acción, porque esa es exactamente la estructura que Codex espera.

Las User Rules se transfieren como un archivo global. Las User Rules de Cursor son preferencias globales definidas en Customize → Rules que se aplican a todos los proyectos. Su equivalente en Codex es ~/.codex/AGENTS.md. Mismo propósito, diferente ubicación, no se necesita conversión más allá de copiar y pegar.

Los servidores MCP, configuraciones, plugins, comandos de barra diagonal (slash commands) y sesiones recientes se transfieren a través del importador. /import cubre seis áreas: settings.json convertido a config.toml, servidores MCP en ambos dialectos JSON, plugins, hasta 50 sesiones recientes de los últimos 30 días, comandos de barra diagonal personalizados y memorias con alcance de proyecto.

Algunas cosas no se pueden transferir. El historial de chat de la interfaz web de Cursor no se puede importar, solo los datos de sesiones locales. La importación es unidireccional; nada de lo que cambies en Codex se devuelve a Cursor. Y la fidelidad de la memoria no está garantizada: las memorias que hacen referencia a características específicas de la herramienta, como el historial del composer de Cursor, no se mapean en el modelo operativo de Codex, por lo que vale la pena dedicar dos minutos a revisarlas con /memories list después de la importación.

Una cosa que no se transfiere en ninguna dirección: el razonamiento detrás de una regla. La propia documentación de Cursor es tajante sobre por qué existen las reglas: "Los modelos de lenguaje grandes no retienen memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt". Las reglas son la solución temporal, y una solución temporal que solo contiene lo que se te ocurrió escribir.

Paso 1: Inventaría tus reglas según cómo se activan

Antes de ejecutar nada, abre cada archivo .mdc y clasifícalo según su frontmatter, ya que el modo determina el destino.

`alwaysApply: true` → estos van directamente a AGENTS.md en el nivel que coincida con su alcance real. Si una regla es genuinamente global para tu trabajo, pertenece a ~/.codex/AGENTS.md. Si es sobre este repositorio, a la raíz del repositorio. Traducción directa, sin complicaciones.

Reglas con `globs` → estas necesitan ubicación, no traducción. Una regla con alcance para src/api/** se convierte en un AGENTS.md dentro de src/api/, donde Codex la detectará cuando trabajes en ese directorio. Esta es la conversión que realmente vale la pena: si se hace correctamente, mantienes el comportamiento de delimitación de alcance; si se hace con pereza (volcándolo todo en el archivo raíz), habrás hecho que una regla específica de la API se aplique a tu CSS.

Cuando un glob no se mapea limpiamente a un directorio (**/*.test.ts disperso por todo el árbol), tienes dos opciones honestas: declarar la condición en prosa dentro del AGENTS.md más cercano ("Al editar archivos de prueba, ..."), o aceptar que ahora siempre estará cargado. Las condiciones en prosa son más débiles que una coincidencia de glob (el modelo tiene que notar que la condición se aplica), así que úsalas para reglas donde un fallo sea poco costoso.

Reglas que usan Apply Intelligently → estas son en las que más debes pensar. Cursor decidía en tiempo de ejecución si la description hacía que una regla fuera relevante. Codex no lo hará. Cada una pasará a estar siempre activa (consumiendo contexto en cada solicitud) o prácticamente desaparecerá. Clasifícalas: las que importan van al archivo, las que eran secundarias se descartan. No las migres todas al archivo raíz, que es el error por defecto y produce exactamente el archivo de instrucciones sobrecargado del que todo el mundo se arrepiente.

Reglas de Apply Manually → estas eran documentos de referencia que traías deliberadamente. Manténlas como documentos en el repositorio (la carpeta docs/ está bien) y añade una línea en AGENTS.md indicándole al agente que lea el archivo correspondiente para ese tipo de trabajo. No las incluyas en línea.

Ya que estás aquí, aplica el propio consejo de tamaño de Cursor en su nuevo hogar: mantén las reglas por debajo de las 500 líneas y divide las más grandes en piezas combinables. Es una buena guía en Cursor y es una guía aún mejor en Codex, donde todo lo que está en el alcance se carga en cada tarea.

Paso 2: Ejecuta /import y luego corrige lo que no se pudo mapear

Asegúrate de estar en Codex v0.145 o posterior, inicia una nueva sesión de la TUI de Codex en la raíz del proyecto y ejecuta /import. Elige Cursor como origen y selecciona las categorías que desees. Ten en cuenta que /import requiere una sesión local integrada de la TUI; no se ejecutará en una sesión remota o mientras haya una tarea en curso.

Luego realiza la revisión que el importador no puede hacer por ti:

1. Lee el `AGENTS.md` resultante. Cualquier frase redactada en torno a conceptos específicos de Cursor (historial del composer, flujos de trabajo con menciones @, nombres de herramientas propios de Cursor) debe reescribirse o eliminarse. De lo contrario, se quedará ahí indicándole a Codex que use cosas que no existen.
2. Ubica las reglas con alcance de glob en archivos AGENTS.md de subdirectorios según el Paso 1. El importador mueve el contenido; no infiere la estructura de directorios a partir de tu frontmatter.
3. Ejecuta `/memories list` y comprueba qué se ha transferido. Las memorias importadas que hacen referencia a la mecánica de Cursor son, en el mejor de los casos, ruido.
4. Verifica que los servidores MCP realmente se inicien. Ambos dialectos JSON se convierten, pero la configuración convertida sigue siendo configuración: un servidor que necesitaba una variable de entorno en Cursor también la necesitará en Codex.

Luego decide sobre la propia función de memoria de Codex, que es algo independiente de las instrucciones. Las memorias locales de Codex están desactivadas por defecto. Actívalas en la aplicación de escritorio en Settings → Personalization con "Enable memories", o establece memories = true en la sección [features] de ~/.codex/config.toml; en el EEE, el Reino Unido y Suiza, Codex solo usa o genera memorias después de que lo actives allí. Puedes controlar las dos partes por separado:

```toml [features] memories = true

[memories] generate_memories = true # extraer memorias de nuevas sesiones use_memories = true # inyectar memorias en futuras sesiones ```

Al activarse, Codex conserva preferencias estables, flujos de trabajo recurrentes, pilas tecnológicas, convenciones de proyectos y errores conocidos entre hilos, almacenando resúmenes, entradas duraderas, entradas recientes y pruebas de respaldo en ~/.codex/memories/.

Vale la pena activarlo. También vale la pena leer las advertencias oficiales, porque definen lo que es: la generación omite sesiones activas o de corta duración, se pausa cuando el porcentaje de límite de tarifa restante cae por debajo del umbral configurado y puede no actualizarse de inmediato cuando finaliza un chat; los archivos son un estado generado que no debes editar a mano; los secretos se ocultan de los campos de memoria generados, pero la documentación aún aconseja revisar antes de compartir. And el almacenamiento es global en lugar de por proyecto, y local para esa máquina: no se sincroniza, y las memorias de un repositorio pueden aparecer en otro.

El Paso 1 fue el trabajo interesante, y fíjate en qué tipo de trabajo era: traducir el modelo de activación de una herramienta al diseño de directorios de otra herramienta. Ese esfuerzo no produce nada reutilizable. Tendrás que hacerlo de nuevo para el próximo editor.

También hay una categoría de conocimiento que nunca aparece en esta migración, porque nunca estuvo en un archivo de reglas. Por qué la lógica de reintento parece incorrecta pero no lo es. Qué rechazó el cliente en marzo. La restricción que descubriste un viernes a las 6 p. m. Las reglas contienen lo que te sentaste y decidiste escribir; el resto vive en hilos que no sobreviven a una exportación.

Mantener esa capa fuera del editor es lo que hace que sobreviva a ambos problemas. MemoryLake es una capa de memoria de la que leen tus herramientas: decisiones, documentos y contexto acumulado en un solo almacenamiento, accesible desde Codex y Cursor a través de MCP y desde cualquier otra cosa mediante la API. La próxima migración se convierte en una entrada de configuración en lugar de un proyecto de conversión.

Para ser justos con los archivos: .cursor/rules y AGENTS.md tienen ventajas reales. Son texto plano, viven en el repositorio, se revisan en las pull requests y tus compañeros de equipo los heredan sin hacer nada. Consérvalos para reglas permanentes: para eso son buenos, y Codex los lee de forma nativa. La capa de memoria se gana su lugar para lo que es demasiado largo para cargarlo cada vez, demasiado específico para publicarlo o demasiado fácil de perder como para confiar en que alguien se acuerde de escribirlo.

Paso 1: Crea una clave 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 en un archivo de configuración; los archivos de configuración son exactamente lo que se copia de un lado a otro durante una migración como esta.

Paso 2: Sube tus primeras memorias

Sube los documentos, imágenes y archivos que contienen el contexto que tus reglas nunca capturaron: decisiones de arquitectura con sus motivos, el informe de incidentes que explica el extraño reintento, las restricciones del cliente. Sube fuentes en lugar de resúmenes siempre que puedas.

Paso 3: Conecta tu IA y agentes

Dale acceso a la memoria a Claude, Codex, OpenClaw y otros agentes de IA a través de MCP o la API. Codex admite servidores MCP, y el importador ya convirtió tu configuración de MCP existente, por lo que esta es una entrada de servidor más. El mismo almacenamiento se puede leer desde Cursor si sigues usándolo, y desde cualquier cosa que construyas con la API.

La primera diferencia es que la migración de reglas deja de tener pérdidas. Ahora mismo pierdes la lógica de activación y el conocimiento no escrito; después, solo estarás convirtiendo la parte que realmente es un archivo.

La segunda es que usar ambos editores se vuelve algo normal. Mucha gente conserva Cursor para editar y usa Codex para ejecuciones de agentes más largas. Hoy en día, eso significa mantener dos copias de las mismas convenciones en dos formatos y ver cómo divergen. Un único almacenamiento del que ambos leen elimina la duplicación; la misma razón por la que conectar la memoria compartida a través de MCP vale la pena hacerlo una vez en lugar de por herramienta.

La tercera es la independencia de la máquina. Las memorias de Codex son locales por diseño, por lo que una segunda computadora portátil comenzará vacía incluso después de una migración perfecta. Una capa de memoria no tiene esa propiedad.

Y tus archivos de instrucciones se vuelven más pequeños, lo que importa más en Codex que en Cursor: todo lo que está en el alcance se carga en cada tarea, por lo que el hecho de que Codex inicie cada sesión sin el contexto de tu proyecto es un problema que querrás resolver con recuperación, no con un archivo raíz más largo.

Convierte por modo de activación, no por archivo

El instinto es migrar archivo por archivo. En su lugar, clasifica por frontmatter (alwaysApply, globs, basados en descripción, manuales), porque cada modo tiene un destino diferente y uno de ellos (Apply Intelligently) no tiene ningún destino. La migración archivo por archivo es la razón por la que todo termina en el AGENTS.md raíz.

Coloca las reglas con alcance en directorios con alcance

Una regla sobre tu capa de API pertenece a un AGENTS.md dentro del directorio de la API. Este es el hábito de mayor valor en toda la migración: preserva la delimitación de alcance que de otro modo perderías y mantiene corto tu archivo raíz. También significa que los nuevos miembros del equipo descubren la regla donde está el código.

Revisa la importación en lugar de confiar ciegamente en ella

/import es bueno, pero no es un traductor. Lee el resultado, elimina las frases específicas de Cursor, ejecuta /memories list, confirma que los servidores MCP se inicien. Quince minutos aquí evitan meses de un agente siguiendo instrucciones escritas para una herramienta diferente.

Decide qué merece realmente estar siempre activo

Todo lo que está en el alcance consume contexto en cada solicitud, para siempre. Antes de ascender una regla que antes era condicional a siempre activa, pregúntate si pagarías por ella en cada una de las tareas. La mayoría de las reglas de Apply Intelligently no pasan esa prueba, y eliminarlas es un mejor resultado que arrastrarlas.

La parte mecánica ahora es fácil: Codex v0.145 importa la configuración de Cursor, los servidores MCP, los plugins, las sesiones, los comandos de barra diagonal y las memorias con alcance de proyecto en un solo comando. La parte que requiere tu criterio es que los cuatro modos de activación de Cursor se reducen al único mecanismo posicional de Codex: de modo que las reglas alwaysApply se trasladan directamente, las reglas con alcance de glob se convierten en archivos AGENTS.md de subdirectorios, las reglas activadas por descripción deben ascenderse o descartarse deliberadamente, y las reglas manuales se quedan como documentos a los que apuntas.

Luego está la capa que esta migración nunca toca, porque nunca estuvo en un archivo. Mantener eso en un almacenamiento que ambos editores lean es la diferencia entre migrar tus reglas y migrar tu conocimiento, y es lo que evita que el próximo cambio te cueste otra tarde de trabajo.