Guía de migración de Claude Code a Codex 2026

El 3 de mayo de 2026 inventarié 744 entradas locales de configuración de agentes y luego clasifiqué 691 de ellas por peso operativo.¹ La cifra parecía grande. La forma importaba más: alrededor de 20 archivos sostenían el sistema.

Una migración de Claude Code a Codex debe portar contratos operativos, no copiar el árbol de archivos. Mueve las reglas de CLAUDE.md a capas de AGENTS.md, los procedimientos reutilizables a habilidades de Codex, los umbrales deterministas a ganchos enfocados, la postura de riesgo a perfiles y las herramientas de navegador/fuentes a MCP explícitos. No copies una red de ganchos de Claude en Codex; mueve las obligaciones de prueba.

Resumen rápido

La pila privada de escritura y verificación ya existe en mi mundo de Codex. Lo que faltaba no era el contenido de las habilidades. Faltaba el manual operativo público: dónde deben vivir las habilidades reutilizables, cómo debe seleccionarlas Codex, qué perfil debe ejecutar la escritura pública y qué umbrales de la época de Claude deben convertirse en reglas nativas de Codex sin exponer detalles privados del flujo de trabajo.

La primera pasada real con Codex cambió la regla de migración: no conviertas un flujo privado en comportamiento ambiental en el momento en que lo portas. Hazlo por etapas. Mi ruta de escritura específica del sitio ahora empieza solo por invocación explícita, mientras que el flujo de migración vive como habilidad de usuario para uso local activo y como candidato a paquete privado de Codex para pruebas locales. Ese paquete no es de código abierto ni está disponible de forma general; si quieres probar el flujo de migración, contáctame. El paquete no debe convertirse en la ruta predeterminada del entorno de ejecución solo porque exista una entrada de instalación local. Un piloto de instalación real todavía necesita validación del paquete, verificación de instalación del plugin, descubrimiento de habilidades con espacio de nombres, limpieza de duplicados y una sesión nueva de Codex antes de significar algo. Así el sistema puede aprender del trabajo real antes de que un flujo pase a ser comportamiento predeterminado.¹⁸¹⁰¹⁴

No empieces clonando cada gancho de Claude en Codex. Empieza escribiendo el contrato de Codex:

• Coloca la política duradera entre repositorios en ~/.codex/AGENTS.md.
• Coloca la política del repositorio en AGENTS.md y ubica las anulaciones más estrechas cerca del trabajo.
• Coloca los procedimientos reutilizables en .agents/skills o $HOME/.agents/skills.
• Eleva la escritura pública a careful-review o a un perfil dedicado public-writing.
• Mantén los umbrales deterministas como ganchos, pero trata los ganchos como una baranda de seguridad, no como todo el modelo de seguridad.

El primer artefacto de migración exitoso debe ser una publicación que se describa a sí misma. Ese artefacto demuestra que el sistema puede explicarse, citar documentación actual, usar un inventario local saneado y producir trabajo público bajo control de Codex sin publicar la maquinaria privada que hay detrás.

Cubrí el lado Claude de la pila en Claude Code como infraestructura, el lado de los archivos de instrucciones en Patrones de AGENTS.md y el problema de degradación de las habilidades en Las habilidades estáticas son habilidades muertas. La migración de abajo conecta esos hilos con el entorno de ejecución de Codex que realmente uso.

Para contexto relacionado, lee la guía de Codex CLI, Claude Code vs Codex, Codex vs Claude Code 2026, Tutorial de ganchos de Claude Code, Crear habilidades personalizadas y Filosofía de calidad Jiro. Esas publicaciones explican las piezas que la migración ensambla aquí.

¿Qué mostró el inventario de migración?

El sistema local tenía 3 centros de gravedad.

Los datos de uso apuntaban a la misma conclusión. Mis registros de enrutamiento de perfiles mostraban que el trabajo cargado de revisión dominaba la ejecución rutinaria.¹ El verdadero centro no era el archivo más largo ni el script más ingenioso. Era la capa de decisión que elegía el nivel de riesgo, cargaba la doctrina y exigía evidencia antes de completar el trabajo.

Ese hallazgo cambia la migración.

