Claude Code vs Codex CLI 2026: Referencia para decidir

Uso Claude Code como mi herramienta de desarrollo principal. Vale la pena dejarlo claro desde el inicio, porque la mejor escritura comparativa surge de conocer una herramienta a fondo y probar la otra con honestidad. Tras 36 duelos a ciegas (en los que ejecuté tareas idénticas en ambas herramientas y puntué los resultados sin saber cuál los había producido ¹) y cientos de sesiones con ambas, he descubierto que la respuesta a “¿cuál es mejor?” es, genuinamente, “depende de la tarea”.

Claude Code es mejor para refactorizaciones profundas, revisión de código y gobernanza programable a través de su sistema de hooks de ciclo de vida; Codex CLI es mejor para sandboxing a nivel de kernel y portabilidad entre herramientas mediante AGENTS.md. Claude Code aplica la seguridad en la capa de aplicación con más de dos docenas de eventos de hooks que tú mismo conectas, mientras que Codex la aplica en la capa del kernel del sistema operativo, donde el modelo no puede eludir las restricciones. Elige Claude Code para razonamiento complejo entre múltiples archivos y los flujos de trabajo personalizables más profundos. Elige Codex para aislamiento máximo e instrucciones de agente estandarizadas que funcionan en 8+ herramientas.

Actualizado a 5 de junio de 2026. Ambas herramientas publican versiones cada semana, así que los datos aquí tienen una vida útil limitada. A fecha de esta revisión, Claude Code usa por defecto Opus 4.8 (CLI v2.1.165) y Codex usa por defecto GPT-5.5 (CLI v0.137.0). El mayor cambio desde la primavera: Codex lanzó un verdadero sistema de hooks de ciclo de vida, reduciendo lo que antes era la ventaja más clara de Claude Code. Consulta Dónde gana cada herramienta para ver qué cambia y qué no.

TL;DR

Claude Code y Codex CLI resuelven el mismo problema (desarrollo asistido por IA) con arquitecturas fundamentalmente distintas. Claude Code gobierna principalmente mediante hooks: más de dos docenas de tipos de eventos de ciclo de vida que aplican políticas de forma determinista en la capa de aplicación ². Codex gobierna principalmente mediante sandboxing: restricciones del kernel del sistema operativo por debajo de la capa de aplicación ³, ahora acompañadas de sus propios hooks de ciclo de vida. Ninguno de los dos enfoques es estrictamente superior.

Claude Code superó a Codex de forma consistente en revisión de código y verificación de seguridad en las pruebas a ciegas. Codex ofrece ventajas genuinas en sandboxing, portabilidad entre herramientas vía AGENTS.md y delegación de tareas a la nube.

Decisión rápida: ¿Necesitas sandboxing a nivel de kernel o un AGENTS.md multiherramienta? → Codex. ¿Necesitas los hooks de gobernanza programables más maduros o refactorización profunda? → Claude Code. ¿Necesitas ambos modelos de seguridad? → Usa las dos.

¿Nuevo en ambas? Empieza primero por la guía de Claude Code o la guía de Codex. Este artículo asume familiaridad con al menos una de ellas.

Dos modelos mentales

Ambas herramientas tienen una arquitectura de tres capas, pero las capas cumplen propósitos distintos.

Claude Code:

1. Razonamiento. Claude Code ejecuta el modelo de Claude seleccionado. A partir de la CLI v2.1.154 (28 de mayo de 2026), Opus 4.8 es el predeterminado, con esfuerzo alto por defecto y un nivel /effort xhigh para las tareas más difíciles; Sonnet 4.6 y Haiku 4.5 siguen disponibles para trabajo más ligero ²
2. Ejecución. Bash, operaciones de archivos, comandos de git, llamadas a herramientas MCP
3. Gobernanza. Los hooks interceptan acciones en más de dos docenas de puntos del ciclo de vida ²; los permisos limitan el alcance

Codex:

1. Modelo. GPT-5.5 (lanzado el 23 de abril de 2026) es el predeterminado: 400K de contexto en Codex, 1M en la API, 5 $ / 30 $ por MTok, 82,7 % en Terminal-Bench 2.0 (estado del arte en su lanzamiento). GPT-5.5-pro cubre el nivel de mayor esfuerzo; el más pequeño GPT-5.4 mini sigue encargándose del trabajo de subagentes de menor latencia ⁴
2. Sandbox. Aplicación a nivel de kernel del sistema operativo (Seatbelt en macOS, Landlock + seccomp en Linux) ³
3. Aprobación. Tres políticas (untrusted, on-request, never) controlan las mutaciones antes de su ejecución ⁵

