Habilitar herramientas externas con MCP: añadiendo conectores externos a Codex

📚 Navegación de la serie: El artículo anterior [19 · El sistema de memoria (Memories y Chronicle)] abordó el registro de preferencias del usuario entre sesiones. En este capítulo daremos un paso hacia el exterior: por defecto, Codex solo interactúa con los archivos y la consola locales; no puede conectarse a tus bases de datos, Figma o documentación externa. MCP is el conector unificado que permite enlazar de golpe múltiples herramientas externas y fuentes de datos. En el próximo artículo [21 · Subagentes (Subagents)] explicaremos cómo delegar tareas en paralelo a un equipo de agentes subordinados con contextos independientes.

Déjame contarte un error típico que cometí cuando empecé a usar MCP.

Yo venía de utilizar Claude Code y tenía memoria muscular: para añadir un servidor, escribía claude mcp add --scope user xxx, donde --scope definía en qué proyectos aplicarse. Al pasar a Codex, ejecuté una instrucción similar sin pensar añadiendo el parámetro --scope y la consola arrojó de inmediato un error indicando que el parámetro no existía. Mi primera reacción fue pensar en una "versión obsoleta" e intenté actualizar la app sin éxito; luego dudé de la sintaxis y reformulé el comando varias veces, pero seguía sin funcionar.

Tras pelearme con la consola durante casi veinte minutos, leí la documentación oficial y caí en la cuenta: Codex carece por completo del concepto de --scope. Centraliza toda la configuración de MCP en un único archivo config.toml, y el "alcance del proyecto" se determina por la ubicación del propio archivo: guardarlo en el directorio de usuario global ~/.codex/config.toml lo habilita en todas partes, y añadirlo en el .codex/config.toml del proyecto limita su uso a ese directorio específico. Había intentado forzar las dinámicas de Claude Code en los comandos de Codex y por eso no avanzaba.

Comparto esta experiencia para ahorrarte esos de veinte minutos de frustración: el protocolo MCP es idéntico en ambos entornos, pero su sintaxis de configuración en Codex y Claude Code es diferente. En este artículo detallaremos el funcionamiento en Codex y completaremos una práctica real vinculando un servidor.

Al terminar este artículo, obtendrás:

• Una explicación directa sobre qué es MCP y qué vacíos funcionales resuelve en Codex.
• Cuándo usar cada tipo de servidor (STDIO local y HTTP Streamable remoto), detallados en una tabla comparativa.
• Dos vías de configuración: el comando codex mcp add frente a la edición manual de config.toml, y cómo la ubicación del archivo decide si el perfil es global o local.
• Cómo usar parámetros como enabled, disabled_tools y default_tools_approval_mode para restringir herramientas y permisos de un servidor.
• Una guía práctica paso a paso: cómo conectar el servidor de documentación Context7 y verificar su funcionamiento en pocos minutos.

---

01 Comprender primero: qué vacíos funcionales resuelve MCP en Codex

Definamos el concepto de entrada: por defecto, Codex actúa como un asistente limitado a las tareas locales; MCP es el conector que le permite enlazar de forma unificada herramientas y fuentes de datos externas.

Si recuerdas los artículos anteriores, Codex realizaba acciones como leer archivos locales, modificar tu código y ejecutar comandos de consola; todas ellas son tareas locales. Por muy hábil que sea el modelo, no puede acceder a las propuestas de diseño en Figma, buscar la documentación de API más reciente de una librería o controlar el navegador para interactuar con una interfaz. Ante la falta de conectores directos, tu única opción es copiar y pegar datos, tomar capturas de pantalla y documentar el contexto manualmente para proporcionárselo.

Analogía: El adaptador multipuerto del móvil. Los móviles modernos suelen incluir un único puerto USB-C, imposibilitando conectar un lápiz de memoria, un cable HDMI para proyectar la pantalla o tarjetas SD simultáneamente. ¿La solución? Comprar un adaptador multipuerto: conéctalo al puerto principal y dispondrás de tomas USB, HDMI y ranuras para tarjetas al instante. MCP (Model Context Protocol, un protocolo abierto que define cómo los modelos invocan herramientas externas) es este adaptador para Codex: lo conectas una vez y el modelo accede de inmediato a múltiples recursos externos.

La documentación oficial lo define de forma muy directa:

