Claude Code y Codex en el Mismo Repositorio: Mi Configuración Real

Claude Code y Codex en el Mismo Repositorio: Mi Configuración Real

Solía ser un fiel seguidor de Claude Code. No de forma tribal — más bien en plan "este es el agente en el que confío, el que he afinado, con el que ya tengo la memoria muscular". Anthropic lanzaba una actualización, yo la instalaba. Anthropic tenía una caída, yo esperaba. La idea de ejecutar un segundo CLI en paralelo se sentía como traicionar una herramienta que se había ganado mi flujo de trabajo.

Entonces, el mes pasado, un miércoles por la tarde, la página de estado de la API de Claude pasó a naranja. Luego a rojo. Aria — mi agente de contenido — estaba a mitad de un lote de cuatro publicaciones. Me quedé ahí sentado 47 minutos viendo girar el spinner. Para cuando la API volvió, había perdido la mañana y la paciencia para seguir siendo un ingeniero de un solo CLI.

Así que hice lo que venía evitando. Abrí un segundo panel de terminal, ejecuté codex en el mismo repositorio, y empecé a enseñarme a mí mismo cómo vivir realmente en ambos ecosistemas a la vez. No la versión de marketing donde "comparas" las dos herramientas y eliges un ganador. La versión aburrida y granular donde ejecutas ambas, en la misma base de código, con el mismo contexto de proyecto, con skills que funcionan mayormente en cualquiera de los dos CLIs, y un truco de traspaso de sesión que te permite pasar trabajo entre ellos cuando uno se queda atascado.

De eso trata este artículo. No "Claude Code vs Codex." Es "Claude Code y Codex, en la misma carpeta de proyecto, con un cerebro compartido y un skill de traspaso que sobrevive a las caídas." Llevo ejecutando esta configuración unas seis semanas. Las primeras tres semanas fueron difíciles. Las últimas tres han sido el entorno de desarrollo más resiliente que he tenido jamás.

Déjame guiarte exactamente por cómo está conectado.

Por Qué Dejé de Elegir Bandos Entre Claude Code y Codex

Antes de la configuración, una breve reflexión sobre el cambio de mentalidad — porque el cableado solo importa si la filosofía subyacente es correcta.

Durante la mayor parte de 2025, la conversación sobre agentes CLI fue tribal. Eras una persona de Claude Code, o de Codex, o de Cursor, o de Gemini CLI. Las razones eran reales: cada herramienta tenía una ergonomía diferente, un comportamiento de modelo diferente, archivos de configuración diferentes, y cambiar costaba tiempo real. Elegir una y profundizar tenía sentido.

Dos cosas cambiaron para mí en 2026.

Lo primero fueron las caídas. No es culpa de Anthropic específicamente — todos los principales proveedores de modelos han tenido al menos un día complicado este año. OpenAI tuvo un incidente de varias horas en febrero. Anthropic tuvo el tartamudeo de API que mencioné arriba. El lado de Gemini de Google tuvo un bug de enrutamiento de modelos en marzo que degradó silenciosamente las respuestas durante horas antes de que nadie lo notara. Si todo tu flujo de trabajo depende de un solo proveedor, una caída se lleva todo tu día. Eso no es un problema de tecnología — es un problema de punto único de fallo.

Lo segundo fue el estancamiento. A veces Claude Code se queda atascado. No "roto" — creativamente atascado. Elige un enfoque, avanza con él, y cuando ese enfoque no funciona, sigue refinando el mismo enfoque con más fuerza. He visto a Opus pasar 40 minutos intentando hacer fiable un test inestable añadiendo reintentos cuando la solución real era reescribir el test con un estilo diferente. Un segundo agente — no como reemplazo, sino como una segunda opinión — generalmente rompe el estancamiento en un solo prompt. Cambiar de CLI es la forma más barata que he encontrado para obtener una perspectiva fresca del modelo sin perder el contexto del proyecto.

Así que el objetivo no es "elegir el mejor CLI." El objetivo es el agnosticismo de herramientas: construir una configuración donde Claude Code y Codex puedan trabajar en la misma base de código, con el mismo conocimiento del proyecto, y puedas moverte entre ellos sin perder tu posición. El CLI se vuelve intercambiable. El contexto del proyecto es lo sagrado. Este es el mismo instinto sobre el que escribí en mi flujo de trabajo de dos agentes supervisor-constructor, llevado más lejos: no solo dos agentes, sino dos CLIs completos tratados como intercambiables.