La diferencia crítica es dónde vive principalmente la gobernanza. El centro de gravedad de Claude Code es la capa de aplicación; los hooks son programas que tú escribes y que interceptan eventos específicos. El centro de gravedad de Codex es la capa del kernel; el sistema operativo impide las operaciones no permitidas sin importar lo que el modelo intente. Ahora ambas herramientas tienen hooks, pero las arquitecturas siguen partiendo de valores por defecto distintos.

Por qué importa esta distinción: la gobernanza en la capa de aplicación es programable. Puedes codificar lógica de negocio, ejecutar linters, validar esquemas, cualquier cosa expresable en código. La gobernanza en la capa del kernel es a prueba de fugas. El modelo no puede eludir las restricciones porque el sistema operativo deniega la syscall antes de que llegue a la aplicación. Toda arquitectura de seguridad intercambia expresividad por fortaleza, y estas dos herramientas se sitúan en los extremos opuestos de ese espectro.

Filosofía de configuración

Claude Code usa JSON. Codex usa TOML. Ambos admiten ámbitos jerárquicos. Las filosofías difieren en cómo piensan sobre el cambio de contexto.

Claude Code: configuración por capas

// ~/.claude/settings.json (user-level)
{
  "permissions": {
    "allow": ["Bash(git *)"],
    "deny": ["Bash(rm -rf *)"]
  }
}

// .claude/settings.json (project-level, inherits user)
{
  "permissions": {
    "allow": ["Bash(npm test)"]
  }
}

Claude Code resuelve la configuración desde múltiples capas: ajustes gestionados (máxima prioridad) → línea de comandos → proyecto local → proyecto compartido → valores por defecto del usuario ⁶. Los archivos de memoria (CLAUDE.md) siguen su propio ámbito: usuario → proyecto → local. Los skills y hooks añaden capas adicionales. La flexibilidad es potente, pero la configuración activa no es visible desde un único archivo; la reconstruyes leyendo la jerarquía.

Codex: perfiles con cambio explícito

# ~/.codex/config.toml
model = "gpt-5.5"
approval_policy = "on-request"

[profiles.deep-review]
model = "gpt-5.5-pro"
approval_policy = "never"

[profiles.careful]
approval_policy = "untrusted"

codex --profile careful "Review this PR"
codex --profile deep-review "Audit this module"

Los perfiles de Codex te permiten alternar entre configuraciones con un flag ⁷. No hay resolución por capas sobre la que razonar; la configuración activa siempre es explícita. Para equipos que estandarizan políticas de aprobación, esto es más sencillo de auditar. Los perfiles han pasado de experimentales a una superficie gestionada de primer nivel: --profile es ahora el selector principal en la CLI, los permisos de la TUI y los flujos de sandbox, y los perfiles de permisos con nombre admiten herencia, APIs de listado y un requirements.toml gestionado para políticas de la organización ⁷.

Modelos de seguridad

La seguridad es la divergencia arquitectónica más profunda entre las herramientas.

Claude Code: hooks deterministas en la capa de aplicación

Los hooks interceptan acciones antes de que se ejecuten. Un hook PreToolUse en Bash puede inspeccionar cada comando y bloquear patrones peligrosos ²:

# Hook: git-safety-guardian (PreToolUse:Bash)
if echo "$tool_input" | grep -q "push.*--force.*main"; then
  echo '{"decision": "block", "reason": "Force push to main blocked"}'
fi

La fortaleza: los hooks son programas. Puedes codificar lógica de seguridad arbitrariamente compleja: comprobar rutas de archivos, validar JSON, aplicar convenciones de nombres, ejecutar linters. Yo ejecuto 95 hooks que cubren desde detección de credenciales hasta puertas de calidad.

La debilidad: los hooks operan en la capa de aplicación. En 2025, Check Point Research reveló la CVE-2025-59536, demostrando que hooks maliciosos en los archivos de configuración de un proyecto podían ejecutar comandos de shell durante la inicialización de Claude Code, antes de que el usuario viera un diálogo de consentimiento ¹⁹. Anthropic parcheó la vulnerabilidad en cuestión de semanas, pero la divulgación valida la preocupación arquitectónica: la aplicación a nivel de aplicación comparte un límite de proceso con el agente. La guía del AI Red Team de NVIDIA llega a la misma conclusión: “los hooks y las funciones de inicialización de MCP suelen ejecutarse fuera de un entorno de sandbox, ofreciendo una oportunidad para escapar de los controles del sandbox” ²⁰.

Codex: sandboxing a nivel de kernel

