Cómo migrar de Codex a Warp sin perder el contexto (2026)

El nombre y el contenido del archivo se transfieren por completo. Codex "lee los archivos AGENTS.md antes de realizar cualquier trabajo". Las Project Rules de Warp residen en "un archivo AGENTS.md (o WARP.md para compatibilidad con versiones anteriores)". Mismo nombre de archivo, mismo markdown, sin conversión.

Un detalle del nombre del archivo te afectará si fuiste descuidado. La documentación de Warp incluye una advertencia explícita: "El nombre del archivo debe estar en mayúsculas para que Warp lo reconozca (por ejemplo, AGENTS.md, no agents.md o Agents.md)". Codex es igual de estricto de una manera diferente: su lista de alternativas es exacta y "Los nombres de archivo que no están en esta lista se ignoran para el descubrimiento de instrucciones". Si habías registrado un nombre en minúsculas o personalizado a través de project_doc_fallback_filenames, Warp no lo verá.

El anidamiento funciona, pero la acumulación reemplaza a la anulación. Este es el cambio sustancial.

El modelo de Codex: "Comenzando en la raíz del proyecto (normalmente la raíz de Git), Codex desciende hasta tu directorio de trabajo actual... En cada directorio a lo largo de la ruta, busca AGENTS.override.md, luego AGENTS.md y después cualquier nombre alternativo en project_doc_fallback_filenames. Codex incluye como máximo un archivo por directorio". Luego los fusiona: "Codex concatena los archivos desde la raíz hacia abajo... Los archivos más cercanos a tu directorio actual anulan las instrucciones anteriores porque aparecen más tarde en el prompt combinado".

El modelo de Warp: "Warp aplica automáticamente el AGENTS.md (o WARP.md) en la raíz y en el directorio actual", y "Si editas archivos en otro subdirectorio, Warp hace un esfuerzo razonable para incluir también el archivo de reglas de ese subdirectorio". Los conflictos se resuelven mediante una precedencia establecida: "1. Reglas en el archivo de reglas del proyecto del subdirectorio actual 2. Reglas en el archivo de reglas del proyecto del directorio raíz 3. Reglas globales (Global Rules)".

Ambos terminan prefiriendo lo específico sobre lo general. El diferencia es lo que sucede con las instrucciones que querías eliminar. En Codex, un AGENTS.override.md en un directorio significa que el AGENTS.md del mismo nivel no se lee en absoluto: puedes reemplazarlo por completo. En Warp, la precedencia decide los conflictos, pero el archivo raíz se sigue aplicando. Una regla que declare el archivo raíz y que tu subdirectorio nunca mencione seguirá vigente.

Por lo tanto, una configuración de Codex que usaba anulaciones para crear una excepción necesita que esas excepciones se vuelvan a declarar como contradicciones explícitas en el archivo del subdirectorio, en lugar de simplemente omitirlas.

El límite de bytes desaparece, y eso es un verdadero alivio. Codex "omite los archivos vacíos y deja de agregar archivos una vez que el tamaño combinado alcanza el límite definido por project_doc_max_bytes (32 KiB por defecto)", siendo el remedio "Aumentar el límite o dividir las instrucciones en directorios anidados cuando alcances el límite". La documentación de reglas de Warp no menciona ningún límite equivalente. Si habías estado dividiendo archivos para mantenerte por debajo de los 32 KiB, esa restricción ha desaparecido, aunque "porque puedes hacerlo" es una mala razón para volver a combinarlos.

El alcance global cambia de un archivo a una interfaz de usuario. Codex mantiene las instrucciones globales en ~/.codex/AGENTS.md (o AGENTS.override.md, ya que "Codex utiliza solo el primer archivo no vacío en este nivel"), reubicable con CODEX_HOME. Las Global Rules de Warp "se aplican a todos los proyectos y contextos" y se gestionan en el panel Warp Drive Rules, donde cada regla puede llevar un nombre y una "Descripción (qué hace la regla y cuándo aplicarla)".

Ese es un artefacto diferente. Tu archivo global se convierte en un conjunto de reglas descritas individualmente, no en un documento, y ya no está bajo control de versiones a menos que guardes una copia en algún lugar.

La verificación cambia de herramientas, y ambas son buenas. Codex te ofrece comandos: codex --ask-for-approval never "Summarize the current instructions.", una variante --cd subdir para el comportamiento anidado y una auditoría completa a través de "un registro TUI de texto plano con codex -c log_dir=./.codex-log". Tampoco tiene una caché con la que lidiar: "Codex reconstruye la cadena de instrucciones en cada ejecución (y al inicio de cada sesión de TUI), por lo que no hay caché que borrar manualmente".