Ahora, el cableado.

El Cerebro Compartido: CLAUDE.md y AGENTS.md Contienen (Casi) lo Mismo

Lo primero que aprendí cuando empecé seriamente a ejecutar ambos agentes en el mismo repositorio es esto: los dos ecosistemas ya coinciden más de lo que el marketing sugiere. Tanto Claude Code como Codex leen un archivo markdown a nivel de proyecto al iniciar. Claude Code lee CLAUDE.md. Codex lee AGENTS.md. Los contenidos son casi intercambiables. El formato es markdown plano. La intención es la misma: decirle al agente qué es este proyecto, cuáles son las convenciones, qué herramientas usar, qué tests ejecutar, y qué no tocar.

Cuando configuré por primera vez el flujo de trabajo en paralelo, cometí el error de novato de escribir dos archivos separados y mantenerlos sincronizados a mano. Eso duró unos cuatro días antes de que la deriva hiciera que los agentes discreparan en cosas básicas — Codex pensaba que estábamos usando pnpm, Claude Code pensaba que estábamos usando npm, y el azar determinaba cuál tenía razón en cada momento.

La solución es uno de dos patrones, y ambos funcionan:

Patrón A — Enlace simbólico de uno al otro. Elige el archivo que quieras como fuente de verdad (yo elegí AGENTS.md porque se está convirtiendo en el estándar multi-proveedor) y enlaza simbólicamente el otro:

# desde la raíz del proyecto, con AGENTS.md como canónico
mv CLAUDE.md AGENTS.md   # si empiezas desde CLAUDE.md
ln -s AGENTS.md CLAUDE.md

Ahora ambos agentes leen el mismo archivo. Edita AGENTS.md, ambos CLIs ven la actualización en el siguiente inicio. Esto es lo que recomienda la guía de migración de Onur Solmaz y lo que yo uso en la mayoría de mis repositorios.

Patrón B — Mantenerlos separados pero forzar la sincronización. Si quieres que cada archivo tenga unas pocas líneas específicas de la herramienta (algunos skills se comportan diferente en uno vs el otro), mantén ambos archivos y escribe un hook de pre-commit que compare la sección compartida y avise si se han desviado. Esto es más pesado, pero te permite tener un bloque # Específico de Claude Code al final de uno y no del otro.

Empecé con el Patrón B y migré todo al Patrón A en dos semanas. El costo de mantenimiento de mantener dos archivos sincronizados era mayor que el valor de tener unas pocas líneas específicas por herramienta.

Cualquiera que sea el patrón que elijas, esto es lo que debería vivir realmente en ese archivo compartido. Esta es la sección de mi AGENTS.md real para el repositorio donde escribo todo este contenido:

# Project: my-ai-crew

## What this is
Multi-brand content generation system. Four brands, each with a distinct
voice. Posts are saved to content/{brand}/[slug].md. No build system,
no tests — the workflow is agent-driven.

## Conventions
- All article files start with `**BRAND:**` — never YAML frontmatter.
- META DESCRIPTION must be 150-160 characters. Count before saving.
- Word count floor: 3,000.
- Brand voices are defined in .claude/agents/aria.md (do not edit
  without explicit instruction).

