VS Code ya mezcla Claude y Codex en la misma superficie: por qué los agentes de terceros sí cambian el trabajo diario
La documentación oficial de Visual Studio Code publicada a inicios de junio de 2026 ya permite usar Claude y Codex como agentes de terceros dentro de la misma experiencia. La novedad útil no es otro selector de modelo: es unificar sesiones, debugging y revisión sin cambiar de editor.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
La pelea entre agentes de coding suele presentarse como si todo se resolviera eligiendo modelo. En práctica, buena parte del costo diario viene de otra cosa: cambiar de superficie, perder estado entre sesiones y salir del editor cada vez que quieres probar otro agente.
La documentación oficial de Visual Studio Code cambió bastante ese cuadro en los primeros días de junio de 2026. La nueva guía de third-party agents deja claro que Claude y OpenAI Codex ya pueden convivir dentro de la misma experiencia de agentes en VS Code, con sesiones unificadas, debugging, testing y gestión compartida desde Copilot.
La novedad real no es “usar más modelos”
Eso ya se podía resolver de formas más artesanales. La señal importante aquí es otra: VS Code usa el SDK y el harness del proveedor, pero mantiene la experiencia de sesión del editor.
La documentación lo baja con bastante claridad. Los agentes de terceros:
- corren con las capacidades propias del proveedor;
- se benefician del mismo manejo de sesiones en VS Code;
- y aprovechan el editor para debugging, testing y revisión de cambios.
Traducido a builder: ya no es solo “abre Claude aquí” o “abre Codex allá”. Ahora puedes mover trabajo entre agentes sin desmontar todo el flujo operativo alrededor.
Por qué eso sí importa para tráfico cualificado
La intención detrás de búsquedas como claude agent vscode, codex vscode, third-party agents vscode o copilot partner agent no es decorativa. La hace gente que ya está comparando cómo trabajar de verdad con agentes, no solo cómo probar un prompt.
Además, GitHub ya venía empujando esa dirección en su changelog de junio: Agents window en Stable preview, sesiones remotas, historial sincronizado y mejor soporte para trabajos largos. La pieza nueva es que esa superficie ya no vive encerrada en el agente nativo de Copilot.
Eso tiene tres efectos prácticos:
- puedes probar fortalezas distintas sin cambiar de herramienta principal;
- el costo de contexto baja porque el editor sigue siendo el mismo;
- y revisar cambios deja de depender del cliente propio de cada proveedor.
Dónde sí le veo valor
Equipos que alternan entre estilos de agente
Hay equipos que prefieren Claude para orquestación larga y otros que quieren probar Codex por su integración con flujos de código y herramientas. Si todo vive dentro de la misma superficie, comparar deja de ser una migración y se vuelve una decisión reversible.
Trabajo que exige editor completo
La misma documentación insiste en el punto correcto: el valor no es solo chatear. Es mezclar agente con:
- debugging;
- testing;
- revisión de diffs;
- y manejo de workspace.
Eso es bastante más serio que una integración lateral.
Sesiones cloud con menos fricción
También importa que el soporte cloud se habilite desde el plan de Copilot y que no exija instalar la extensión del proveedor para usar su agente en la nube. Para un equipo eso reduce setup, soporte y diferencias entre máquinas.
El límite que no conviene esconder
No todo está resuelto. La guía oficial también marca que los third-party coding agents in the cloud siguen en preview. Y eso importa porque preview no es lo mismo que flujo endurecido para toda una organización.
Tampoco conviene vender esto como neutralidad total. VS Code mantiene la experiencia de sesión, sí, pero cada proveedor sigue trayendo su propio SDK, su propio harness y sus propias capacidades. La unificación mejora la operación; no borra las diferencias reales entre agentes.
Mi criterio práctico
Yo pondría esta nota frente a cualquier equipo que hoy esté en una de estas dos situaciones:
- ya trabaja en VS Code y quiere comparar agentes sin abrir otra superficie;
- o ya entendió que el cuello de botella no es solo el modelo, sino la sesión completa: contexto, revisión, terminal y validación.
Si todavía estás ordenando memoria, instrucciones y disciplina mínima antes de meter varios agentes en el mismo loop, empieza por el curso gratis. Y si quieres bajar un nivel más técnico sobre por qué el resultado cambia aunque el modelo sea bueno, esta historia conversa muy bien con el harness de Copilot en VS Code.
La lectura corta es esta: VS Code no solo está añadiendo otro partner agent; está intentando convertirse en la capa donde eliges agente sin romper tu flujo de trabajo.