Si lo importante fuera que “Claude tiene muchos ganchos”, la migración copiaría ganchos. Si lo importante fuera que “el sistema tiene una filosofía”, la migración copiaría prosa. El inventario mostró otra respuesta: lo importante es un contrato pequeño que se activa en el momento correcto.

¿Qué hicimos antes de publicar?

El artículo mismo se convirtió en el primer ejercicio de migración.

Primero mapeé la forma de la configuración madura de Claude Code: qué piezas gobernaban el comportamiento, cuáles solo documentaban preferencias y cuáles debían seguir siendo privadas. Luego contrasté el comportamiento actual de Codex con la documentación oficial y el CLI local, porque las guías de migración se degradan rápido cuando heredan flags antiguos o formas de configuración no admitidas. Después redacté este artículo pensando en la migración real, pero reduje el detalle público a arquitectura saneada, no a implementación privada.

El siguiente paso ocurre antes de la publicación: usar esta guía para construir la configuración de Codex y luego revisar el artículo a partir de lo que realmente cambió. El artículo público debe mostrar el patrón de migración y los criterios de aceptación. No debe publicar instrucciones privadas, flujos privados de escritura, detalles exactos de ganchos, rutas sensibles ni nada que permita a un lector reconstruir el sistema privado.

La pasada en vivo produjo una tabla de prueba segura para publicar. Solo publico el contrato, el estado de activación y la señal de aceptación, no las instrucciones privadas, los cuerpos exactos de los ganchos ni los detalles internos del flujo de escritura.

¿Deberías empezar una migración a Codex con ganchos?

Claude me enseñó a pensar en eventos de ciclo de vida. Un gancho UserPromptSubmit puede inyectar contexto de proyecto. Un gancho PreToolUse puede bloquear rutas sensibles. Un gancho Stop puede rechazar una finalización débil. Ese patrón funciona en Claude porque mi pila local creció alrededor de despachadores que convierten muchos scripts pequeños en una sola canalización ordenada de eventos.¹¹

Codex también tiene ganchos, pero el Codex actual los trata como un sistema de ciclo de vida detrás de una función habilitada, no como un directorio de ganchos siempre activo. La documentación de ganchos de OpenAI muestra [features] codex_hooks = true en config.toml, y mi codex features list local reporta hooks como estable y habilitado en Codex CLI 0.130.0.²⁸ OpenAI documenta la entrada de ganchos como JSON por stdin, con campos compartidos como id de sesión, directorio de trabajo, nombre de evento y modelo activo.² Codex admite eventos como SessionStart, PreToolUse, PermissionRequest, PostToolUse, UserPromptSubmit y Stop; PreToolUse puede interceptar Bash, apply_patch y llamadas a herramientas MCP.²

La misma documentación también da la advertencia que importa para la migración: PreToolUse sigue siendo una baranda de seguridad, no un límite completo de aplicación. La documentación señala que la intercepción no cubre todas las rutas de shell y no intercepta web search ni otras llamadas que no sean shell ni herramientas MCP.²

Esa limitación no vuelve débiles a los ganchos de Codex. Significa que los ganchos no deben cargar con toda la migración. OpenAI también señala que varios ganchos de comando que coinciden para el mismo evento se lanzan en paralelo, así que una migración a Codex que requiera orden todavía necesita un despachador o un único comando de gancho combinado.²

Para Codex, quiero ganchos para verificaciones deterministas estrechas:

• Bloquear comandos de shell obviamente destructivos.
• Advertir sobre rutas con forma de credencial.
• Agregar un contexto pequeño al inicio de la sesión.
• Registrar evidencia de ejecuciones de escritura pública.
• Hacer fallar un evento stop cuando falte un artefacto requerido o un comando de verificación.

No quiero que los ganchos carguen con la voz de escritura, la política de citas, la filosofía, el enrutamiento o la doctrina del proyecto. Codex ya tiene mejores lugares para eso.

¿Cómo se mapean los artefactos de Claude a Codex?

La migración se vuelve más limpia cuando cada artefacto de Claude se mapea al primitivo de Codex que mejor encaja con su trabajo.

