Claude Code 29 Tools vs Codex 7 Tools: Las filosofías de diseño son opuestas radicales

Me cansé de perseguir las actualizaciones semanales de Claude Code y Codex, así que volví a los principios básicos. Abrí cada definición de tipo del SDK, cada system prompt, cada esquema de configuración que pude encontrar. Quería entender no solo qué hace cada herramienta, sino por qué el número de tools diverge de forma tan dramática.

Claude Code expone 29 tools. Codex expone 7. Esa proporción no dejaba de llamarme la atención, porque no puede ser simplemente una brecha de funcionalidades. Dos equipos bien financiados con ingenieros de primer nivel no llegan por accidente a una proporción de 4:1. La diferencia es intencional, y el razonamiento detrás de ella revela dos filosofías genuinamente distintas sobre cómo debería interactuar la IA con vuestro entorno de desarrollo.

La granularidad de tools es una decisión de seguridad

La diferencia más llamativa es cómo cada herramienta gestiona las operaciones con archivos. Claude Code divide la manipulación de archivos en cuatro tools separadas: Read, Write, Edit y MultiEdit. La búsqueda también tiene sus propias tools dedicadas, con Grep y Glob completamente independientes de Bash. Esto significa que podéis configurar settings.json para permitir Read pero bloquear Write. Podéis dejar que el agente busque en vuestro código sin concederle nunca permiso para modificar ni un solo archivo. El control de permisos ocurre a nivel de tool.

Codex toma un camino diferente. Le da al agente shell, apply_patch y file_read como primitivas principales. Todo lo demás pasa por el shell. ¿Queréis buscar archivos? Es un comando de shell. ¿Queréis listar directorios? Shell de nuevo. La seguridad no viene de los permisos a nivel de tool, sino de las reglas de execpolicy que hacen pattern-matching contra comandos de shell concretos, clasificándolos en las categorías allow, prompt o block.

Ningún enfoque es incorrecto. El modelo de Claude Code os da cerrojos de grano fino, pero requiere mantener una superficie de tools más amplia. El modelo de Codex es más sencillo de razonar, pero delega la aplicación de seguridad en el string-matching sobre comandos de shell, lo que se vuelve frágil cuando los comandos se complican. He visto casos en que una cadena de pipes bien construida se salta una regla de execpolicy escrita para la versión directa del mismo comando.

El desglose completo:

• Claude Code (29 tools): 4 tools de archivo (Read/Write/Edit/MultiEdit), 3 tools de búsqueda (Glob/Grep/LS), 2 tools web, 3 tools cron, 4 tools MCP, Bash y más
• Codex (7 tools): shell, apply_patch, file_read, web_search, update_plan, write_stdin, js_repl

El despliegue de skills divide el ecosistema

Ambas herramientas adoptaron el estándar abierto Agent Skills, donde un único archivo SKILL.md define el comportamiento de una skill. La estructura es idéntica. El modelo de distribución no lo es.

Codex construyó un sistema de distribución centralizado. Ejecutar $skill-installer descarga skills seleccionadas del repositorio oficial de skills de OpenAI. Pasad una URL de GitHub y también podéis instalar skills de terceros. Incluso existe $skill-creator para generar nuevas skills de forma interactiva a través de la conversación. La experiencia se parece a npm: un comando, un registro, disponibilidad inmediata.

Claude Code fue en la dirección contraria. Creáis archivos SKILL.md en .claude/skills/ manualmente, o instaláis bundles desde repositorios git mediante /plugin marketplace add. No hay un registro oficial único. Las skills se descubren a través de repositorios de la comunidad, enlaces compartidos y el boca a boca.

Al principio preferí el modelo centralizado de Codex porque la descubribilidad es mejor. Pero tras usar ambas herramientas durante varias semanas, el enfoque descentralizado tiene una ventaja real: puedo editar un archivo de skill a mitad de sesión y los cambios se aplican de inmediato sin reiniciar. Con las skills instaladas de Codex, los cambios requieren una reinstalación. Cuando estáis iterando sobre un flujo de trabajo personalizado, esa diferencia importa más de lo que esperaba.

Comparación rápida:

• Invocación: Claude Code usa /skill-name, Codex usa $skill-name
• Almacenamiento: .claude/skills/ vs .agents/skills/
• Skills integradas: Claude Code incluye /simplify, /batch, /loop, /claude-api; Codex incluye $skill-installer, $skill-creator
• Distribución: Marketplace descentralizado vs repositorio centralizado

Los diagnósticos de sesión son donde la brecha se hace real

Ambas herramientas comparten lo básico: /model, /plan, /review, /clear, /fast. La divergencia aparece en la introspección de la sesión.

Claude Code invirtió mucho en permitiros entender qué ocurre dentro de vuestra sesión. /compact activa manualmente la compresión del contexto. /context muestra lo que está cargado. /cost rastrea el gasto en tokens en tiempo real. /doctor diagnostica problemas de configuración. /rewind vuelve a un estado anterior de la conversación. /insights analiza un mes de patrones de uso y sugiere mejoras. /usage muestra el consumo acumulado entre sesiones. Son siete comandos dedicados exclusivamente a entender y gestionar el estado de la sesión.

Codex se centró en otra parte. /personality ajusta el estilo de comunicación del agente. /theme cambia el aspecto visual. /apps gestiona las aplicaciones conectadas. Son funciones de personalización de UX, no herramientas de diagnóstico.