Model Context Protocol (MCP) conecta el modelo a herramientas y contextos. Utilízalo para enlazar documentación de terceros con Codex o interactuar con utilidades de desarrollo como Figma o navegadores.

La palabra clave aquí es estándar. MCP no es un protocolo propietario desarrollado a puerta cerrada por OpenAI, sino una especificación abierta. La ventaja radica en que permite una única integración compatible con múltiples entornos: si desarrollas un servidor MCP para una utilidad específica, podrá consumirse en Codex, Claude Code, Cursor o cualquier otro cliente compatible. Codex admite el estándar MCP, variando únicamente su formato de configuración (como comentaba al inicio y detallaremos en la sección 03).

Un detalle específico de Codex: el sistema lee la clave instructions (instrucciones) devuelta por el servidor durante su inicialización y la asimila como directriz de uso; suele contener limitaciones de peticiones, reglas del flujo de trabajo o restricciones. En definitiva, los servidores de calidad incorporan su propio manual de uso y Codex lo cargará automáticamente.

¿Cuándo conviene recurrir a MCP? El criterio es sencillo: si notas que vuelves a copiar datos de una ventana externa para pegarlos en el chat de Codex, necesitas integrar un servidor MCP. Veamos algunos escenarios comunes:

• "Ajusta los estilos de esta vista de acceso según la propuesta de Figma": el modelo lee la mesa de trabajo directamente sin requerir capturas.
• "Refactoriza este código usando la API más reciente de esta librería": consulta la documentación actualizada al instante sin arrastrar sintaxis obsoletas.
• "Abre el navegador y toma una captura de la interfaz adaptada a móvil": controla la navegador por su cuenta sin intervención manual.

💡 Resumen en una frase: Por defecto, Codex no puede acceder a propuestas de diseño, documentación reciente o interfaces del navegador; MCP actúa como puerto de conexión unificado para interactuar con herramientas externas e integra la clave instructions como manual de uso.

Esquema: Codex solo interactúa con archivos y consola locales; MCP actúa como concentrador USB para enlazar repositorios, bases de datos o entornos de diseño en una única interfaz.

---

02 Dos tipos de servidor: local o remoto en la nube

Existen diferentes arquitecturas de servidores MCP; comprender su distinción te ayuda a estructurar tu archivo de configuración. La pregunta clave es: ¿el servidor se ejecuta localmente en tu máquina o se hospeda en una dirección web remota?

Analogía: Los aparatos eléctricos del hogar; unos requieren cables y otros conexión inalámbrica. Una lámpara o un ventilador son dispositivos físicos en la habitación conectados al enchufe; el altavoz inteligente, para consultar el tiempo o reproducir música, requiere conectarse a servidores remotos en la nube. Los servidores MCP se dividen bajo el mismo criterio: procesos locales ejecutados en tu máquina y servidores externos remotos a los que te conectas.

La documentación oficial define soporte para ambas estructuras:

Tipo	Ubicación	Ejecución / Conexión	Casos de uso
STDIO (proceso local)	Localmente en tu máquina	Invoca mediante una instrucción de terminal (p. ej. npx ...)	Servidores que interactúan con archivos locales, navegadores o herramientas locales
Streamable HTTP (remoto)	En una dirección web externa	Se define una URL de conexión	Servicios web, documentación en la nube o entornos de diseño (requiere autenticación)

Detalles y precauciones para principiantes:

La clave de los servidores STDIO es su "instrucción de arranque". Básicamente, Codex arranca un microservicio local en segundo plano en cada inicio basándose en tu comando (como npx -y @upstash/context7-mcp). Por tanto, requiere disponer del entorno correspondiente en el sistema (por ejemplo, Node.js para invocar comandos de npx). Permiten además inyectar variables de entorno específicas (--env o env en la configuración) para asignar credenciales de acceso.

Los servidores HTTP se conectan a recursos en la nube y admiten dos métodos de autenticación según detalla la documentación oficial:

• Bearer token: se especifica el nombre de la variable de entorno que contiene el token de acceso.
• OAuth (acceso con credenciales): para servidores compatibles con OAuth, ejecuta codex mcp login <nombre_del_servidor> para autorizar el acceso.

Recursos como Figma o repositorios de documentación remotos solo requieren su dirección URL y credenciales de acceso, sin necesidad de instalar utilidades locales.