La documentación de AGENTS.md de OpenAI convierte la primera fila en la columna vertebral de la migración. Codex lee archivos AGENTS.md antes de trabajar, aplica en capas la guía global desde el directorio home de Codex y luego recorre desde la raíz del proyecto hasta el directorio actual, permitiendo que los archivos más cercanos anulen la guía anterior.³ Ese comportamiento encaja con lo que en realidad necesito de CLAUDE.md: acuerdos persistentes de trabajo más detalles locales del proyecto.

El movimiento importante: reescribir las reglas como operaciones. “Escribe con cuidado” no pertenece a AGENTS.md. “Para posts públicos, reúne citas primero, verifica URLs, ejecuta checks de frases prohibidas y reporta cualquier afirmación no verificada” sí pertenece ahí.

¿Cómo deben moverse las habilidades privadas de escritura a Codex?

La pila del escritor de blog se porta limpiamente porque ya tiene la forma correcta. Una habilidad de Codex es una carpeta con un archivo SKILL.md que contiene frontmatter e instrucciones. Codex puede activar habilidades cuando el usuario las invoca explícitamente o cuando la tarea coincide con la descripción de la habilidad.⁴ Codex lee habilidades desde ubicaciones de repositorio, usuario, administración y sistema, incluidas .agents/skills del repositorio, $HOME/.agents/skills y /etc/codex/skills.⁴

Aquí una migración de Claude Code puede equivocarse de forma sutil. Las habilidades de Codex no son comandos slash de Claude. La ruta oficial de Codex para invocación explícita de habilidades es el selector de habilidades o una mención $skill-name, mientras que los comandos slash de Codex CLI son una superficie interactiva separada para acciones incorporadas como estado, permisos, cambios de modelo, plugins y control de sesión.⁴¹⁵ Una instrucción como /cave todavía puede servir como atajo si la descripción de la habilidad la reconoce o si un envoltorio la convierte en Use $cave ..., pero el texto slash por sí mismo no es el contrato duradero. Para prueba de migración, prueba $skill-name; luego prueba /name por separado solo si prometes esa compatibilidad.

Eso significa que debo normalizar las nuevas habilidades de escritura nativas de Codex en las rutas oficiales sin publicar los nombres ni contenidos privados de las habilidades:

$HOME/.agents/skills/source-verifier/SKILL.md
$HOME/.agents/skills/public-post-writer/SKILL.md
$HOME/.agents/skills/site-specific-writer/SKILL.md

Mi entorno de ejecución local también tiene habilidades de usuario funcionales en una ubicación anterior.¹ No debo borrarlas solo porque la documentación pública nombre .agents/skills. La migración segura es:

1. Copiar o enlazar simbólicamente una habilidad en $HOME/.agents/skills.
2. Reiniciar Codex.
3. Confirmar que Codex lista y activa la habilidad.
4. Hacer que la habilidad sea solo explícita mientras está en piloto.
5. Mover el resto solo después de que el descubrimiento y el uso piloto funcionen.
6. Dejar la ruta antigua en su lugar hasta que las sesiones y scripts existentes dejen de depender de ella.

Ese es el camino que tomé para el primer flujo privado de escritura. Preparé un escritor específico del sitio como habilidad privada solo explícita, en lugar de convertirlo en el escritor predeterminado para cada tarea de contenido. Eso le dio a la migración una mejor prueba: si la habilidad mejora este artículo y la siguiente ejecución de escritura pública sin filtrar proceso privado, puede pasar de solo explícita a piloto. Si agrega confusión, se queda acotada.

Los escritores específicos de marca no deben convertirse en escritores predeterminados de sitio. Un escritor privado de producto puede compartir los mismos estándares de citas y revisión, pero su audiencia, datos del producto, llamadas a la acción y reglas de voz deben mantenerse acotados a ese producto. La portabilidad correcta mantiene los adaptadores de marca separados y crea un escritor delgado específico del sitio para blakecrosley.com.

Esa habilidad del sitio debe seguir siendo delgada:

---
name: site-specific-writer
description: Escribe publicaciones técnicas públicas para un sitio específico. Úsalo para artículos que necesitan fuentes verificadas, enlaces internos, voz del sitio y comprobaciones de publicación.
---

# Escritor específico del sitio

Usa las habilidades privadas de escritura, verificación de fuentes y detectabilidad para IA en cada artículo técnico público.