Esto refleja una división filosófica más profunda. Claude Code trata la sesión como algo que deberíais monitorizar y dirigir activamente. Codex la trata como algo que debería funcionar solo en segundo plano mientras os centráis en personalizar la experiencia. Tras meses de uso, me encuentro queriendo ambas cosas. Los diagnósticos me salvan cuando una sesión se tuerce, pero también agradezco poder ajustar la personalidad cuando paso de trabajo de arquitectura detallado a correcciones rápidas de bugs.

• Claude Code (~35 comandos + 4 skills incluidas): enfocado en diagnósticos de sesión como /compact, /context, /cost, /doctor, /rewind, /insights, /usage
• Codex (~19 comandos): más fuerte en personalización de UX con /personality, /theme, /copy, /apps, /skills, /agent, /tools

Las arquitecturas de equipo parten de supuestos distintos

La forma en que cada herramienta gestiona la colaboración multiagente revela quizás la diferencia de diseño más profunda.

Los Agent Teams de Claude Code usan comunicación peer-to-peer. Los miembros del equipo se envían mensajes directamente entre sí sin pasar por un agente principal. Comparten una lista de tareas y se coordinan de forma autónoma. Podéis ejecutar entre 2 y 16 agentes, y negociarán entre ellos quién hace qué. Lo probé con tres agentes en una tarea de refactorización, y el consumo de tokens fue entre 3 y 7 veces mayor que una única sesión haciendo el mismo trabajo. El coste de coordinación es real. Pero cuando la tarea se beneficia genuinamente de la exploración paralela (como depurar una race condition en la que queréis agentes explorando hipótesis distintas simultáneamente), el modelo P2P encuentra respuestas más rápido.

Codex usa un modelo hub-spoke. Los agentes hijos solo reportan al padre. No hay comunicación lateral. El comando spawn_agents_on_csv crea agentes en masa desde un archivo CSV, optimizado para tareas paralelizables donde cada unidad de trabajo es independiente. Pensad en: “aplica esta migración a 200 archivos” o “ejecuta esta comprobación contra cada endpoint de esta lista”.

P2P no es universalmente mejor. Desperdicié tokens significativos en una tarea de batch directa porque los agentes de Claude Code seguían discutiendo su trabajo solapado entre sí. El hub-spoke de Codex habría sido la elección correcta para ese trabajo concreto.

• Claude Code: mensajería P2P con lista de tareas compartida, 2 a 16 agentes, soporte de paneles divididos en tmux
• Codex: arquitectura hub-spoke, creación masiva de agentes desde CSV mediante spawn_agents_on_csv

La granularidad de hooks determina la profundidad de automatización

Claude Code os permite interceptar la ejecución de tools en múltiples puntos del ciclo de vida. PreToolUse se activa antes de que una tool se ejecute, permitiéndoos validar o modificar la llamada. PostToolUse se activa después, así que podéis adjuntar un formateador que se ejecute automáticamente en cada guardado de archivo. Los hooks Notification capturan las comunicaciones del agente. PreCompact se activa antes de la compresión del contexto, dándoos la oportunidad de preservar información crítica. Los HTTP Hooks pueden hacer POST de JSON a URLs externas, conectando Claude Code a pipelines de CI, Slack o dashboards personalizados.

Codex lo mantiene simple. Un único archivo execpolicy con reglas allow/prompt/block aplicadas a comandos de shell. Esa es toda la superficie de extensibilidad para controlar el comportamiento del agente.

Configuré un hook PostToolUse que ejecuta Prettier después de cada operación Write. Me llevó cinco minutos y eliminó toda una categoría de prompts de seguimiento relacionados con el formateo. Ese tipo de automatización quirúrgica no es posible en el modelo de Codex, donde tendríais que incluir “y ejecuta prettier después de escribir” en cada prompt o construirlo dentro de una skill.

Pero la simplicidad de Codex también tiene valor. Nunca he roto accidentalmente mi configuración de Codex con un hook mal configurado. Lo he hecho dos veces con Claude Code: una con un hook PreToolUse que bloqueaba silenciosamente lecturas de archivos legítimas y causó veinte minutos de depuración confusa.

• Claude Code: PreToolUse, PostToolUse, Notification, PreCompact y HTTP Hooks
• Codex: archivo de reglas execpolicy con tres niveles (allow/prompt/block)

Elegid la arquitectura, no la lista de funciones

La comparación entre 29 y 7 no trata de que una herramienta sea más capaz que la otra. Trata de dos respuestas distintas a la misma pregunta de diseño: ¿cuánto debería descomponer un agente de IA sus capacidades en unidades controlables individualmente?

Claude Code dice “todo”. Cada operación tiene su propia tool, su propia superficie de permisos, sus propios puntos de hook. Esto os da el máximo control a costa de la complejidad de configuración. Codex dice “solo lo esencial”. Las operaciones principales tienen tools dedicadas; todo lo demás fluye a través del shell con salvaguardas basadas en políticas. Esto os da simplicidad a costa de la granularidad.

Cuando elijo qué herramienta usar para un proyecto concreto, la lista de funciones apenas importa. Lo que importa es si el proyecto necesita control de permisos de grano fino (codebase regulado, varios colaboradores con distintos niveles de acceso) o simplicidad ligera (proyecto en solitario, iteración rápida, configuración mínima). La arquitectura sobre la que construís da forma a cada decisión de flujo de trabajo que viene después.