🗺️ Los tres niveles de migración
Un clic, un comando, personal. El newsletter que dio origen a este curso divide la migración de Claude a Codex en tres niveles. Los dos primeros son mecánicos y rápidos; el tercero es el que realmente importa y el que ninguna herramienta hace por ti. Aquí vas a entender cada nivel, qué es de verdad específico del modelo, por qué la mayor parte del trabajo es una limpieza, y cuándo vale la pena construir tu propio harness.
🖱️ Nivel 1: importar en la app de Codex
El nivel más superficial es el más fácil: abres la app de escritorio de Codex, haces clic en Importar, y ella trae de Claude Code las skills, los comandos, los plugins, los proyectos y las sesiones de chat. Es la promesa del "un clic". Funciona, y para quien solo quiere probar Codex con lo que ya tiene, resuelve.
Pero hay una trampa que la auditoría de esta máquina reveló: el Codex CLI (la versión de terminal, 0.154 en la fecha del diagnóstico) no tiene comando import. El "un clic" existe solo en la app de escritorio. Si tu flujo es en la terminal, el nivel 1 simplemente no está disponible para ti. Por eso existe el curso: para el nivel 2 y el 3.
¿Nuevo por aquí? "Importación nativa" es cuando la propia herramienta de destino ofrece un botón o comando oficial para traer la configuración de otra herramienta. "CLI" es la versión de línea de comandos (escribes codex en la terminal); "app de escritorio" es la ventana con interfaz gráfica. Son el mismo producto, pero no siempre tienen las mismas funciones.
✓ Lo que el nivel 1 resuelve
- ✓Trae skills, comandos y plugins de una vez, sin que toques ningún archivo.
- ✓Copia proyectos y sesiones de chat, así que el historial no desaparece.
- ✓Ideal para probar Codex en 5 minutos.
✗ Lo que no resuelve
- ✗No existe en el CLI: quien trabaja en la terminal se queda sin nada.
- ✗Copia el ruido también: skills muertas, sesiones viejas, memoria sin aprobación.
- ✗No separa nada: sigues con dos cerebros, ahora duplicados.
- ✗Nada garantiza que Codex vaya a usar lo que importó.
Conceptos clave
Botón oficial de la herramienta de destino. Solo en la app de escritorio de Codex.
Mismo producto, recursos diferentes. El CLI 0.154 no importa.
Importar duplica el cerebro; no lo vuelve portátil.
Ejecuta codex --help y mira la lista de comandos tú mismo.
⌨️ Nivel 2: un comando
El segundo nivel es la idea de un comando que lleva todos tus recursos de Claude Code a Codex. El texto original imagina algo como npx migrate to codex y sugiere que se puede adaptar a un stack con Gemini. También recomienda, antes de ejecutar cualquier cosa, dejar que un agente audite toda la configuración de Claude para que ningún detalle se pierda.
Ese comando hipotético no existe listo para usar. Por eso nació el kit agente-claude-codex: es el nivel 2 de esta máquina, dividido en cinco scripts que se ejecutan en orden y que vas a usar de verdad en la Ruta 2.
Léelo como una escalera: el nivel 1 es mecánico y superficial, el nivel 2 automatiza el cambio, y solo el nivel 3, destacado, carga lo que sobrevive al cambio de modelo. Cuanto más alto, más duradero.
🧰 El "un comando" de esta máquina: cinco scripts en orden
scripts/doctor.sh y scripts/audit.sh: diagnostican el entorno e inventarían skills, hooks, MCP, sin alterar nada.
scripts/adapt-instructions.sh: separa el CLAUDE.md en un AGENTS.md portátil más el residuo Claude.
scripts/init-core.sh: instala el núcleo portátil sin sobrescribir lo que ya existe.
scripts/sync-skills.sh: una fuente canónica de skill, copias generadas por runtime, verificación de drift.
scripts/readback-test.sh: abre una sesión nueva en cada runtime y prueba que el agente leyó y usó el contexto.
💡 Consejo práctico
Todo script del nivel 2 empieza en modo audit: lee e informa, no cambia. Solo después de que leíste el informe y lo aprobaste, el paso siguiente altera archivos, y siempre con un backup al lado. Si un "comando de migración" que encuentres por ahí no tiene esa fase de auditoría, desconfía.
Conceptos clave
Migración automatizada y reproducible, no manual.
Un agente inventaría todo para que nada se pierda.
El kit que implementa el nivel 2 en cinco scripts.
Cada paso tiene backup o genera un archivo propuesto.
🧠 Nivel 3: la capa personal duradera
Este es el nivel que realmente importa para la mayoría de las personas. Aquí entran el conocimiento privado, el contexto de los proyectos, el overview.md, el sources.md, los playbooks, los handoffs y la documentación. Es la capa duradera, la que no queda atada a ningún modelo específico. Ningún botón de importar y ningún script hacen esto por ti, porque es tu forma de trabajar, no una configuración.
Piensa en lo que pasaría si mañana Claude y Codex desaparecieran y tuvieras que usar un tercer agente. ¿Qué te gustaría haber guardado en archivos comunes, legibles por cualquiera? Eso es el nivel 3.
Conocimiento privado
Hechos sobre ti, tus clientes, tus proyectos. En esta máquina: los runbooks de Skool, del login INEMA.PRO, de los modelos de Magnific.
Contexto de los proyectos
Qué es cada proyecto, dónde está, qué funciona, qué está pendiente. Hoy disperso en 165 archivos CLAUDE.md.
Playbooks y procesos
Cómo publicas, versionas, generas imágenes, entregas. Reglas que valen para cualquier agente que trabaje contigo.
Handoffs
El resumen estructurado de cada sesión: decisiones, pendientes, próximos pasos, rutas de archivo. Viaja a cualquier proveedor.
✓ Señales de que está en el nivel 3
- ✓Es Markdown común, dentro del proyecto, sin depender de plugins.
- ✓Una persona lo entiende al abrirlo, no solo un agente.
- ✓Tiene fecha, fuente y dueño.
- ✓Sobrevive si cambias de herramienta mañana.
✗ Señales de que todavía es nivel 1 o 2
- ✗Vive en
~/.claude/projects/*/memoryy solo Claude lo lee. - ✗Está en sesiones JSONL de 2,3 GB que nadie va a releer.
- ✗Depende de un hook o plugin que el otro runtime no tiene.
- ✗Fue importado, pero nunca leído ni aprobado.
Conceptos clave
Lo que sobrevive al cambio de modelo.
Hechos verificados y de dónde vinieron. Detalle en el 1.4.
Proceso escrito que cualquier agente sigue.
Resumen de sesión que la próxima sesión lee primero.
🧹 La gran limpieza
El cambio de mentalidad principal, en palabras del texto original: la mayor parte de esto es simplemente una gran limpieza. Suena a algo supercientífico, pero es básicamente un Marie Kondo para tus carpetas, el mismo tipo de orden que harías en la computadora aunque la IA no existiera.
El cerebro del Claude Code de mucha gente está lleno de archivos muertos, cosas viejas, documentos archivados e información irrelevante. Migrar eso en crudo solo transporta el ruido. Antes de migrar cualquier cosa: limpia el "segundo cerebro", archiva por defecto, y trae información de vuelta al contexto solo cuando haga falta.
¿Nuevo aquí? "Marie Kondo de las carpetas" es la regla de guardar solo lo que todavía sirve y archivar el resto. "Segundo cerebro" es el conjunto de notas y archivos donde guardas lo que no cabe en la cabeza. "Archivar por defecto" significa que la regla es quitar del camino; traer de vuelta es la excepción, hecha bajo demanda.
📊 El ruido de esta máquina, medido en el diagnóstico del 2026-09-14
- •6.859 sesiones JSONL de Claude, 2,3 GB, más 209 de Codex. Historial, no fuente.
- •227 carpetas de memoria con 869 archivos que solo Claude lee y nadie aprobó.
- •CLAUDE.md de 1.391 líneas en un proyecto (ruflo), 542 en otro. Un archivo de ese tamaño se vuelve ruido en los dos runtimes.
- •11 skills archivadas y 117 activas, de las cuales 89 solo existen en Claude.
Inventariar
Ejecuta la auditoría antes de decidir. No limpias lo que no ves.
Archivar por defecto
Skill que no corre hace 90 días, sesión vieja, memoria sin uso: al archivo. Nada se borra, solo sale del camino.
Promover lo que vale
Un hecho verificado va al overview.md con fecha y fuente. Una regla estable va al AGENTS.md. El resto se queda donde está.
Solo entonces migrar
Con el cerebro depurado, lo que cruza a Codex es pequeño, claro y útil.
Conceptos clave
Limpiar es la mayor parte del trabajo, no la migración.
Quitar del camino es la regla; traer de vuelta, la excepción.
Sesiones, memoria y CLAUDE.md gigantes tienen número.
El contexto entra en la sesión cuando la tarea lo pide.
🎯 Lo que realmente es específico del modelo
Aquí está la buena noticia que cambia el tamaño del problema: la parte realmente atada al proveedor es pequeña. Básicamente, solo el agents.md y el claude.md están fuertemente ligados a una herramienta. Gemini también usa agents.md. A GLM se le puede indicar que respete ese archivo. El claude.md es la única excepción realmente específica de Claude. Prácticamente todo lo demás es Markdown portátil.
Compara los tamaños: la caja pequeña es todo lo que depende del proveedor, dos archivos de instrucciones. La caja grande, destacada, es tu trabajo de verdad, y es solo Markdown que cualquier agente lee.
🧩 Quién lee qué
Lee
CLAUDE.md. Con @AGENTS.md en la primera línea, importa el portátil.Lee
AGENTS.md. Sin él, entra "a ciegas": 13 proyectos de esta máquina están así.También lee
AGENTS.md.Se les puede indicar que respeten
AGENTS.md por instrucción en el prompt o en el harness.⚠️ El error a evitar
Mantener dos fuentes de verdad: un CLAUDE.md y un AGENTS.md escritos a mano, cada uno con reglas distintas. En esta máquina, 39 proyectos tienen ambos archivos y nadie sabe cuál manda. El patrón correcto es uno solo portátil (AGENTS.md) y el otro importando (@AGENTS.md) más el residuo específico.
Conceptos clave
CLAUDE.md y AGENTS.md son lo que te ata al proveedor.
Codex, Gemini y GLM lo leen; Claude lo importa.
El núcleo no cambia; el borde traduce para cada herramienta.
Nunca dos archivos de instrucciones divergentes.
🔧 Cuándo vale la pena construir tu propio harness
Una tentación común es construir un "OmniAgent" o un súper-harness que envuelva a todos los modelos. Para Claude y Codex, el texto es directo: no pierdas tiempo con eso. Sus harnesses ya están bastante optimizados, y son los propios proveedores quienes hacen el trabajo de dar seguimiento y adaptar el harness a medida que aparecen nuevos modelos.
¿Dónde vale la pena crear el tuyo? Para modelos locales. En esos casos el harness por defecto suele ser mucho más débil. Es lo que el autor hace con PyHarness, entrenando y evolucionando a partir de sesiones excelentes hechas con modelos fuertes. En esta máquina, el caso análogo es dsh-sandbox y openpcbotv3, que verás en la Ruta 3.
¿Nuevo aquí? "Harness" es la estructura alrededor del modelo: el bucle que lee tu mensaje, decide llamar herramientas, ejecuta comandos, lee archivos y devuelve la respuesta. Claude Code y Codex son harnesses. "PyHarness" es el harness propio, en Python, que el autor del texto mantiene para modelos locales, usando como referencia sesiones buenas de modelos como Astra y Fable. Un "súper-harness" sería un harness único por encima de todos los modelos.
✓ Vale la pena construir un harness cuando
- ✓El modelo es local y su harness por defecto es débil.
- ✓Tienes sesiones excelentes de modelos fuertes para usar como referencia.
- ✓Privacidad, costo o trabajo offline exigen ejecutar todo en casa.
✗ No vale la pena cuando
- ✗El objetivo es Claude o Codex: el proveedor ya optimiza y actualiza.
- ✗La motivación es "unificar todo": lo que unifica es el contexto, no el harness.
- ✗Todavía no hiciste la limpieza ni tienes la capa durable en su lugar.
🔭 Dos advertencias del texto original
- •Todo esto es iterativo. Cada cambio puede mejorar una skill para un modelo y romper la misma skill para otro. Da seguimiento a lo que cada modelo realmente necesita.
- •Los modelos cerrados quizá ya no necesiten skills. Si se entrenan con base en tus conversaciones, muchas skills se vuelven innecesarias. Los modelos locales tal vez sigan dependiendo de ellas. Construye agnóstico, pero da seguimiento a cada proveedor.
Conceptos clave
El loop de herramientas alrededor del modelo.
No aplica para Claude y Codex: ellos ya se encargan de eso.
Aquí sí: el estándar es débil y puedes entrenar el tuyo.
Mejorar para uno puede romper para otro. Medir siempre.
Autoevaluación (opcional): trabajas en la terminal con el Codex CLI y quieres migrar tu setup de Claude. ¿Qué camino está disponible?
🎯 Resumen del módulo
Próximo módulo:
1.4 — Anatomía de un workspace portátil: AGENTS.md, context/, tasks/, handoffs/