Pruebas obligatorias antes de finalizar:
- Las afirmaciones técnicas externas tienen citas.
- Las afirmaciones actuales sobre Codex citan documentación de OpenAI.
- Las afirmaciones internas enlazan a publicaciones existentes o al análisis del autor.
- La publicación incluye un resumen rápido, conclusiones por rol y preguntas del lector cuando sea útil.

La documentación de habilidades de Codex muestra name y description como los campos de frontmatter de una habilidad manual, y convierte la descripción en el disparador de activación implícita.⁴ El cuerpo puede indicarle a Codex que use habilidades privadas compañeras; la composición pertenece a las instrucciones salvo que una cadena local de herramientas agregue metadatos extra. La pila general posee las reglas de escritura. El envoltorio del sitio posee la voz, los patrones de enlaces y la prueba.

La misma separación aplica al flujo de migración. La documentación de plugins de OpenAI recomienda empezar con una habilidad local cuando todavía iteras sobre un flujo personal, y luego construir un plugin cuando quieres compartir un paquete estable entre equipos o agrupar más integraciones.¹⁰ Eso hizo obvia la ruta activa: primero habilidad de usuario, luego piloto de paquete privado. No he publicado como código abierto la habilidad de migración ni prometido un lanzamiento público; si quieres probarla, contáctame. Una prueba de caché de plugins mostró que una habilidad de plugin instalado aparece bajo un espacio de nombres de plugin y no con el nombre desnudo de la habilidad, así que la documentación del paquete debe distinguir el uso directo de la habilidad del uso de la habilidad instalada por plugin.⁸

El paquete privado necesita un validador antes de necesitar una historia de lanzamiento. En la pasada más reciente, agregué un validador que revisa el JSON del marketplace, el manifiesto del plugin, el frontmatter de la habilidad, referencias requeridas, sintaxis del verificador de citas, política de instalación, ausencia de manifiestos activos de ganchos o MCP, archivos generados y filtraciones obvias de rutas privadas o fixtures de secretos. Esa verificación debe ir antes de cualquier activación más amplia porque la documentación de plugins de OpenAI convierte el marketplace en la superficie de instalación, no en un espacio de prueba para flujos privados inestables.⁸¹⁰

¿Cómo debe AGENTS.md llevar las reglas de escritura pública?

El cambio más fuerte de la migración a Codex pertenece a AGENTS.md, no a un gancho. La escritura pública necesita una clase de riesgo predeterminada.

Esta es la regla que quiero cerca del inicio del archivo global o de proyecto:

## La escritura pública es trabajo de producto

Los artículos públicos, guías, landing pages, documentos que moldean la comprensión del usuario y copy de producto usan como mínimo el perfil `default`. Promueve a `careful-review` cuando haya afirmaciones, citas, marca, dinero, seguridad, protección o confianza del usuario en juego.

Antes de finalizar escritura pública:
- Reúne citas antes de redactar.
- Cita documentación oficial de producto para el comportamiento actual de herramientas.
- Etiqueta con claridad el análisis del autor.
- Ejecuta un escaneo de frases prohibidas.
- Verifica enlaces internos.
- Reporta cualquier afirmación que no pudo verificarse.

Esa regla corrige la falla que encontré en el inventario del enrutador. Parte del trabajo de contenido se había desviado hacia ejecución rápida porque el enrutador trataba “contenido” como trabajo barato. La escritura pública no es trabajo barato cuando cambia lo que la gente cree, compra, instala o ejecuta. Los borradores de blog, guías y páginas de producto merecen más revisión que las ediciones rutinarias de código porque el modo de falla es la confianza pública, no una prueba local rota.

La publicación que estás leyendo es el ejemplo. Cita documentación actual de Codex para el comportamiento actual de Codex. Etiqueta las afirmaciones de inventario local como análisis del autor. Usa una pila real en lugar de fingir que la migración empieza desde una máquina en blanco, pero mantiene fuera del artículo público los detalles privados de implementación.

¿Cómo deben codificar el riesgo los perfiles de Codex?

La referencia de configuración de OpenAI define profile como el perfil predeterminado al iniciar y admite anulaciones por perfil para claves de configuración admitidas.⁵ La misma referencia define model_reasoning_effort, approval_policy y sandbox_mode como controles explícitos de configuración.⁵

Eso le da a Codex un lugar natural para codificar riesgo.