Codex restringe al agente a nivel de sistema operativo. En macOS, los perfiles de Seatbelt limitan el acceso al sistema de archivos, la conectividad de red y la creación de procesos ³. En Linux, Landlock + seccomp proporcionan restricciones equivalentes, con un pipeline opcional de Bubblewrap (bwrap) disponible vía configuración ³.

# Three sandbox modes
codex --sandbox read-only           # Agent can read but not write
codex --sandbox workspace-write     # Agent writes only in project directory (default)
codex --sandbox danger-full-access  # No restrictions (named to signal risk)

La fortaleza: la aplicación a nivel de kernel está por debajo de la aplicación. El modelo no puede escapar de las restricciones elaborando comandos ingeniosos; el sistema operativo deniega la syscall antes de que se ejecute ³. El prefijo danger- en el modo de acceso total refleja que eliminar las restricciones del sandbox es una acción excepcional, no un ajuste rutinario.

La debilidad: las restricciones del kernel son binarias. Puedes permitir o denegar la escritura en el sistema de archivos, pero no puedes decir “permite escrituras en src/ pero bloquea las escrituras en config/ salvo que el cambio pase un linter”. Esa gobernanza granular requiere lógica a nivel de aplicación.

El tradeoff es real. Los hooks ofrecen seguridad granular y programable, pero con límites más débiles. El sandboxing ofrece límites más fuertes, pero con un control más grueso. Una heurística rápida de decisión:

• Confianza interna, código externo: usa Codex con sandboxing read-only cuando revises PRs de contribuidores desconocidos. El kernel impide la modificación de archivos sin importar lo que el modelo intente.
• Código de confianza, aplicación de políticas: usa hooks de Claude Code cuando confías en la base de código pero necesitas aplicar estándares organizativos: formatos de mensajes de commit, escaneo de credenciales, puertas de linting.
• Ambas preocupaciones: usa las dos. Emplea Codex como el primer límite de seguridad y luego cambia a Claude Code para una revisión intensiva en gobernanza.

Extensibilidad

Ambas herramientas admiten personalización, pero la madurez varía según el mecanismo.

Dónde lidera Claude Code: la profundidad de los hooks. El sistema de ciclo de vida abarca PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, SessionEnd, Stop, StopFailure, SubagentStart, SubagentStop, PreCompact, PermissionRequest, PermissionDenied, TaskCreated, TaskCompleted, CwdChanged, FileChanged, MessageDisplay y más. Son más de dos docenas de eventos y siguen creciendo ². Codex ahora también tiene hooks, pero el catálogo de Claude Code es más amplio y está más probado en producción, y se combina con el additionalContext del hook Stop para dirigir y con /workflows dinámicos para grandes despliegues de agentes. Si necesitas aplicar puertas de calidad, detectar filtraciones de credenciales antes de los commits o inyectar contexto automáticamente en muchos tipos de eventos, la arquitectura de hooks de Claude Code es la opción más madura.

Dónde Codex cerró una brecha: los hooks ya no son exclusivos de Claude Code. La comunidad llevaba pidiendo más eventos de hooks durante buena parte de 2025 ¹⁸, y Codex cumplió: un verdadero sistema de hooks de ciclo de vida con los eventos AfterAgent y AfterToolUse, una TUI /hooks para descubrirlos y activarlos a mitad de sesión, y una API de extensiones donde las extensiones observan el inicio/fin de subagentes, la ejecución de herramientas y los metadatos de la vuelta con aprobación asíncrona ⁹. El antiguo planteamiento (Claude Code tiene hooks, Codex tiene una única notificación a posteriori) está desfasado. La afirmación honesta para 2026: ambas herramientas tienen hooks de gobernanza programables; el de Claude Code es más amplio y maduro, el de Codex corre junto al sandbox más fuerte de la categoría.

Dónde lidera Codex: portabilidad entre herramientas y superficies. AGENTS.md es un estándar abierto gobernado por la Agentic AI Foundation bajo la Linux Foundation ¹³, adoptado por más de 60.000 proyectos ⁸. El mismo archivo de instrucciones funciona en Codex, Cursor, GitHub Copilot, Amp, Windsurf y Gemini CLI (con configuración) ¹⁴. CLAUDE.md es potente, pero está bloqueado a Claude Code. Codex además corre en cinco superficies (CLI, app de escritorio, extensión de IDE, nube y una extensión de Chrome que acompaña la navegación normal ¹⁶), y codex cloud exec descarga trabajo de larga duración a la infraestructura de OpenAI y devuelve diffs ¹², un flujo de trabajo que Claude Code no ofrece de forma nativa.