Una advertencia sobre diferencias de software: otras herramientas (como Claude Code) conservan integraciones para conexiones SSE obsoletas; Codex documenta únicamente el soporte para STDIO y HTTP Streamable, lo que simplifica la configuración al omitir flujos SSE. Limítate a estas dos opciones.

Compara las rutas de conexión en este esquema:

Este esquema ilustra el flujo: las utilidades integrada en Codex acceden únicamente a los recursos locales de la izquierda; la interfaz MCP proporciona conexiones STDIO (procesos del sistema locales) y HTTP Streamable (enlace web con credenciales) para añadir los recursos externos de la derecha.

💡 Resumen en una frase: Usa STDIO para utilidades locales (instrucción de ejecución, requiere disponer del entorno en la máquina) y Streamable HTTP para recursos web (URL y credenciales por token o iniciando sesión con codex mcp login); Codex limita el soporte a estos dos formatos.

---

03 Cómo añadir un servidor: comandos de consola frente a edición manual de config.toml

Definidos los tipos de servidor, revisemos la configuración. Existen dos alternativas y debes tener clara la regla de oro: toda la configuración de MCP se almacena en config.toml.

La documentación oficial señala:

Codex almacena la configuración de MCP junto con el resto de opciones en config.toml. Por defecto en ~/.codex/config.toml, aunque puedes definirlo en .codex/config.toml para limitar el uso de servidores MCP a un repositorio específico (requiere confiar en el proyecto).

Esta advertencia resalta la diferencia principal con Claude Code: allí controlas con --scope y en Codex la jerarquía se regula por la ruta del propio archivo:

Ruta de guardado	Alcance de proyectos	Propósito
~/.codex/config.toml (global)	Afecta a todos los repositorios	"Recursos que utilizo a diario de forma global"
.codex/config.toml en el proyecto	Limitado al repositorio activo (requiere confiar en el proyecto)	"Servidor específico y exclusivo de este proyecto"

Además, las herramientas de CLI y las extensiones de IDE leen el mismo archivo. Configurar un servidor en la terminal lo habilitará de inmediato en la extensión de VS Code sin configurarlo por duplicado, facilitando el trabajo.

El "proyecto confiable" es una directriz del sistema de seguridad (explicada al detalle en los artículos 15 y 16 sobre permisos y límites). El archivo .codex/config.toml local del proyecto solo se carga si has aceptado confiar en la carpeta, impidiendo que repositorios descargados ejecuten servidores no deseados.

Vía 1: Con comandos de codex mcp (el método rápido)

Añade un servidor STDIO con codex mcp add, teniendo en cuenta que la instrucción de ejecución debe declararse tras los caracteres --:

codex mcp add <nombre_del_servidor> --env VAR1=VALOR1 -- <comando_de_arranque_stdio>

Ejemplo oficial para añadir el servidor Context7 (documentación de desarrollo gratuita):

codex mcp add context7 -- npx -y @upstash/context7-mcp

El bloque npx -y @upstash/context7-mcp tras -- define la instrucción de arranque (-y fuerza la instalación sin solicitudes). Revisa las opciones de la consola ejecutando codex mcp --help. Si agregas un servidor HTTP compatible con OAuth, inicia sesión con codex mcp login <nombre_del_servidor>.

Durante una sesión de chat (CLI o app), comprueba los servidores activos escribiendo:

/mcp

Vía 2: Edición manual de config.toml (ajustes detallados)

Para restringir herramientas, ajustar tiempos de espera o definir permisos específicos, edita el archivo config.toml agregando un bloque [mcp_servers.<nombre_del_servidor>]:

Servidores STDIO (como el caso de Context7 anterior):

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

Los parámetros son descriptivos: command indica el comando del sistema y args los argumentos de ejecución. Admite opciones adicionales como env (variables de entorno), cwd (directorio de trabajo) y env_vars (variables a reenviar al subproceso).

Servidores HTTP Streamable (ejemplo oficial para la conexión con Figma):

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"

El parámetro url especifica la dirección de conexión y bearer_token_env_var la variable de entorno que almacena el Bearer token; nunca guardes el token en texto plano en la configuración, declara solo la variable (para evitar subirlos a Git). Permite configurar cabeceras HTTP mediante http_headers (valores estáticos) o env_http_headers (leídas del entorno).

ℹ️ Este config.toml coincide con el archivo detallado en el artículo 18; la sección de MCP se almacena bajo el bloque mcp_servers. Ambos métodos modifican el mismo archivo: codex mcp add escribe los parámetros automáticamente y la edición manual los define directamente.