[profiles.public-writing]
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
web_search = "live"

El modelo exacto puede cambiar. La política no debería. La escritura pública necesita mayor razonamiento, verificación de fuentes en vivo cuando los hechos pueden cambiar, ejecución limitada al workspace y aprobación humana para acciones que salen de la ruta segura de trabajo.

El enrutador debe mapear tareas como estas a public-writing o careful-review:

• Un post de blog, una guía o un cambio de homepage.
• Cualquier artículo con citas.
• Cualquier contenido que compare herramientas o proveedores.
• Cualquier post que nombre Codex actual, Claude Code, OpenAI, Anthropic, Apple, Google u otro producto que cambie rápido.
• Cualquier trabajo que toque schema, llms.txt, SEO, analytics o metadatos públicos.

El perfil no es una vibra. El perfil es un presupuesto de riesgo.

¿Qué ganchos de Codex siguen importando?

Los ganchos de Codex deben hacer cumplir las cosas pequeñas que tienen que ocurrir durante la ejecución.

Un gancho stop de escritura pública podría revisar los archivos cambiados y rechazar completar si un post público en Markdown contiene referencias a notas sin definiciones. Un gancho previo a herramientas podría advertir si el agente intenta editar .env, credenciales de analytics o cachés de traducción generadas mientras escribe un artículo. Un gancho de inicio de sesión podría agregar la fecha actual y recordarle a Codex que las afirmaciones de “lo último” requieren verificación.

Mantén pequeña la carga útil del gancho. OpenAI documenta formas de salida JSON para ganchos, incluidos systemMessage, continue y campos específicos por evento.² Usa esos campos para bloquear o advertir sobre fallas exactas. No reconstruyas toda la red de despachadores de Claude salvo que los datos de falla de Codex prueben que la necesitas.

Las pruebas de configuración no justifican promoción. Un gancho sale de piloto solo después de que una observación de uso real muestre 3 cosas: se activa en las situaciones previstas, deja pasar el trabajo ordinario y registra telemetría agregada segura en lugar de contenido privado. Si ocurre un bloqueo, la razón debe decirle al usuario qué hacer después.²⁸

Después de las primeras pasadas en vivo, el backlog práctico de ganchos se ve así:

1. SessionStart: mantener en piloto contexto compacto de fecha actual, actualidad, proyecto y frontera público/privado.
2. PreToolUse:Bash: mantener en piloto el guard estrecho contra comandos destructivos y lectura de credenciales.
3. PostToolUse:apply_patch: mantener la sombra de calidad no bloqueante sobre líneas de patch cambiadas de código/configuración.
4. Stop: mantener en piloto el umbral de citas para Markdown público cambiado.
5. Stop: mantener el contrato de verificación final plegado dentro del piloto existente de Stop de calidad; no crear un gancho separado de resumen hasta que fallas reales prueben la necesidad.

Ese conjunto porta el comportamiento de seguridad sin importar meses de ceremonia específica de Claude.

¿Cómo deben encajar MCP y las herramientas de navegador?

Mi configuración actual de Codex ya usa una ruta privada de automatización de navegador respaldada por MCP.¹ Codex también admite servidores MCP tanto mediante CLI como con config.toml: codex mcp add puede registrar un servidor stdio, y las tablas [mcp_servers.<server-name>] pueden definir command, args, entorno, URLs, enabled_tools, disabled_tools y tiempos de espera.⁶

Para escritura pública, MCP pertenece a 2 lugares:

• Automatización de navegador para revisar páginas renderizadas en vivo, capturas de pantalla y previews locales.
• Descubrimiento de fuentes o recuperación de documentación cuando un proveedor específico expone un servidor MCP confiable.

MCP no debe ocultar el rastro de fuentes. Un escritor de blog necesita citas que un lector pueda abrir, no un resultado de herramienta privada que solo existió dentro de la sesión. MCP puede ayudar a encontrar el hecho. El post final todavía necesita una fuente pública.

¿Cómo arrancas una migración de Claude Code a Codex?

El primer artefacto nativo de Codex debe describir la migración mientras usa la migración.

Este es el bucle interactivo de arranque:

codex -p careful-review --search \
  "Inventory the local Codex and Claude migration surface, then create a citation bank for a sanitized post about moving the setup to Codex."