## Tools available
- WebSearch — use for fact verification, never guess versions/pricing
- Glob — scan content/{brand}/*.md before writing
- Read, Write, Edit — standard file ops

## What NOT to do
- Don't run git commit unless explicitly asked.
- Don't add Co-Authored-By lines without instruction.
- Don't generate placeholder metrics — use real numbers or omit.

## Brand directories
- content/mejba.me/ — personal practitioner voice
- content/ramlit.com/ — agency, business-focused
- content/colorpark.io/ — design agency, opinionated
- content/xcybersecurity.io/ — security, authoritative

Ambos CLIs leen esto. Ambos agentes ahora conocen las convenciones. La primera vez que escribes este archivo correctamente es la primera vez que tu configuración de dos CLIs se siente coherente en lugar de esquizofrénica.

Hay una sutileza que vale la pena señalar. Claude Code soporta archivos CLAUDE.md anidados en subdirectorios — cuando el agente lee un archivo en content/colorpark.io/, puede recoger instrucciones adicionales de un CLAUDE.md colocado en esa subcarpeta. Codex tiene un mecanismo similar: cuando haces cd a un subdirectorio, concatena los archivos AGENTS.md desde la carpeta actual hasta la raíz del repositorio, con los archivos más cercanos sobreescribiendo a los anteriores (esto está documentado en la guía de AGENTS.md de Codex). Si enlazas simbólicamente en la raíz, también puedes hacerlo a nivel de subcarpeta. Ambos ecosistemas se llevarán bien.

El Mapa de Archivos y Carpetas: Dónde Busca Cada CLI

Una vez que el cerebro compartido está conectado, la siguiente pregunta es: ¿dónde vive todo lo demás? Skills, agentes, configuración, comandos slash. Ambos CLIs tienen su propia estructura de carpetas, y necesitas un mapa mental.

Este es el que mantengo fijado en mis propias notas:

Algunas observaciones sobre esta tabla porque me tropecé la primera vez:

El formato de configuración es la mayor diferencia de formato. Claude Code usa JSON para settings.json. Codex usa TOML para config.toml. Si nunca has escrito TOML, está a medio camino entre YAML e INI — claves, valores, secciones entre corchetes. No es difícil, pero no puedes pegar tu settings.json en config.toml y esperar que nada funcione. La conversión es mecánica pero manual. (O, como mostraré en un momento, le pides a Claude Code que lo haga por ti.)

Los comandos slash y los skills están convergiendo en Codex. La documentación oficial de OpenAI ahora dice que los prompts personalizados están deprecados en favor de los skills. Así que en 2026, si estás escribiendo instrucciones reutilizables para Codex, las escribes como skills, no como prompts personalizados. Claude Code todavía distingue entre comandos (en .claude/commands/) y skills (en .claude/skills/), pero la brecha se está cerrando. Ambos ecosistemas están llegando a "un skill es un archivo markdown con frontmatter que describe cuándo debe activarse." Buenas noticias para la portabilidad.

Los sub-agentes divergen más de lo esperado. Los sub-agentes de Claude Code se despachan automáticamente — el agente principal lee las descripciones de cada archivo .claude/agents/*.md al iniciar, y enruta el trabajo hacia ellos cuando una tarea coincide. Codex requiere invocación explícita. Puedes construir agentes en .codex/agents/, pero Codex no los enruta automáticamente; tú le dices a Codex qué agente usar. Volveré a esta diferencia porque es lo que más cambia cómo trabajas.

Los Skills Son Mayormente Portables. Los Agentes Necesitan una Conversión.

La razón por la que toda esta configuración funciona es que la mayoría de los archivos markdown en .claude/ y .codex/ son estructuralmente iguales. Un skill es una carpeta con un SKILL.md dentro. El SKILL.md tiene frontmatter YAML con name y description, luego un cuerpo markdown con instrucciones. Esa especificación es la misma en ambos lados. Lo que significa que un skill que escribí para Claude Code se traslada a Codex sin cambios la mayoría de las veces.

Lo probé directamente. Mi skill caveman — el modo de comunicación ultra-comprimido que reduce el uso de tokens en ~75% (escribí sobre construir el skill caveman para Claude Code hace un tiempo) — fue escrito originalmente para Claude Code. Copié la carpeta caveman/ de .claude/skills/ a .codex/skills/, reinicié Codex, y el skill se activó correctamente en el primer prompt. Sin cambios de formato. Sin reescrituras de frontmatter. Simplemente funcionó.

Los skills que no se portan limpiamente son los que hacen referencia a nombres de herramientas específicos de Claude Code. Si tu skill dice "usa la herramienta Glob" — Codex no tiene una herramienta llamada Glob. Tiene acceso al shell, así que el agente aún puede buscar archivos con glob vía find o ls, pero tendrás que reescribir el skill para referenciar operaciones de shell o aceptar que el skill funcionará menos fiablemente. Alrededor del 80% de los skills que he migrado no necesitaron cambios. El otro 20% necesitó ediciones ligeras en las referencias de herramientas.

Los sub-agentes son donde la conversión se pone seria. El frontmatter es similar (name, description, model, tools) pero el modelo de despacho es diferente — y eso cambia cómo escribes el cuerpo del agente. Un agente de Claude Code se escribe asumiendo que será auto-invocado cuando una tarea coincida con su descripción. Un agente de Codex se escribe asumiendo que tú lo invocarás explícitamente. Entonces:

• Las descripciones de agentes de Claude Code están escritas para que las lea el modelo despachador. Dicen "usa este agente cuando se necesite X" porque el agente principal necesita saber cuándo delegar.
• Las descripciones de agentes de Codex están escritas para que las lea el usuario humano. Dicen "este agente maneja X" porque el humano es quien enruta el trabajo.

Cuando migras un agente de uno al otro, no solo copias el archivo. Reescribes la descripción desde la perspectiva correcta. El cuerpo — el system prompt real — generalmente se transfiere sin cambios.

Esta es la mayor diferencia práctica entre los dos ecosistemas, y es la razón por la que ejecuto ambos en paralelo en lugar de tratarlos como reemplazos directos. Claude Code es mejor en orquestación multi-agente porque el despacho es automático — cubrí la mecánica de despacho en detalle en mi guía de equipos de agentes de Claude Code. Codex es mejor en uso controlado y determinístico de agentes porque tú decides qué agente se ejecuta. Diferentes fortalezas, mismos bloques de construcción.

El Prompt de Conversión que Pego en Claude Code para Inicializar Codex

Cuando empiezo un nuevo repositorio y quiero ambos CLIs listos desde el primer día, no convierto nada manualmente. Escribo la configuración de Claude Code primero (porque ahí está la memoria muscular) y luego pego este prompt en Claude Code y dejo que genere el equivalente de Codex.

Este es el prompt real. Cópialo, pégalo en Claude Code, y hará la conversión por ti:

I want this repo to work in both Claude Code and Codex CLI side by side.
Right now the Claude Code setup is complete. I need you to generate the
parallel Codex setup. Specifically:

1. Read CLAUDE.md and create AGENTS.md with the same content, then
   replace CLAUDE.md with a symlink to AGENTS.md. Use:
     mv CLAUDE.md CLAUDE.md.bak
     # copy CLAUDE.md.bak contents into AGENTS.md
     ln -s AGENTS.md CLAUDE.md
     rm CLAUDE.md.bak  (only after verifying the symlink works)

2. Read .claude/settings.json and create .codex/config.toml that mirrors
   the relevant settings. Convert JSON syntax to TOML. Skip any
   Claude-Code-specific keys that have no Codex equivalent (e.g.
   permissions, hooks) and add a comment listing what was skipped.

3. For each file in .claude/skills/<name>/SKILL.md, create
   .codex/skills/<name>/SKILL.md by copying the file. Check the body
   for any references to Claude-Code-specific tools (Glob, Read tool,
   etc) and either rewrite them as shell equivalents or flag them in a
   comment at the top of the file.

4. For each file in .claude/agents/<name>.md, do NOT auto-port to
   .codex/agents/. Instead, list the agents and ask me which ones I
   want available in Codex. For the ones I select, rewrite the
   description field to be human-routing-friendly (Codex requires
   explicit invocation, not auto-dispatch) and copy the body unchanged.

5. After all conversions, write a CONVERSION_LOG.md at the repo root
   that lists every file created or modified, every skipped key, and
   every tool reference that was rewritten. I want to be able to audit
   this in 30 seconds.

Do not commit anything. Just create the files and the log.

La primera vez que ejecuté esto, Claude Code tardó unos cuatro minutos. La mayor parte fue el agente leyendo cada skill y decidiendo si cada uno tenía referencias de herramientas específicas de Claude Code. El log de conversión fue útil porque detectó dos skills que referenciaban la herramienta Glob por nombre — los reescribí para usar find del shell en su lugar, y ahora ambas versiones del skill funcionan en sus respectivos CLIs sin más cambios.

También puedes ejecutar la conversión inversa, yendo de una configuración de Codex a una de Claude Code. El prompt es simétrico — solo invierte el origen y el destino. Normalmente tengo una dirección de conversión como el pipeline canónico de configuración y la otra como un bootstrap de una sola vez.

El Skill de Traspaso de Sesión: Moviendo Contexto Entre Agentes

Aquí está la parte de la que nadie habla: incluso con un AGENTS.md compartido, los agentes en sí no comparten estado de conversación. Cuando cambias de Claude Code a Codex a mitad de tarea, el nuevo agente no sabe qué estabas haciendo. Conoce las convenciones del proyecto, pero no la intención activa.

Este es el momento donde la mayoría abandona la configuración de CLI en paralelo. Lo prueban un día, chocan con un muro de contexto al cambiar de herramienta, y concluyen que ejecutar ambos "no vale la pena." No es así — pero solo si tienes un traspaso deliberado.

Construí un skill que resuelve esto. Captura las cuatro cosas que realmente importan al traspasar trabajo entre agentes: los archivos activos que has estado tocando, la intención actual (qué estás intentando hacer), los bloqueadores (qué está atascado o falló), y el siguiente paso (qué debería hacer primero el agente receptor). Escribe esos cuatro campos en un archivo .handoff.md en la raíz del repositorio. El agente receptor lee ese archivo en el siguiente prompt y sabe exactamente dónde continuar.

Este es el skill real, que vive en .claude/skills/session-handoff/SKILL.md:

---
name: session-handoff
description: Capture the active session state into .handoff.md so another CLI agent (Codex, Gemini, etc.) can pick up the work. Use when the user says "handoff", "pass to codex", "switch agents", or "context for next agent".
allowed-tools: Read, Write, Bash
---

# Session Handoff

When this skill fires, write `.handoff.md` at the repo root with these
exact four sections. Be terse. The receiving agent reads this and
needs to act on it immediately.

## Format

```markdown
# Session Handoff — [ISO timestamp]
From: [claude-code | codex | other]

## Active files
- [path/to/file:line-range] — [one-line reason]
- [path/to/file] — [one-line reason]

## Current intent
[1-3 sentences: what we're trying to accomplish in this work session]

## Blockers
- [Specific thing that's stuck. Include error message if any.]
- [Or "none" if not stuck — just switching for fresh perspective.]

## Next step
[Exactly one sentence. The single action the receiving agent should
take first.]

Rules

• Do NOT include full file contents. Just paths and line ranges.
• Do NOT summarize the conversation. Capture state, not history.
• If .handoff.md already exists, overwrite it (no append).
• After writing, print "Handoff written to .handoff.md" and exit.
• The receiving agent should be told (by the human) to read .handoff.md as their first action.

El skill espejo en `.codex/skills/session-handoff/SKILL.md` es idéntico excepto por un cambio — la descripción está reescrita porque Codex no despacha automáticamente. La versión de Codex dice algo más como una pista de uso que una señal de enrutamiento. La diferencia en texto plano: la descripción de Claude Code dice "activa esto cuando el usuario diga X." La de Codex dice "usa este skill para escribir un archivo de traspaso."

Para activar un traspaso en Claude Code, simplemente escribo "handoff to codex" — el skill detecta la palabra clave y escribe el archivo. Para activarlo en Codex, escribo `$session-handoff` (la sintaxis de invocación explícita de Codex) y hace lo mismo. Luego cambio de pestaña, y lo primero que le digo al agente receptor es: "Lee .handoff.md y continúa."

El archivo de traspaso suele tener entre 15 y 30 líneas. El agente receptor lo lee, tiene contexto completo en cinco segundos, y empieza a trabajar. He usado este skill probablemente 200 veces en las últimas seis semanas. Es la pieza de pegamento individual que hace que la configuración de CLI en paralelo se sienta coherente en lugar de fragmentada.

Si solo construyes una cosa de todo este artículo, construye este skill. Es pequeño. Ahorra horas. Si nunca has construido un skill de Claude Code desde cero, mi [guía de skills avanzados de Claude Code](https://www.mejba.me/blog/agent-skills-advanced-claude-code) explica el formato y las trampas.

## Cómo Se Ve el Lado a Lado en la Práctica: Panel Dividido en VS Code

El cableado anterior es la configuración estática. Aquí está la dinámica — cómo se ve realmente mi pantalla durante una sesión de trabajo.

VS Code, panel de terminal dividido, orientación vertical. Panel izquierdo: Claude Code, ejecutando Opus 4.7, en la raíz del proyecto. Panel derecho: Codex CLI, ejecutando GPT-5.4, misma raíz de proyecto. Ambos agentes tienen el mismo `AGENTS.md`. Ambos tienen acceso a los mismos skills. Ambos pueden editar los mismos archivos (se coordinan a través del sistema de archivos, no a través de ninguna mensajería entre CLIs — git es la fuente de verdad sobre el estado del disco).

Por defecto uso Claude Code al inicio de cualquier sesión. Es el agente que más he afinado, y tiene mi conjunto completo de sub-agentes de `.claude/agents/` disponibles. Planifico, estructuro y hago el primer 60% de los cambios ahí.

Cambio a Codex en escenarios específicos:

**Claude Code se queda atascado en un enfoque.** Cuarenta minutos después, está dando vueltas con la misma idea. Ejecuto el skill de traspaso, cambio a Codex, y le pido que mire el mismo problema con ojos frescos. Alrededor del 70% de las veces, Codex elige un ángulo diferente y desbloquea el trabajo. El 30% restante, coincide con el enfoque de Claude Code pero sugiere un ajuste específico que lo hace funcionar. De cualquier manera, el estancamiento se rompe.

**Trabajo de refactorización largo y mecánico.** El rendimiento de Codex CLI en tareas basadas en terminal es genuinamente superior al de Claude Code en tareas rutinarias pesadas en shell, según la [comparativa de DeployHQ 2026](https://www.deployhq.com/blog/comparing-claude-code-openai-codex-and-google-gemini-cli-which-ai-coding-assistant-is-right-for-your-deployment-workflow) (Codex CLI alcanzó un 77.3% en Terminal-Bench 2.0 vs el 65.4% de Claude Code). Cuando la tarea es "renombrar 30 variables en 12 archivos siguiendo este patrón" o "ejecutar la suite de tests, analizar los fallos, escribir correcciones," Codex es más rápido y usa menos tokens.

**La API de Claude está caída.** Esta es la razón original por la que construí la configuración en paralelo. Cuando Anthropic tiene un incidente, cambio completamente al panel de Codex y sigo trabajando. Los skills se transfieren. El contexto del proyecto se transfiere. Lo único que pierdo es el agente Aria (porque Aria tiene comportamiento de sub-agente específico de Claude Code que no se traduce completamente), y normalmente no estaba usando Aria para el trabajo que traslado a Codex de todas formas.

**Revisión adversarial.** Cuando quiero una revisión de código que *no* sea del mismo modelo que escribió el código, hago el trabajo en Claude Code, luego le pido a Codex que revise el diff. Linaje de modelo diferente, datos de entrenamiento diferentes, puntos ciegos diferentes. Detecto bugs de esta manera que ningún agente encuentra cuando revisa su propio trabajo. Escribí sobre este patrón extensamente en [el artículo de revisión adversarial con plugin de Codex](https://www.mejba.me/blog/codex-plugin-claude-code-adversarial-review) — misma idea, integración más estrecha cuando la quieres.

El patrón que emergió después de unas semanas: Claude Code es mi principal, Codex es mi paralelo. Estoy en Claude Code el 70-80% del tiempo. Codex es el 20-30%, más el 100% cuando Claude está caído.

## Manteniendo las Dos Configuraciones Sincronizadas (La Disciplina)

Todo el sistema se rompe si las dos configuraciones divergen. El modo de fallo más común que veo — incluyendo en mi propia configuración, cuando me pongo perezoso — es que editas `CLAUDE.md` (que ahora es el enlace simbólico) y accidentalmente escribes cambios que solo Claude Code entiende. O añades un nuevo skill a `.claude/skills/` y te olvidas de replicarlo en `.codex/skills/`. Dos semanas después, cambias de CLI y descubres que la mitad de tus herramientas faltan.

La disciplina que realmente me funciona, después de varias iteraciones:

**Las ediciones al archivo canónico siempre se consideran "agnósticas de herramienta" por defecto.** Si estoy escribiendo algo en `AGENTS.md` que solo un CLI debería saber, lo pongo en una sección claramente marcada al final: bloques `# Solo Claude Code` y `# Solo Codex`. Ambos CLIs leen todo el archivo, pero los encabezados de sección me dicen (al humano) qué líneas aplican dónde. Reduce mucho el trabajo de mantenimiento.

**Los cambios en skills pasan por un script de sincronización.** Tengo un pequeño script de shell que copia archivos nuevos o modificados de `.claude/skills/` a `.codex/skills/` (y viceversa), preservando cualquier sobreescritura de nombres de herramientas que ya haya hecho. Lo ejecuto manualmente después de editar cualquier skill, antes de la siguiente sesión. Cinco segundos de trabajo, previene la deriva lenta.

**Los cambios en sub-agentes no se sincronizan automáticamente.** Dejo los agentes en `.claude/agents/` para uso de Claude Code, y solo porto manualmente los que quiero activamente en Codex. La mayoría de mis agentes son exclusivos de Claude Code porque el comportamiento de despacho automático es todo el sentido de tenerlos. Los dos o tres que sí porto a Codex, los mantengo sincronizados manualmente porque las descripciones necesitan ser diferentes de todas formas.

**Los archivos de configuración (`settings.json` y `config.toml`) nunca se sincronizan automáticamente.** Divergen naturalmente porque exponen configuraciones diferentes. Los trato como independientes, y reviso cada uno una vez al mes para asegurarme de que no he introducido una discrepancia de comportamiento no intencionada.

Esa es la carga operativa, honestamente. Unos diez minutos a la semana de trabajo de sincronización explícito. A cambio, tengo dos CLIs que ambos conocen mi proyecto y ambos pueden trabajar en él de forma intercambiable.

## Cuándo la Configuración en Paralelo No Vale la Pena

Estaría mintiendo si dijera que esta configuración es adecuada para todos.

Si eres nuevo en Claude Code, no hagas esto todavía. Afina Claude Code primero. Escribe bien tu `CLAUDE.md`, construye un puñado de skills, acostúmbrate a cómo funcionan los sub-agentes. Añadir Codex el primer día significa que estás aprendiendo dos CLIs a la vez, y te confundirás sobre qué comportamiento viene de qué herramienta. Elige uno, profundiza, luego añade el otro.

Si tu trabajo está mayormente dentro de las herramientas de un ecosistema — uso intensivo de Claude Skills, muchos servidores MCP conectados específicamente a Claude, sub-agentes que dependen del despacho automático — la configuración en paralelo podría no compensar. La capa portable es más pequeña para ti que para alguien que usa ambas herramientas principalmente a través de skills en markdown plano.

Si eres un desarrollador individual lanzando un proyecto secundario los fines de semana, el argumento de resiliencia importa menos. Una caída te cuesta la tarde del sábado. Molesto, no catastrófico. La configuración en paralelo compensa más cuando tu sustento depende de que el agente funcione — cuando una caída significa que el trabajo del cliente no se entrega.

Y si eres sensible a los costos, ejecutar dos CLIs significa que tienes suscripciones o acceso API a dos proveedores. Yo ejecuto ambos con planes Pro, lo que cuesta más al mes que ejecutar uno. Vale la pena para mí porque el valor de resiliencia es alto. Probablemente no vale la pena para alguien cuyo uso es ligero.

## La Verdadera Ganancia: Resiliencia y Perspectiva Fresca

La configuración vale el esfuerzo por dos razones que son fáciles de subestimar hasta que has vivido sin ellas.

Primero, resiliencia. En las seis semanas desde que ejecuto ambos CLIs, he enfrentado dos incidentes separados de Anthropic y un bug extendido de actualización del CLI de Claude Code. En los tres casos, perdí aproximadamente cero tiempo de trabajo, porque cambié a Codex en cinco minutos y seguí adelante. Comparado con los días pre-configuración, donde una mala tarde podía costarme un entregable completo de cliente, la inversión en CLI paralelo se amortizó en el primer incidente.

Segundo, perspectiva fresca. Incluso en días cuando ningún agente está roto, cambiar de CLI a mitad de tarea es la herramienta de creatividad más barata que he usado jamás. Linaje de modelo diferente. RLHF diferente. Diferente énfasis en datos de entrenamiento. El mismo prompt, enviado a Claude Code y a Codex, a veces produce soluciones con enfoques radicalmente diferentes. He adoptado la costumbre de ejecutar deliberadamente ambos en el mismo problema difícil y combinar las mejores ideas. Es como tener dos ingenieros senior en la misma tarea, excepto que uno de ellos cuesta casi nada extra y nunca se cansa.

La mentalidad agnóstica de herramientas es el verdadero cambio. El CLI es intercambiable. El conocimiento del proyecto es lo que importa. Trata `AGENTS.md` (o cualquier archivo de instrucciones compartido que tengas) como el archivo más importante de tu repositorio. Trata los skills como activos portables, no como scripts específicos de herramienta. Trata los sub-agentes como lo que cada CLI hace a su manera, y no intentes forzarlos a ser idénticos entre proveedores.

Si Anthropic lanzara un competidor de Codex mañana, mi flujo de trabajo lo absorbería en una tarde. Si OpenAI lanzara algo que hiciera obsoleto a Claude Code, lo mismo. Los agentes van y vienen. El conocimiento del proyecto permanece.

Esa es la ganancia.

## Preguntas Frecuentes

### ¿Pueden Claude Code y Codex editar los mismos archivos al mismo tiempo?
Sí, ambos CLIs pueden editar archivos en el mismo proyecto simultáneamente, pero no se coordinan a nivel de memoria — se coordinan a través del sistema de archivos. Si ambos agentes tocan el mismo archivo en el mismo minuto, tendrás un problema de lectura obsoleta. Regla práctica: ejecútalos en paralelo en archivos diferentes, o traspasa explícitamente usando el skill de session-handoff descrito arriba.

### ¿Necesito pagar por Claude Code y Codex por separado?
Sí. Claude Code es el CLI de Anthropic y usa la facturación de Anthropic (plan Pro o API). Codex es el CLI de OpenAI y usa la facturación de OpenAI (ChatGPT Plus/Pro o API). No hay una suscripción compartida. El costo de ejecutar ambos es aproximadamente el doble del costo de ejecutar uno, pero la resiliencia y la perspectiva fresca lo hacen valer para profesionales en activo.

### ¿Cuál es la diferencia real entre CLAUDE.md y AGENTS.md?
Funcionalmente, ninguna — ambos son archivos markdown planos que el agente lee al iniciar para aprender las convenciones del proyecto. La diferencia es qué CLI lee cuál por defecto. AGENTS.md se está convirtiendo en el estándar multi-proveedor, soportado por Codex y otros, mientras que CLAUDE.md es el nombre nativo de Claude Code. La configuración más limpia es mantener AGENTS.md como el archivo real y crear un enlace simbólico de CLAUDE.md hacia él.

### ¿Funcionarán mis skills de Claude Code en Codex sin cambios?
La mayoría, sí. Ambos ecosistemas usan el mismo formato SKILL.md (frontmatter YAML con name/description, cuerpo markdown). Los skills que necesitan edición son los que referencian nombres de herramientas específicos de Claude Code como Glob o servidores MCP específicos que no están instalados en tu configuración de Codex. Aproximadamente el 80% se porta sin cambios en mi experiencia; el otro 20% necesita 5-10 líneas de ediciones.

### ¿Tiene Codex sub-agentes como Claude Code?
Codex ahora soporta skills (el reemplazo moderno de los prompts personalizados) y sub-agentes vía `.codex/agents/`, pero el modelo de despacho es diferente: Codex requiere que invoques explícitamente un sub-agente, mientras que Claude Code despacha automáticamente basándose en que la descripción del agente coincida con la tarea. Si dependes del enrutamiento automático entre muchos sub-agentes, Claude Code sigue siendo el orquestador más fuerte. Si prefieres control determinístico sobre qué agente se ejecuta, el modelo de invocación explícita de Codex es más limpio.

## Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

* **Fiverr** (desarrollos personalizados e integraciones): [fiverr.com/s/EgxYmWD](https://www.fiverr.com/s/EgxYmWD)
* **Portfolio**: [mejba.me](https://www.mejba.me)
* **Ramlit Limited** (soluciones empresariales): [ramlit.com](https://www.ramlit.com)
* **ColorPark** (diseño y branding): [colorpark.io](https://www.colorpark.io)
* **xCyberSecurity** (servicios de seguridad): [xcybersecurity.io](https://www.xcybersecurity.io)