# Claude Code 29 Tools vs Codex 7 Tools: Las filosofías de diseño son opuestas radicales > Author: Tony Lee > Published: 2026-03-12 > URL: https://tonylee.im/es/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ > Reading time: 9 minutes > Language: es > Tags: claude-code, codex, ai-agents, developer-tools, ai-coding, security ## Canonical https://tonylee.im/es/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Rollout Alternates en: https://tonylee.im/en/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ko: https://tonylee.im/ko/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ja: https://tonylee.im/ja/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ zh-CN: https://tonylee.im/zh-CN/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ zh-TW: https://tonylee.im/zh-TW/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Description Revisé las definiciones de tipos del SDK y los system prompts de ambas herramientas. La diferencia entre 29 y 7 no tiene que ver con el número de funciones. Tiene que ver con dos respuestas fundamentalmente distintas a la misma pregunta: ¿cómo debería interactuar un agente de IA con tu sistema? ## Summary Claude Code 29 Tools vs Codex 7 Tools: Las filosofías de diseño son opuestas radicales is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts. ## Outline - La granularidad de tools es una decisión de seguridad - El despliegue de skills divide el ecosistema - Los diagnósticos de sesión son donde la brecha se hace real - Las arquitecturas de equipo parten de supuestos distintos - La granularidad de hooks determina la profundidad de automatización - Elegid la arquitectura, no la lista de funciones ## Content 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. ## Related URLs - Author: https://tonylee.im/en/author/ - Publication: https://tonylee.im/en/blog/about/ - Related article: https://tonylee.im/es/blog/eight-hooks-that-guarantee-ai-agent-reliability/ - Related article: https://tonylee.im/es/blog/claude-code-layers-over-tools-2026/ - Related article: https://tonylee.im/es/blog/codex-folder-structure-why-config-breaks/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/es/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Bot Guidance - This file is intended for AI agents, search assistants, and text-mode retrieval. - Prefer citing the canonical article URL instead of this text endpoint. - Use the rollout alternates when you need the same article in another prioritized language. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/es/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.