codex -p careful-review \
  "Draft content/blog/claude-code-to-codex-migration.md using the local inventory, official Codex docs, and existing internal posts. Label author analysis clearly."

codex -p careful-review \
  "Review the draft for unsupported claims, stale Codex flags, broken internal links, and AGENTS.md operational value."

Para trabajo no interactivo, usa codex exec y convierte la búsqueda en vivo en una preocupación de configuración/perfil en lugar de copiar el flag interactivo --search. OpenAI documenta codex exec para ejecuciones scriptadas o de estilo CI, con anulaciones --profile, --sandbox y --config; mi ayuda local de Codex CLI 0.130.0 confirma esos flags y rechaza codex exec --search.⁷⁸

codex exec -p careful-review -c 'web_search="live"' \
  "Create a citation bank for content/blog/claude-code-to-codex-migration.md from official Codex docs and sanitized local inventory."

codex exec -p careful-review \
  "Review content/blog/claude-code-to-codex-migration.md for unsupported Codex claims, stale flags, broken internal links, and AGENTS.md operational value."

Los detalles de línea de comandos importan. OpenAI marca --full-auto como un flag de compatibilidad obsoleto y recomienda --sandbox workspace-write en su lugar.⁷ Las guías viejas centradas en --full-auto no deben controlar la nueva automatización.

El post se convierte en la prueba de aceptación. Si Codex puede:

• Cargar las habilidades de escritura.
• Usar careful-review.
• Citar documentación actual de OpenAI.
• Usar inventario local sin exponer detalles privados de implementación.
• Explicar qué cambia en AGENTS.md, habilidades, ganchos, perfiles y MCP.
• Producir un artículo Markdown limpio en el repositorio del sitio.

Entonces la migración de escritura funciona.

Lista de verificación de migración de Claude Code a Codex

Para configuración de Codex:

• Agrega o actualiza ~/.codex/AGENTS.md con acuerdos globales de trabajo.
• Agrega reglas de AGENTS.md del repositorio para escritura pública.
• Crea public-writing o enruta la escritura pública a careful-review.
• Haz que careful-review use de verdad razonamiento alto o xhigh para afirmaciones públicas.
• Agrega una regla de enrutador que trate guías, posts de blog, docs y copy de producto como trabajo de superficie pública.

Para habilidades:

• Mueve o duplica habilidades privadas de escritura en $HOME/.agents/skills una por una.
• Mantén los flujos de migración probados activamente como habilidades de usuario antes de tratar un paquete de plugin como ruta de ejecución.
• Usa $skill-name como prueba canónica de invocación explícita; trata /name como envoltorio de conveniencia o hábito de selección, no como prueba de que una habilidad de Codex cargó.
• Agrega un validador de preparación de paquete antes de la activación en marketplace.
• Agrega un umbral de salud del arnés que pruebe referencias de AGENTS, perfiles, habilidades, ganchos, estado del paquete, forma del registro y estado de activación antes de promover.
• Para pilotos de instalación, verifica agregado desde marketplace, lectura/instalación del plugin, listado del plugin, listado de habilidades, visibilidad de habilidad en sesión nueva y limpieza de marketplaces duplicados.
• Mantén las habilidades piloto como solo explícitas antes de permitir activación implícita.
• Mantén los estándares genéricos de escritura separados de la voz específica del sitio.
• Mantén la verificación de fuentes como el umbral factual duro.
• Mantén los checks de detectabilidad para IA separados de la voz del autor.
• Crea una habilidad delgada de escritor específico del sitio en lugar de reutilizar un escritor específico de marca.
• Confirma que Codex descubre habilidades después de cada movimiento.

Para colaboración entre agentes:

• Mantén a Codex como dueño del bucle.
• Ancla las revisiones a archivos reales o artefactos de contexto.
• Falla en cerrado cuando faltan anclajes, la salida está vacía o el segundo agente agota el tiempo.
• Rechaza hallazgos no sustentados de segundos agentes con evidencia local.
• Acepta solo hallazgos fundamentados, aplica la corrección más pequeña, vuelve a ejecutar revisión estática y luego corre verificaciones propiedad de Codex.

Para ganchos:

• Porta primero solo verificaciones deterministas.
• Usa SessionStart, PreToolUse, PostToolUse y Stop para umbrales estrechos.
• Registra fallas antes de agregar más umbrales.
• Para ganchos sombra, registra categorías en lugar de contenido privado crudo.
• Prueba un fixture conocido malo y uno conocido ruidoso antes de promover.
• Separa fallas limpias de deuda de limpieza antes de hacer cumplir una verificación migrada.
• Trata los ganchos como verificaciones de tiempo de ejecución, no como el almacén canónico de doctrina.

Para el flujo de escritura:

• Reúne citas antes de redactar.
• Usa documentación oficial para comportamiento actual de Codex.
• Usa análisis del autor para inventario y experiencia local.
• Enlaza posts internos cuando ya explican un concepto.
• Ejecuta verificación antes de finalizar.
• Para mantenimiento de guías, verifica afirmaciones de fuentes y entorno de ejecución, sincroniza superficies públicas derivadas, regenera archivos de descubrimiento y nombra checks omitidos de traducción, despliegue y producción en vivo.
• Para guías traducidas, registra el proveedor de traducción elegido, lote diferencial o conteo de secciones, estado de credenciales sin valores, si hubo escrituras/subidas, verificación de locale y la razón de no escritura cuando la ejecución esté bloqueada.
• Para higiene de secretos y logs, separa código ejecutable, docs, cachés generadas, transcripciones de sesión, capturas de shell, logs y almacenes intencionales de secretos; redacta historial y convierte helpers a configuración requerida por entorno antes de tratar un flujo migrado como seguro.
• Después de desplegar, verifica la URL canónica, datos estructurados, sitemap, llms-full.txt, estado de despliegue, frescura de CDN y marcadores de contenido cambiado en producción.
• Si una caché CDN sirve contenido obsoleto, purga solo las URLs públicas afectadas mediante la ruta de despliegue existente y luego vuelve a revisar los marcadores cambiados.

FAQ

¿Las habilidades privadas de escritura tienen que ser públicas?

No. Un artículo de migración puede describir la forma del sistema de escritura sin publicar nombres privados de habilidades, instrucciones, detalles de puntuación ni adaptadores específicos de marca. La lección pública es dónde pertenecen esas habilidades y cómo debe activarlas Codex.

La habilidad de migración sigue la misma regla. Hoy es privada, no un paquete de código abierto. Si quieres probar el flujo, contáctame.

¿Una migración de Claude Code a Codex debería reutilizar escritores específicos de marca?

No. Los escritores específicos de marca deben seguir siendo específicos de marca. Un sitio personal o de empresa necesita un adaptador delgado de sitio que comparta estándares de verificación sin heredar la audiencia, los datos ni las llamadas a la acción de otro producto.

¿Debo copiar cada gancho de Claude Code en Codex?

No. Copia comportamiento solo después de identificar el contrato detrás. Un bloqueo de credenciales pertenece a un gancho. Una rúbrica de escritura pertenece a una habilidad. Una regla de riesgo pertenece a un perfil o enrutador. Una filosofía pertenece a AGENTS.md más una habilidad enfocada.

¿Dónde deben vivir las habilidades de Codex?

Para trabajo nuevo nativo de Codex, usa las ubicaciones oficiales de habilidades: .agents/skills del repositorio para habilidades de proyecto y $HOME/.agents/skills para habilidades de usuario.⁴ Si una configuración local existente también usa ~/.codex/skills, mantenla hasta que el descubrimiento de Codex confirme que la nueva ubicación funciona.

¿Por qué las instrucciones /skill a veces fallan en Codex?

Porque /skill no es el contrato canónico de invocación de habilidades de Codex. Las habilidades de Codex se activan cuando seleccionas o mencionas la habilidad explícitamente, incluido $skill-name, o cuando la tarea coincide con la descripción de la habilidad.⁴ Los comandos slash de Codex CLI son su propia superficie de comandos incorporados.¹⁵ Usa $skill-name cuando necesites activación determinista de una habilidad. Mantén /name solo como envoltorio de conveniencia, hábito de selección o frase de instrucción que de todas formas necesita su propia prueba.

¿Cuál es el corazón de una migración de Claude Code a Codex?