💡 Resumen en una frase: Toda la configuración de MCP en Codex reside en config.toml (sin parámetro --scope, regulándose por guardar el archivo en ~/.codex/ o en .codex/ del proyecto); añade servidores con codex mcp add (con la instrucción tras --) o editando la tabla [mcp_servers.<nombre>], compartida entre la consola y las extensiones.

---

04 Restringir un servidor: habilitar, limitar herramientas y ajustar permisos

Añadir el servidor no implica otorgarle acceso ilimitado. Codex proporciona variables en config.toml para restringir el comportamiento de cada servidor: qué herramientas están activas, tiempos de espera o solicitudes de aprobación.

Analogía: Otorgar la tarjeta de acceso a un becario. Evitarás proporcionarle una tarjeta maestra que abra todas las dependencias del edificio; en su lugar, habilitarás "salas de reuniones autorizadas, exclusión de servidores de red, inhabilitación automática tras la jornada laboral o confirmación previa para zonas de finanzas". Definir los permisos de un servidor MCP funciona de forma idéntica: el servidor ofrece una suite de herramientas y tú configuras cuáles permitir, cuáles bloquear y cuáles confirmar en cada uso.

Detallemos las variables habituales según la documentación oficial:

Variable	Propósito	Valores y comportamiento
enabled	Desactivar temporalmente el servidor sin borrarlo	false para apagarlo
enabled_tools	Lista blanca (solo permite estas herramientas)	Permite todas si se omite
disabled_tools	Lista negra (se aplica restando de la lista blanca)	—
default_tools_approval_mode	Estrategia de aprobación para este servidor	auto / prompt / approve
startup_timeout_sec	Límite de tiempo de arranque (segundos)	10 por defecto
tool_timeout_sec	Límite de tiempo de ejecución de herramienta (segundos)	60 por defecto

Aclaraciones importantes:

La lista blanca tiene prioridad sobre la lista negra. La documentación especifica que disabled_tools se aplica "después de procesar enabled_tools". Esto permite definir un conjunto amplio en la lista blanca y sustraer herramientas específicas de riesgo con la lista negra. El ejemplo oficial con Chrome DevTools ilustra esta lógica: declarar enabled_tools = ["open", "screenshot"] y restar con disabled_tools = ["screenshot"] deja únicamente open disponible.

Los tres valores de default_tools_approval_mode regulan las solicitudes de aprobación para este servidor en concreto, no los confundas con los modos generales de sandbox:

• auto: permite a Codex decidir según sus directrices por defecto.
• prompt: requiere confirmación del usuario en cada uso.
• approve: autoriza la ejecución automáticamente sin preguntar (confianza plena).

Puedes además declarar tools.<nombre_de_herramienta>.approval_mode para sobreescribir reglas específicas: por ejemplo, autorizar por defecto el servidor pero forzar la confirmación manual para herramientas que modifiquen archivos.

Los tiempos de espera por defecto son: 10 segundos para el arranque y 60 segundos para la ejecución. Al probar un servidor local pesado que tardaba varios segundos en arrancar, el límite de 10 segundos provocaba fallos de inicio constantes; tras diagnosticar que se debía a startup_timeout_sec, aumenté el valor para solucionarlo:

[mcp_servers.slow_server]
command = "python"
args = ["-m", "slow_server"]
startup_timeout_sec = 30   # Incrementar para servidores con arranque lento
tool_timeout_sec = 120     # Incrementar para herramientas de ejecución larga

Veamos una configuración consolidada que aprovecha estos parámetros:

[mcp_servers.chrome_devtools]
url = "http://localhost:3000/mcp"
enabled_tools = ["open", "screenshot"]
disabled_tools = ["screenshot"]          # Se aplica tras la lista blanca, quedando solo open
default_tools_approval_mode = "prompt"   # Solicita confirmación en cada uso por defecto
startup_timeout_sec = 20
enabled = true

[mcp_servers.chrome_devtools.tools.open]
approval_mode = "approve"                # Habilita open automáticamente sin preguntar

💡 Resumen en una frase: Editar manualmente config.toml permite un control exhaustivo: enabled para encender o apagar, enabled_tools y disabled_tools para restringir herramientas (lista blanca tiene prioridad), default_tools_approval_mode para regular aprobaciones (con sobreescrituras por herramienta) y límites de tiempo personalizables.

