VS Code multi-agente: Copilot, Claude y Codex, cada uno a su ritmo

Google apagó Gemini Code Assist y el CLI de Gemini para cuentas individuales el 18 de junio de 2026, sin periodo de gracia: quien tenía ese agente configurado en VS Code se encontró el comando sin responder de un día para otro, mientras Google empujaba a los usuarios afectados hacia Antigravity. Los otros tres agentes que competían por el mismo hub -- Copilot, Claude y Codex -- no desaparecieron, pero tampoco conviven hoy en igualdad de condiciones: desde julio, VS Code despliega de forma gradual un Agent Host común, opcional y detrás de settings distintos para cada uno, no un proceso que los tres compartan ya por defecto. La lista de quién vive hoy en VS Code cambió de forma más concreta -- y más desigual -- que cualquier titular sobre "IA en el IDE".

El Agent Host: una arquitectura nueva, no un hecho consumado

VS Code 1.109, publicado en enero de 2026, fue la primera versión que dejó correr a Claude y Codex junto a Copilot dentro del mismo editor, con una vista de Agent Sessions que unificaba sesiones locales, en segundo plano y en la nube, y con soporte para lanzar varios subagentes en paralelo dentro de una misma tarea. La arquitectura de fondo cambió con la versión 1.129, publicada el 15 de julio de 2026: VS Code empezó a desplegar de forma gradual un Agent Host, un proceso separado construido sobre el Agent Host Protocol que permite que una misma sesión se renderice en varias ventanas a la vez. No es un cambio universal ni automático -- exige activar chat.agentHost.enabled -- y cada agente lo adopta a un ritmo distinto.

Copilot ya corre sobre esa infraestructura por defecto. Claude puede ejecutarse ahí, pero sigue conviviendo con su modo tradicional en el extension host y necesita habilitarse explícitamente. Codex, en cambio, sigue arrancando por defecto desde la extensión de OpenAI para VS Code; moverlo al Agent Host es todavía experimental y exige activar dos settings aparte, chat.agentHost.codexAgent.enabled y chat.editor.codex.preferAgentHost, según la documentación de harnesses de agentes. La ventana de Agents deja elegir el harness desde un desplegable -- Copilot, Claude o Codex --, pero la disponibilidad real depende de qué settings tenga activados cada instalación; Gemini no figura entre las opciones en ningún caso.

Dentro de Copilot Chat, en cambio, un modelo Gemini todavía puede elegirse como motor de respuesta (Gemini 3.1 Pro en preview, 3.5/3.6 Flash en disponibilidad general, según el catálogo de modelos soportados de Copilot): es la selección de modelo del propio Copilot, no el agente ni la extensión dedicada que sostenía la idea de un hub con Gemini como pieza propia -- esa pieza es la que desapareció. Los otros dos agentes también cambiaron de motor por debajo: Claude ofrece hoy la familia Opus 5 y Sonnet 5, y Codex se apoya en GPT-5.6 (Sol, Terra y Luna). Cualquier comparación que cite versiones anteriores ya describe un editor distinto del actual.

El riesgo real: dos agentes, un repo

Meter dos agentes autónomos a trabajar sobre el mismo checkout no es gratis: si Claude está refactorizando un módulo mientras Codex toca un archivo adyacente en la misma franja de tiempo, el conflicto de edición concurrente aparece igual que si fueran dos personas, con la diferencia de que ninguno de los dos pide permiso antes de escribir. Tres mitigaciones cubren la mayoría de los casos, y ninguna es automática -- el editor no elige por el equipo cuál aplicar:

• Worktrees de git: cada agente trabaja en su propia copia física del repositorio hasta que el cambio está listo para revisión y merge. La casilla "New Worktree" ya cubre a Copilot, Claude y Codex por igual, según la documentación de harnesses, con dos límites que conviene conocer: el worktree solo copia archivos ya confirmados (committed) de la rama base -- lo sin commitear o sin seguimiento queda fuera salvo que se liste en git.worktreeIncludeFiles --, y sus sesiones suelen activar "Bypass Approvals", que aísla el árbol de archivos pero no restringe comandos ni red fuera de esa carpeta.
• División por capa: asignar a cada agente una porción del sistema que no se solape con la del otro (backend a uno, frontend a otro) evita el problema en vez de mitigarlo, pero exige una frontera real, no solo de carpetas -- un cambio de contrato de API la rompe igual.
• Sesiones secuenciales: terminar el trabajo de un agente, revisarlo y solo entonces lanzar al siguiente. Es la opción más lenta y la más segura cuando el cambio toca lógica compartida que ningún límite de capa protege.

Elegir mal -- por ejemplo, dividir por capa un cambio que en realidad cruza capas -- reproduce el mismo conflicto que se quería evitar; el worktree reduce la fricción de montar el aislamiento, pero no decide por el equipo cuándo hace falta ni cubre nada fuera de su propia carpeta.

Dónde vive cada configuración MCP

Configurar MCP en este hub implica hasta tres archivos distintos, no uno. Para VS Code como editor, el archivo es mcp.json dentro de .vscode/, con la clave servers:

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp"
    }
  }
}

Para Claude Code (el harness o la extensión propia), la documentación oficial de MCP en Claude Code distingue tres scopes que caben en solo dos archivos: el scope de proyecto vive exclusivamente en .mcp.json, en la raíz del repo, pensado para compartirse en el repositorio; los scopes local y user viven ambos en ~/.claude.json (el local anidado bajo la ruta del proyecto, el user a nivel global). Ambos usan la clave mcpServers:

{
  "mcpServers": {
    "shared-server": {
      "type": "http",
      "url": "https://example.com/mcp"
    }
  }
}

El nombre de archivo casi coincide entre VS Code y Claude Code, pero no es el mismo: mcp.json sin punto inicial dentro de .vscode/, frente a .mcp.json con punto inicial en la raíz del repo. Y no existe un ~/.claude/mcp.json -- esa ruta circula en guías de terceros y basta con probarla en una shell para descartarla. Hay además un matiz reciente: con el Agent Host activo, VS Code no lee la configuración propia del editor (.vscode/mcp.json) directamente para las sesiones de Claude o Codex -- la reenvía al Agent Host, salvo para los servidores que necesitan entrada interactiva. Si un servidor MCP funciona en Copilot Chat pero no aparece en una sesión de Claude dentro del mismo editor, la documentación de MCP en VS Code recomienda declararlo en el archivo portable que ambos caminos leen igual: .mcp.json o ~/.copilot/mcp-config.json.

La factura que no esperabas

Elegir "Claude" en el desplegable del Agent Host no fija por sí solo quién paga. GitHub abrió el acceso a Claude y Codex desde dentro de Copilot en vista previa pública para Pro+ y Enterprise el 4 de febrero de 2026, y lo extendió a Business y Pro el 26 de febrero: "no se requieren suscripciones adicionales, el acceso está incluido en tu plan de Copilot existente", consumiendo entonces una premium request por sesión de agente. Ese esquema de medida cambió de fondo, no solo de nombre, el 1 de junio de 2026: GitHub dejó de contar interacciones con un multiplicador por modelo y pasó a tarificar por tokens de entrada, salida y caché, convertidos en AI credits, en los planes mensuales (los planes anuales previos a esa fecha conservan el esquema anterior si no migran).

Ese es el primer camino -- Claude como harness del Agent Host usando el proxy de Copilot, comportamiento por defecto. Existe un segundo camino, más reciente: un usuario relató en una petición de funcionalidad en el repositorio de VS Code -- cerrada el 26 de junio de 2026 -- haber gastado unos 300 dólares extra en una semana asumiendo que el harness de Claude tiraba de su propia suscripción de Anthropic. El issue derivó en una pull request ya fusionada que añade acceso nativo (BYOK): con claudeUseCopilotProxy: false, el SDK de Claude usa credenciales propias -- ANTHROPIC_API_KEY o un token vía CLAUDE_CODE_OAUTH_TOKEN -- sin pasar por el proxy, que sigue siendo la opción por defecto si no se cambia explícitamente. El tercer camino es instalar la extensión oficial de Claude Code o la de OpenAI para Codex por separado del Agent Host: ambas se autentican con una cuenta propia y facturan aparte, sin tocar la cuota de Copilot. Los tres son legítimos; lo que hace daño es no saber cuál se está usando antes de lanzar la sesión, justo lo que le pasó al autor de esa petición.

Cuándo usar cada agente

La pregunta que decide no es cuál agente es mejor en abstracto, sino qué necesita la tarea en contexto, autonomía y presupuesto -- y ahí Copilot, Claude y Codex compiten en terrenos distintos, no como sustitutos directos:

El caso habitual no es elegir uno y quedarse con él: es arrancar en Copilot para lo inmediato, subir a Claude cuando el cambio cruza varios archivos con contexto que no cabe en una sugerencia inline, y delegar a una sesión cloud lo que puede esperar sin que nadie mire la pantalla.

Si algo no aparece: checklist de depuración

Antes de asumir un bug del editor, esta secuencia descarta la mayoría de los casos en el orden en que conviene probarlos:

• Ejecutar "Developer: Reload Window" tras cualquier cambio de configuración MCP; sigue siendo el primer paso, no un parche cosmético.
• Confirmar el archivo y el scope correctos antes de sospechar de un fallo real: mcp.json dentro de .vscode/ para VS Code, .mcp.json para el scope de proyecto de Claude Code, ~/.claude.json para sus scopes local y user -- nunca ~/.claude/mcp.json.
• Lanzar la CLI de Claude Code desde la raíz del repo o un subdirectorio suyo: el scope de proyecto no carga si se lanza desde otra ruta, aunque .mcp.json exista en disco.
• Si el servidor atascado en "Connecting" es de Gemini Code Assist, primero identifica el tipo de cuenta. Para individuales, Google AI Pro o Google AI Ultra no hay parche que esperar: la extensión y el CLI dejaron de servir peticiones a esas cuentas el 18 de junio de 2026, y el issue que documentaba el propio bug de MCP quedó cerrado como not planned en mayo de 2026 -- es una integración retirada, no un bug pendiente. Para licencias Standard o Enterprise, que siguen funcionando sin cambios, el mismo síntoma sigue siendo un bug activo sin corrección confirmada.
• Si es la extensión de Claude Code en VS Code, no asumas que mover la configuración a .mcp.json arregla nada por sí solo: el reporte más citado sobre este síntoma -- un issue de la extensión, reproducido en macOS en la versión 2.1.38 -- tenía servidores declarados a la vez en el scope local (~/.claude.json) y en el de proyecto (.mcp.json), y la extensión no mostraba ninguno de los dos aunque la CLI los veía todos. El propio reporte contradice la idea de que cambiar de archivo sea la solución; se cerró por inactividad, sin corrección confirmada.