Dónde gana cada herramienta

Basado en 36 duelos a ciegas, donde envié prompts idénticos a ambas herramientas y puntué los resultados a ciegas, y en el uso diario en producción:

La metodología completa y la puntuación duelo a duelo está en The Blind Judge. Estos resultados son anteriores a Opus 4.8 y GPT-5.5, así que tómalos como orientativos y no como un marcador actual: capturan la forma de cada herramienta (Claude Code más fuerte en revisión y razonamiento, Codex más fuerte en DevOps y aislamiento), que se ha mantenido a lo largo de las actualizaciones de modelos, no los márgenes exactos en los modelos de hoy. Repetiré los duelos con los valores por defecto actuales; hasta entonces, las tendencias por categoría son la señal duradera.

Claude Code gana

• Revisión de código y verificación de seguridad. Claude Code ganó 8 de los 12 duelos decididos en tareas de revisión ¹. El sistema de filosofía de calidad y las puertas de evidencia detectan problemas que se cuelan por el enfoque más procedimental de Codex.
• Flujos de trabajo intensivos en gobernanza. Si tu flujo requiere chequeos pre-commit, escaneo de credenciales, validación de salida o puertas de calidad que bloqueen antes de la ejecución, el hook PreToolUse de Claude Code es el mecanismo. Codex ya tiene sus propios hooks de ciclo de vida (AfterAgent, AfterToolUse) ⁹, pero observan a posteriori; para el bloqueo previo a la ejecución Codex se apoya en su sandbox y su política de aprobación en lugar de un hook previo programable. Por amplitud de tipos de eventos y lógica de bloqueo en línea, el catálogo de Claude Code sigue siendo el conjunto de gobernanza más completo.
• Orquestación compleja de múltiples agentes. La delegación explícita a subagentes vía el Task tool ¹⁰, combinada con /workflows dinámicos que despliegan de decenas a cientos de agentes en segundo plano y con sistemas de deliberación, habilita flujos en los que muchos agentes especializados colaboran con contexto aislado.
• Refactorización profunda de la base de código. Opus destaca al sostener contexto arquitectónico a lo largo de sesiones largas. Los patrones de ingeniería de contexto que gobiernan la jerarquía de hooks/skills/rules de Claude Code se traducen directamente en cómo el modelo razona sobre bases de código grandes.

Codex gana

• Entornos donde el sandbox es crítico. Si estás ejecutando un agente de IA contra código no confiable, procesando PRs externos u operando en un pipeline de CI/CD donde necesitas garantías duras sobre el acceso al sistema de archivos y la red, el sandboxing a nivel de kernel de Codex es la herramienta adecuada ³. Los hooks a nivel de aplicación no pueden ofrecer la misma garantía.
• Equipos multiherramienta. Si tu equipo usa varias herramientas de codificación con IA, AGENTS.md te da un único archivo de instrucciones que funciona en Codex, Cursor, Copilot, Amp, Windsurf y más ¹⁴. Sin duplicar el mantenimiento en CLAUDE.md, .cursor/rules e instrucciones de Copilot.
• Flujos de trabajo asíncronos en la nube. codex cloud exec delega tareas a infraestructura en la nube y devuelve diffs ¹². Para integración de CI/CD o procesamiento por lotes, es un flujo que Claude Code no ofrece de forma nativa.
• Dirección en tiempo real. El modo steer de Codex te permite inyectar instrucciones a mitad de tarea con Enter (inmediato) o encolar seguimientos con Tab (próxima vuelta) ¹⁵. Claude Code admite mensajes de seguimiento pero no inyección a mitad de vuelta.
• Cobertura de superficies. Codex abarca cinco superficies: CLI, app de escritorio (multitarea en macOS entre worktrees paralelos y ventanas flotantes), extensión de IDE (VS Code, Cursor, Windsurf), tareas en la nube y una extensión de Chrome que acompaña tu navegación sin apropiarse de ella ¹⁶. Claude Code se integra con VS Code y JetBrains ¹⁷, pero es CLI-first. Si quieres un único agente que te siga de la terminal al editor, al navegador y a la nube, Codex cubre más terreno.

Usar las dos

Las herramientas no entran en conflicto. CLAUDE.md y AGENTS.md coexisten en el mismo repositorio. Así es como lo tengo montado:

my-project/
├── .claude/
│   └── settings.json     # Claude Code project config
├── CLAUDE.md              # Claude Code instructions
├── AGENTS.md              # Codex + Cursor + Copilot instructions
└── codex.md               # Codex project config (optional)