---

05 Seguridad en servidores de terceros: auditar antes de conectar

Esta sección es breve pero esencial: complementa directamente las advertencias de seguridad del artículo 16.

La pauta de seguridad es simple: los servidores MCP son desarrollos de terceros y OpenAI no audita su código. Conectar un servidor STDIO permite a Codex ejecutar un proceso externo en tu máquina; enlazar un servidor HTTP para recopilar recursos de la red introduce datos externos en el contexto del modelo. Ambas acciones implican riesgos.

Analogía: Añadir una dependencia externa a tu código en producción. Evitarás instalar aleatoriamente con npm install una librería desconocida y sin mantenimiento; antes auditarás su comunidad, autores y popularidad. Los servidores MCP son equivalentes a estas dependencias de terceros: comprueba su fiabilidad antes de integrarlos, especialmente si acceden a páginas web, incidencias o documentos.

¿Por qué los servidores que recopilan recursos web implican mayor riesgo? Porque actúan como vehículo para inyecciones de prompts (prompt injection), como detallamos en el artículo 16. La documentación web recopilada puede ocultar directrices diseñadas para manipular el comportamiento de Codex al asimilarlas. De ahí la utilidad de las restricciones de herramientas y aprobaciones de la sección 04: forzar prompt (confirmación manual) para servidores nuevos e inhabilitar herramientas sensibles con disabled_tools detiene los ataques en el origen.

Recomendaciones prácticas para la integración de servidores:

Escenario	Criterio
Servidores recomendados oficialmente (OpenAI Docs, Context7, Figma, Playwright...)	✅ Fiable
Servidores de proveedores oficiales conocidos (GitHub, Sentry...)	✅ Fiable
Repositorio externo con pocas estrellas en GitHub	⚠️ Audita el código de origen antes de integrarlo
Configurar default_tools_approval_mode = "approve" (ejecución automática)	⚠️ Exclusivo para servidores de absoluta confianza
Otorgar permisos de escritura en bases de datos de producción	❌ Limita el acceso a solo lectura, evita la escritura

La regla de oro: aplica el principio de mínimo privilegio otorgando solo lectura cuando sea posible para minimizar riesgos. Aunque el sandbox y la estrategia de aprobación de Codex (artículos 15 y 16) actúan como cortafuegos, ninguna protección detendrá un servidor malicioso si lo autorizas expresamente para ejecutarse de forma automática.

💡 Resumen en una frase: Los servidores MCP son códigos de terceros no auditados por OpenAI; prioriza utilidades oficiales o recomendadas, desconfía de inyecciones de prompts en contenidos web, usa prompt por defecto para herramientas nuevas y restringe los accesos de escritura.

---

06 Manos a la obra: conectar el servidor de documentación Context7 y verificar su uso

La teoría sin práctica no sirve. Conectaremos Context7, un servidor gratuito y recomendado en la documentación oficial para consultar documentación de desarrollo actualizada, sin requerir cuentas de pago y con configuración mínima.

⚠️ Requisitos: Context7 se ejecuta mediante npx, requiriendo disponer de Node.js en el sistema (comprueba con node -v en la consola). Requiere conexión a internet para descargar la documentación; comprueba tu red en caso de fallos de conexión.

Primer paso: Añadir el servidor (en la terminal de comandos, fuera del chat de codex)

codex mcp add context7 -- npx -y @upstash/context7-mcp

Resultado esperado: la consola confirma que el servidor context7 se ha añadido correctamente. El comando escribe automáticamente la sección [mcp_servers.context7] en ~/.codex/config.toml (como vimos en la sección 03); puedes abrir el archivo para comprobarlo.

Segundo paso: Iniciar la sesión de chat y comprobar la conexión

codex

Escribe en el chat para listar los servidores activos:

/mcp

Resultado esperado: context7 figura en la lista en pantalla, lo que demuestra que se ha cargado. Si no aparece, comprueba la instalación de Node.js o los parámetros de red.

Tercer paso: Pedir expresamente usar el servidor para buscar documentación

Realiza una consulta solicitando consultar la documentación en tiempo real (forzando el uso de Context7 en lugar de sus conocimientos integrados):

Usa Context7 para consultar cómo configurar las rutas en la versión más reciente de React Router, y muéstrame la sintaxis de la documentación oficial.