En Warp, las reglas en juego aparecen en la conversación: "Las reglas utilizadas en una interacción aparecerán en la conversación bajo References o marcadas como derivadas de una regla específica". Diferente mecanismo, mismo propósito, y vale la pena usarlo durante la primera semana en lugar de darlo por sentado.

La indexación del código base es nueva y es local. Codex lee archivos bajo demanda. Warp mantiene un índice: "Warp indexa tu código base rastreado por Git para ayudar a los Agents a comprender tu código y generar respuestas precisas y conscientes del contexto. No se almacena código en los servidores de Warp". Obtienes estados (Synced, Discovering files, Failed, Codebase too large), además de .warpindexingignore para el control, y todos los planes admiten "al menos 5,000 archivos por código base".

No hay nada que migrar aquí. Es una capacidad que ganas, con una sincronización en la que ahora tienes que pensar: "si muchos archivos han cambiado o la red es lenta, es posible que la sincronización no se complete antes de que el Agent intente acceder al contexto".

Agent Memory es la ventaja, con tres condiciones. Agent Memory de Warp "proporciona a los agentes en Warp memoria persistente a través de los entornos compatibles, incluidos Warp Agent, Claude Code y Codex". Es un sistema serio: almacenes personales, de agente y de equipo; extracción automática donde "El nuevo conocimiento se fusiona con las memorias existentes o las reemplaza en caso de conflicto"; acceso de solo lectura o de lectura y escritura por almacén con instrucciones por almacén; trazabilidad, donde "Cada memoria registra de dónde proviene"; y auditabilidad, donde "Se registra cada cambio en una memoria".

Ahora las condiciones, las tres documentadas y las tres importantes. "Está en research preview (vista previa de investigación) y se habilita por equipo para socios de diseño", con una lista de espera. La cobertura de entornos de terceros se aplica cuando se ejecutan como agentes en la nube: "La ejecución local de entornos de terceros no es compatible durante la vista previa de investigación". Y reside en Warp: "La memoria permanece vinculada a su propietario (un usuario, un agente o un equipo), independientemente de qué entorno lea o escriba".

Así que la versión honesta es: si tu equipo es un socio de diseño y ejecutas Codex como un agente en la nube de Warp, obtienes una capa de memoria alojada. Si no lo eres, o si ejecutas Codex localmente en tu propia terminal, no la obtienes, y las propias memorias locales de Codex, que están desactivadas por defecto y se explican en activar las memorias locales de Codex, se quedan en tu máquina.

Paso 1: Mover los archivos y luego volver a declarar cada anulación como una contradicción

Copia cada AGENTS.md en la misma ruta. Nada cambia en el contenido.

Luego maneja las anulaciones, que es la parte que requiere criterio. Para cada AGENTS.override.md en tu árbol, pregúntate qué estaba suprimiendo. Si existía para reemplazar una regla raíz (por ejemplo, "usa make test-payments en lugar de npm test"), vuelve a declararla en el AGENTS.md de ese directorio como una instrucción explícita, porque en Warp la regla raíz se seguirá aplicando y la precedencia solo ayuda donde ambas entran en conflicto directo. Si existía para suprimir una regla raíz sin ofrecer un reemplazo, necesitas una frase que lo diga claramente, ya que el silencio ya no suprime nada.

Mientras estés allí, revisa tu archivo global. Divide ~/.codex/AGENTS.md en Global Rules individuales con descripciones, y guarda una copia en el control de versiones si te interesa revisar sus cambios; el panel de Warp Drive es una buena superficie de edición, pero no un historial de git.

Si tu repositorio usaba nombres de archivo personalizados a través de project_doc_fallback_filenames, cámbialos a AGENTS.md (todo en mayúsculas) en las rutas correspondientes. El comando /init de Warp también puede vincular un archivo de reglas externo existente, y la lista documentada es específica: "CLAUDE.md, .cursorrules, AGENT.md, GEMINI.md, .clinerules, .windsurfrules, .github/copilot-instructions.md". Ten en cuenta el singular AGENT.md en esa lista; el plural AGENTS.md se lee de forma nativa.

Paso 2: Decidir sobre Agent Memory con honestidad, luego indexar y verificar

Responde a dos preguntas antes de planificar algo en torno a Agent Memory: ¿está tu equipo habilitado para la vista previa de investigación (research preview) y ejecutarás Codex como un agente en la nube de Warp en lugar de localmente? Si alguna respuesta es no, trata a Agent Memory como una capacidad futura y diseña como si no existiera.

Esto no es una crítica a la función. Es lo que dice la documentación, y construir un flujo de trabajo sobre una vista previa de investigación en la que no estás inscrito es la forma en que los equipos terminan con una brecha de contexto que descubren tres semanas después.