Un flujo de trabajo concreto con ambas herramientas: uso Claude Code para el desarrollo diario: implementación de funciones, revisión de código, refactorizaciones multiarchivo donde los hooks aplican puertas de calidad en cada paso. Cuando un contribuidor externo abre un PR, cambio a Codex con --sandbox read-only para revisar sus cambios contra código no confiable. Cuando necesito una segunda opinión sobre una decisión arquitectónica, envío el mismo prompt a ambas herramientas y comparo los resultados a ciegas mediante el enfoque del blind judge.

El enfoque de doble herramienta tiene respaldo empírico más allá de mis propias pruebas. Una investigación de Milvus encontró que la revisión adversarial entre múltiples modelos de IA aumentó la detección de bugs del 53% al 80% ²³. Un estudio aparte descubrió que los bucles iterativos de revisión entre Claude y Codex atraparon 14 problemas en 3 rondas que ninguna herramienta encontró por sí sola ²⁴. Ninguna de las dos reemplaza a la otra; cubren modelos de amenaza y perfiles de tarea distintos.

Puntos clave

Si estás eligiendo una herramienta:

• Empieza por tus requisitos de seguridad. ¿Necesitas sandboxing a nivel de kernel? Codex. ¿Necesitas hooks de gobernanza programables? Claude Code.
• Considera a tu equipo. ¿Varias herramientas de IA en uso? AGENTS.md evita duplicar el mantenimiento de instrucciones entre herramientas ¹⁴.
• Prueba ambas en una tarea real antes de decidir. La metodología del blind judge también funciona para la evaluación personal.

Si ya estás comprometido con una:

• Usuarios de Claude Code: escribe un AGENTS.md igualmente. Te lleva 20 minutos y hace que tu proyecto sea accesible para usuarios de Codex, Cursor y Copilot.
• Usuarios de Codex: el sistema de hooks ya llegó. Explóralo con /hooks, conecta AfterAgent/AfterToolUse y apóyate en los perfiles de permisos y el sandbox para el control previo a la ejecución ⁹. La suposición de que «Codex no tiene hooks» que quizá arrastres de principios de 2026 está desfasada.
• Ambas herramientas están mejorando rápido. La comparación de este artículo tiene una vida útil medida en semanas, no en años, y por eso lleva una línea de revisión fechada.

Preguntas frecuentes

¿Puedo usar las dos herramientas en el mismo proyecto?

Sí. CLAUDE.md y AGENTS.md son archivos separados sin conflictos. Cada herramienta lee su propio archivo de instrucciones e ignora el otro. Yo mantengo ambos en mis proyectos activos.

¿Qué herramienta es mejor para principiantes?

Codex tiene una barrera de configuración más baja: tres modos de sandbox y tres políticas de aprobación cubren la mayoría de los casos de uso ⁵. La potencia de Claude Code proviene de los hooks y skills, que requieren inversión para configurarse. Empieza con el modelo (Claude o GPT) con el que ya te sientas cómodo.

¿Cómo se comparan los costes?

Ambas usan precios basados en tokens a través de sus respectivas APIs. Claude Code se apoya en los precios de Anthropic; Codex se apoya en el sistema de créditos de OpenAI. Un benchmark independiente de Composio encontró que Codex consumió de 2 a 4 veces menos tokens para resultados comparables. En una tarea de plugin de Figma, Claude Code usó 6,2M tokens frente a los 1,5M de Codex ²². La eficiencia de tokens no se traduce directamente en coste (los precios por token difieren), pero el menor consumo de tokens de Codex es una ventaja medible para flujos de trabajo con presupuesto limitado.

¿Funcionará AGENTS.md con Claude Code?

Actualmente no. Claude Code lee CLAUDE.md; Codex lee AGENTS.md. Los formatos son lo suficientemente parecidos como para que el contenido se traduzca con facilidad entre ellos, pero no hay lectura cruzada automática. Escribir ambos requiere un esfuerzo mínimo, ya que el contenido se solapa.

¿Cuál tiene mejor integración con el IDE?

Codex tiene la mayor superficie: una app de escritorio para macOS con multitarea y ventanas flotantes, una extensión de IDE para VS Code, Cursor y Windsurf, y una extensión de Chrome, todas compartiendo un mismo modelo de sesión ¹⁶. Claude Code se integra con VS Code mediante extensión y con JetBrains mediante plugin (beta) ¹⁷. Ambas funcionan bien; la elección depende de si prefieres flujos CLI-first (Claude Code) o una huella GUI/multisuperficie (Codex).

Referencias