Codex invocará las herramientas de Context7 para obtener los documentos más recientes; según tus ajustes de permisos, el primer uso del servidor detendrá la sesión para solicitar tu aprobación (el flujo de permisos de las secciones 04 y 05), acéptalo. Devolverá la sintaxis de la documentación oficial actualizada en lugar de su historial antiguo. Podrás auditar el uso de Context7 durante la ejecución para verificar que la información proviene del exterior.

Cuarto paso: Limpieza (opcional)

Si deseas eliminar el servidor tras la prueba, elige una opción:

codex mcp --help

Consulta el comando de borrado oficial en la ayuda (según indique codex mcp --help en tu sistema); o bien edita ~/.codex/config.toml directamente eliminando la sección [mcp_servers.context7] o agregando enabled = false para desactivarlo, ya que modificar el archivo produce el mismo efecto.

Completar este flujo consolida el ciclo: "añadir servidor → comprobar conexión → invocar con permisos → limpiar". El proceso es idéntico para cualquier otro servidor en el futuro, variando únicamente el nombre, la instrucción de arranque o URL y los permisos asignados en config.toml.

💡 Resumen en una frase: Context7 es idóneo para iniciarse: agrégalo con codex mcp add, comprueba con /mcp, realiza una consulta en el chat para autorizar su uso y modifícalo en config.toml para borrarlo; la práctica es el mejor método de aprendizaje.

---

07 Resumen

En este artículo hemos enlazado a Codex con el exterior: pasando de utilidades estrictamente locales a un conector multipuerto para acceder a todo tipo de recursos gracias a MCP.

Repasemos las pautas consolidadas:

Objetivo	Canal / Herramienta	Puntos clave
Qué es MCP	Estándar de integración abierto	Conecta recursos que Codex no accede por defecto; lee instructions como guía de uso
Conectar utilidades locales	Servidores STDIO	Requiere instrucción de terminal (npx ...) y disponer del entorno en el sistema
Conectar servicios web	Servidores HTTP Streamable	Requiere URL de conexión y token o iniciar sesión con codex mcp login
Definir el alcance de uso	Ubicación del archivo	Sin parámetro --scope; regulado por ~/.codex/config.toml (global) o .codex/config.toml (proyecto)
Añadir un servidor	Consola o edición manual	La instrucción de arranque se declara tras --; compartido entre CLI y extensiones
Restringir herramientas y permisos	Parámetros de config.toml	Variables como enabled, listas blancas o negras, default_tools_approval_mode y límites de tiempo
Seguridad en desarrollos externos	Auditoría de origen	OpenAI no audita el código; desconfía de inyecciones de prompts, forzando prompt y solo lectura

Ahora deberías ser capaz de: comprender qué limitaciones resuelve MCP; diferenciar y configurar servidores STDIO y HTTP; gestionar el alcance por la ubicación del archivo omitiendo el parámetro --scope; añadir servidores con la consola o en config.toml consultando con /mcp; restringir el uso de herramientas con enabled_tools o default_tools_approval_mode; y auditar la fiabilidad de servidores de terceros antes de conectarlos. Esta conectividad externa es la llave para convertir a Codex de asistente local a gestor de tu ecosistema de desarrollo.

Evita el error del inicio: recuerda que Codex carece de --scope, almacena todo en config.toml y la instrucción de ejecución se escribe tras -- para no malgastar tiempo de configuración.

---

El próximo artículo [21 · Subagentes (Subagents)]: MCP incrementa las capacidades de Codex, pero el volumen de tareas puede sobrecargar el contexto del modelo. El siguiente capítulo aborda una estrategia alternativa: en lugar de exigir todo a un único agente, delegaremos en un equipo de subagentes especializados con contextos independientes: el agente principal distribuye el trabajo y los subagentes operan en paralelo sin contaminar sus contextos. Analízalo: delegar la búsqueda de documentación, la escritura de pruebas y la compilación a diferentes subagentes autónomos que trabajan simultáneamente es mucho más eficiente que gestionarlo todo con un solo Codex.

---

Lecturas recomendadas

• Los cuatro flujos de trabajo habituales: exploración, depuración, refactorización y pruebas
• Elección de modelos: cómo decidir qué modelo ejecutar en cada consulta
• Instrucciones de AGENTS.md: integrar directrices obligatorias en el inicio de Codex