El corazón no son los ganchos, las habilidades ni los perfiles por separado. El corazón es la capa de decisión que responde 4 preguntas antes de empezar el trabajo: ¿qué tipo de trabajo llegó, qué perfil de riesgo debe ejecutarlo, qué instrucciones lo gobiernan y qué prueba debe existir antes de completarlo?

Puntos clave

Para usuarios de Codex: Porta contratos, no directorios. AGENTS.md, perfiles, habilidades, MCP y ganchos tienen cada uno un trabajo. Coloca cada regla donde Codex la honre de forma más directa.

Para usuarios de Claude Code que migran: Trata los ganchos de Codex como barandas de seguridad, no como reemplazo completo de un sistema maduro de despachadores de Claude. Empieza con AGENTS.md y habilidades; luego agrega ganchos donde importe la aplicación en tiempo de ejecución.

Para escritores públicos: La escritura de blog pertenece a un perfil de alta revisión. Las afirmaciones actuales necesitan fuentes actuales. Un artículo pulido pero equivocado daña la confianza más rápido que un script local roto.

Para mi propia pila: El sistema privado de escritura ya no solo está portado en sustancia; el primer escritor específico del sitio está preparado como solo explícito, el flujo de migración está activo como habilidad de usuario y el paquete privado de plugin pasó un piloto de instalación local sin convertirse en lanzamiento público. La doctrina de Codex ahora convierte la calidad y el criterio estético en regla operativa. El resumen de verificación final quedó como revisión sombra manual, con su check determinista estrecho plegado dentro del piloto existente de Stop de calidad en lugar de un gancho separado. Un gancho compacto de contexto SessionStart está en piloto, el primer gancho activo de calidad observa cambios de apply_patch en modo sombra, el primer guard de seguridad pre-Bash corre como piloto bloqueante estrecho, el verificador de citas ahora corre como piloto Stop de Markdown público cambiado, las pasadas de mantenimiento de guías probaron el bucle fuente-a-renderizado en docs públicos reales, una pasada corrigió afirmaciones obsoletas de conteos exactos en vez de preservar cifras antiguas del arnés de fuentes, otra detectó una discrepancia entre una ruta generada y una servida de descubrimiento IA, pasadas recientes corrigieron compatibilidad de modelos/parámetros, deriva de benchmarks/model cards, deriva de lanzamientos rápidos de plugins, deriva de datos estructurados FAQ renderizados, deriva de contabilidad de créditos, afirmaciones de API/legales/mínimos de función solo de terceros y deriva de rutas por slug en frontmatter, y las últimas pasadas de la guía de Codex hicieron que la traducción de guías pudiera elegir proveedor, usaron Codex como proveedor predeterminado para trabajo propiedad de Codex, rechazaron salida de traducción truncada antes de escribir caché, completaron escrituras de locales, verificaron rutas de locales y resolvieron respuestas obsoletas de CDN con purga dirigida en vez de depender silenciosamente de una ruta solo de Claude. Una pasada acotada de higiene de secretos/logs separó código fuente, docs, cachés generadas, registros de sesión, capturas de shell, logs y almacenes intencionales de secretos antes de registrar brechas de rotación, redacción y ganchos preventivos. El bucle de lanzamiento ahora trata las verificaciones locales, el estado de despliegue, la frescura de CDN y la prueba en vivo de marcadores cambiados como umbrales separados. Una pasada de inteligencia de fuentes probó disciplina de simulación/volumen de escritura antes de escribir en memoria privada, la ruta de incorporación de blogs de empresa ahora se detiene antes de generar archivos salvo que destino/ruta/evidencia de intake sean explícitos, el traductor de blog ahora se detiene antes de ejecutar escrituras cuando faltan credenciales D1 o un destino explícito y rechaza salida de Codex con demasiado residuo antes de publicar cuando las credenciales están presentes, un bucle de colaboración entre agentes probó revisión/corrección/reverificación sin entregar autoridad al segundo agente y un umbral manual de salud del arnés revisa la superficie determinista de promoción antes de cualquier activación más amplia. El siguiente trabajo es seguir probando los rituales de producción que aún son solo explícitos, mantener estacionada la frontera de lanzamiento público y seguir pasando trabajo real de escritura pública e ingeniería por los carriles preparados antes de ampliar cualquier umbral.

Referencias