Luego configura lo que definitivamente sí obtienes. Abre tu repositorio en Warp para que comience la indexación y verifica el estado en Settings > Code > Indexing and projects hasta que aparezca Synced. Agrega un .warpindexingignore si el repositorio es grande. Luego ejecuta una conversación con el Agent y mira la sección References para confirmar qué reglas se extrajeron realmente; el mismo instinto que ejecutar el comando de resumen de instrucciones de Codex, y la razón por la cual los agentes ignoran tus archivos de instrucciones suele ser un problema de descubrimiento en lugar de uno de comprensión.

La migración de archivos es una copia más una auditoría de anulaciones. Lo que este movimiento expone es que el conocimiento duradero de tu proyecto ha estado dependiendo de la herramienta que casualmente estuvieras usando: las memorias locales de Codex en una máquina, o Agent Memory de Warp si estás inscrito y ejecutando en la nube.

Ambas son funciones reales. Ninguna es un lugar para colocar el conocimiento que necesitas independientemente del estado de inscripción, la máquina o el lugar donde se ejecute el agente. Esa capa no debería ser una propiedad del entorno en absoluto.

Colócalo fuera y el cálculo se simplifica: migras las reglas, obtienes la indexación del código base y los datos que tus agentes necesitan ya están allí en la primera ejecución. MemoryLake se configura en tres pasos.

Paso 1: Crear una clave API

Inicia sesión y genera una clave API desde tu panel de control. No depende de una inscripción en la vista previa de investigación ni de si el agente se ejecuta localmente o como un agente en la nube, que es precisamente la ambigüedad que introduce esta migración.

Paso 2: Subir tus primeras memorias

Introduce lo que ni un archivo de reglas ni un índice pueden proporcionar: decisiones de arquitectura y las razones detrás de ellas, por qué sigue existiendo un servicio obsoleto, vocabulario del dominio, propiedad y las restricciones que tienen motivos asociados.

Mantén el comportamiento en AGENTS.md, ahora sin un límite de 32 KiB con el que luchar, lo cual es una buena razón para mantener esos archivos cortos a propósito en lugar de porque te viste obligado a hacerlo.

Paso 3: Conectar tu IA y agentes

Apunta Warp al almacén, y apunta Codex a él también mientras sigues ejecutando ambos. Una migración por etapas es exactamente el momento en que una capa compartida se gana su lugar, ya que la alternativa son dos herramientas con dos visiones parciales, el caso expuesto en compartir una memoria entre herramientas.

El primer cambio es que la auditoría de anulaciones es un costo de una sola vez en lugar de una sorpresa recurrente. Una vez que las excepciones se declaran en lugar de implicarse, sobreviven también a la siguiente herramienta.

El segundo es que perder el límite de bytes no significa perder la disciplina. 32 KiB era un techo arbitrario; los archivos de instrucciones cortos se siguen mejor que los largos, y los datos que solían competir por ese presupuesto ahora viven en otro lugar.

El tercero es que Agent Memory se convierte en un extra en lugar de una dependencia. Si tu equipo se inscribe, agrega memoria compartida por el equipo, rastreable y auditable, además de lo que ya tienes. Si no lo hace, nada en tu configuración dependía de ello, que es el punto de mantener el contexto de IA del equipo independiente de cualquier herramienta.

• Mantén el nombre del archivo en mayúsculas. Warp lo requiere; los nombres en minúsculas y personalizados registrados en Codex no se verán.
• Audita cada AGENTS.override.md. Warp aplica el directorio raíz y el actual de forma conjunta, por lo que la ausencia ya no suprime.
• Vuelve a declarar las supresiones explícitamente. Una regla que querías eliminar necesita una frase, no una omisión.
• Divide el archivo global en reglas descritas. Y guarda una copia bajo control de versiones si deseas un historial de cambios.
• Deja que la indexación termine antes de juzgar la calidad. Busca el estado Synced y usa .warpindexingignore en repositorios grandes.
• Lee la sección References. Es la respuesta de Warp al comando de resumen de instrucciones de Codex.
• No planifiques en torno a Agent Memory a menos que estés inscrito. Vista previa de investigación (research preview), por equipo para socios de diseño, solo agentes en la nube durante la vista previa.
• Mantén los archivos de instrucciones cortos de todos modos. El límite de 32 KiB ha desaparecido; la razón para la brevedad no.

La mitad de esta migración correspondiente a los archivos es una copia, y las dos ganancias reales (la indexación del código base y la ausencia de límite de bytes) llegan sin ningún esfuerzo.

Las dos cosas que se deben manejar deliberadamente son la semántica de anulación, que no sobrevive a la migración, y Agent Memory, que es excelente y condicional de tres maneras documentadas. Vuelve a declarar tus excepciones, mantén los datos duraderos en una capa que ninguna de las dos herramientas posea, y el cambio te costará una tarde en lugar de un trimestre redescubriendo lo que tus agentes solían saber.