
VS Code multi-agente: Claude, Codex y Copilot con MCP
TL;DR
VS Code dejó de ser el IDE de un solo asistente. Con MCP (Model Context Protocol) como capa común, Claude Code, Codex y Copilot conviven en paneles separados, comparten tools y permiten cambiar de agente sin salir del editor. El riesgo principal: dos agentes trabajando sobre el mismo repo pisan archivos si no coordinas sesiones. Aquí va el setup mínimo, cuándo usar cada agente y los patrones que evitan conflictos.
Por qué este cambio importa ahora
Hasta hace poco, elegir agente de código era elegir IDE. Cursor estaba pegado a Anthropic-friendly, Copilot vivía en VS Code, y Claude Code en su CLI. Microsoft ha formalizado un giro: VS Code ahora es el hogar de múltiples agentes con MCP como protocolo común.
El resultado práctico: puedes lanzar Claude Code para refactorizar un módulo grande, dejarlo en background, y pedir a Copilot un autocompletado puntual en el mismo proyecto sin cambiar de ventana. La consecuencia menos obvia es que cambia tu forma de organizar tareas: el agente deja de ser una elección estratégica y pasa a ser una decisión táctica por tarea.
¿Qué es MCP en una frase?
MCP (Model Context Protocol) es un protocolo abierto creado por Anthropic que permite a cualquier agente de IA acceder a herramientas externas (bases de datos, APIs, sistemas de archivos) de forma uniforme. A mayo de 2026, lo soportan nativamente Claude, mediante adaptadores oficiales Codex y Copilot, y la lista crece cada semana.
Si quieres ir más profundo en cómo blindar esas integraciones, el post sobre contratos para MCP en Claude Code cubre el patrón de validación que evita que un cambio del servidor reviente el agente.
El stack en VS Code: paneles, sesiones y agentes
La integración tiene tres piezas que conviene distinguir antes de tocar configuración:
- Paneles de agente: cada agente vive en su panel lateral con su propio historial. El atajo por defecto es
Ctrl+Alt+Ipara abrir el panel activo. - Sesiones background: puedes dejar a Claude Code trabajando mientras editas o usas Copilot inline. Las sesiones largas no bloquean el editor.
- MCP servers compartidos: si añades un servidor MCP (por ejemplo GitHub o Postgres), está disponible para todos los agentes que lo soporten.
La clave conceptual: MCP es la capa común, pero cada agente sigue teniendo su propio system prompt y sus propios tools nativos. Por eso un mismo modelo responde distinto según quién lo invoque.
Cuándo usar cada agente
Esta es la tabla que uso para decidir sin pensarlo dos veces:
| Tarea | Agente recomendado | Por qué |
|---|---|---|
| Refactor grande multi-archivo | Claude Code | Sesiones largas, contexto extendido, ejecución autónoma |
| Autocomplete inline mientras escribes | Copilot | Latencia mínima, integración nativa con el cursor |
| Análisis exploratorio o algorítmico | Codex | Reasoning fuerte en problemas matemáticos o de complejidad |
| Code review semiautomático | Claude Code + skills | Reglas reutilizables en SKILL.md, aplicables a todo el repo |
Si todavía no has separado responsabilidades entre skills y subagentes, el artículo sobre skills y subagentes como ladrillo base es buena lectura previa.
Setup mínimo: añadir un MCP server compartido
Configurar un MCP server en VS Code requiere un archivo de definición que todos los agentes compatibles leen. Ejemplo para conectar una Postgres local:
// .vscode/mcp.json — define un MCP server local accesible a Claude y Copilot
{
"servers": {
"postgres-local": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost/dev"
],
"env": {}
}
}
}
Tras guardar el archivo y recargar la ventana (Ctrl+Shift+P → Reload Window), ambos agentes ofrecen los tools del servidor (query, schema, list-tables) sin configuración adicional. Si manejas Postgres desde Node, en su día expliqué cómo usar Prisma para gestionar bases de datos; combinar Prisma con un MCP server te da un agente que entiende tu schema sin tener que explicárselo.
El riesgo real: dos agentes, un repo
El conflicto más habitual aparece cuando ejecutas dos agentes en paralelo sobre los mismos archivos. Claude Code edita auth.py mientras Copilot Chat propone cambios en el mismo fichero desde otro panel. Resultado: el último que guarda machaca al anterior, y el git diff queda incoherente.
Patrones que evitan el problema:
- Worktrees git: cada agente trabaja en su worktree, sobre la misma base pero con archivos físicos distintos. Eliminas el conflicto a nivel filesystem.
- División por capa: Claude para backend, Copilot para frontend. Sin solape físico, sin riesgo.
- Sesiones secuenciales: termina la sesión de un agente antes de empezar la del otro si comparten ficheros. Menos óptimo, más seguro.
Para casos donde necesitas aislar al agente del resto del sistema, el post sobre sandbox para agentes de código explica las opciones de aislamiento que ya están listas para producción.
En producción
Algunas consideraciones cuando quieres llevar este flujo a un equipo real, no solo a tu setup personal:
- Coste duplicado: Claude Code (suscripción Max o API) más Copilot (10-19€/mes) suma rápido. En escenarios reales, conviene auditar uso de cada agente antes de pagar ambos. Si el 80% del valor lo aporta uno, cancela el otro.
- Política de secretos: cada MCP server puede exponer credenciales si no aíslas el entorno. Usa
.envseparado por proyecto y revisa permisos del servidor antes de exponerlo a un agente que puede ejecutar comandos. - Logs y auditoría: VS Code centraliza logs de agentes en
Output → Agent Activity. Es el primer sitio donde mirar tras un postmortem si un agente toca lo que no debe. - Reglas compartidas: con 2-3 devs basta convenir quién usa qué agente. En equipos de 10+, conviene reglas explícitas en
CLAUDE.mdyAGENTS.mdversionados, una capa que conecta con la idea de separación de responsabilidades aplicada a herramientas, no solo a clases.
Errores comunes y depuración
- Error: el MCP server no aparece en Claude Code → Causa: el archivo está en
.vscode/mcp.jsonpero Claude Code lee de~/.claude/mcp.jsonpor defecto → Solución: duplica la definición o usa un enlace simbólico. - Error: Copilot ignora cambios hechos por Claude en background → Causa: el caché interno de Copilot no se invalida cuando otro proceso modifica el archivo → Solución:
Ctrl+Shift+P → Reload Windowtras sesiones largas. - Error: conflict markers en git tras usar ambos agentes → Causa: edición concurrente sin worktree → Solución: divide el trabajo en worktrees separados por agente o usa la opción de checkpoints del propio VS Code antes de cada sesión.
- Error: el agente lee secretos del proyecto vecino → Causa: workspace multi-root con un
.envcompartido → Solución: separa workspaces, nunca compartas.enventre proyectos con agentes activos.
Preguntas frecuentes
¿Sustituye VS Code multi-agente a Cursor?
Depende del flujo. Cursor sigue ganando en inline editing fluido y composer multi-archivo cuando trabajas a alta velocidad. VS Code multi-agente gana cuando ya pagas Copilot y quieres añadir Claude Code o Codex sin cambiar de editor, especialmente en equipos donde VS Code ya es estándar.
¿Necesito licencia separada para cada agente?
Sí. Cada agente factura por su lado: Copilot vía GitHub, Claude Code vía Anthropic (suscripción Max o API), Codex vía OpenAI. VS Code es solo el contenedor, no incluye créditos ni descuento por usar varios agentes juntos.
¿Funciona MCP con todos los modelos a la vez?
A mayo de 2026, MCP es estándar para Claude (nativo) y compatible con Codex y Copilot mediante adaptadores oficiales. Modelos open-source como Llama o Qwen necesitan un wrapper adicional, y la cobertura de tools varía según la implementación.
Cierre
VS Code como hub multi-agente cambia menos el modelo y más el flujo de trabajo. La pregunta ya no es qué agente uso, sino cómo dividir las tareas entre ellos sin pisarte. Si vienes de una sesión única con Claude Code, empieza añadiendo Copilot solo para autocompletado, mantén Claude para sesiones largas y mide si tu factura conjunta compensa el ahorro de tiempo real.
El siguiente paso natural es configurar MCP servers privados para tu equipo sin exponer secretos, algo que conecta con todo lo que hemos visto sobre arquitectura de agentes. ¿Has probado ya combinar agentes en VS Code? Cuéntamelo en Twitter @sergiomarquezp_ o en los comentarios del blog.


