Copilot ya controla navegador en VS Code GA: útil para QA, peligroso sin dominios y tabs aisladas

GitHub publicó el 1 de julio de 2026 que Browser Tools para GitHub Copilot en VS Code ya están en disponibilidad general. La mejora hace que el agente pueda abrir un navegador real, navegar una app viva, hacer clic, escribir, leer errores de consola, tomar capturas y devolver esa evidencia al chat.

Para equipos que usan agentes de coding, esto cambia el estándar mínimo de cierre. Si el agente toca frontend, ya no basta con "compila" o "los tests pasaron". Ahora puede verificar el flujo en navegador, encontrar errores que solo aparecen con DOM, estado, red o permisos, y volver con una corrección más aterrizada.

Lo que sí cambia para el builder

La noticia no es que un agente pueda mirar una captura. Eso ya existía en varias formas. El salto práctico es que el navegador queda dentro del loop de desarrollo de VS Code: el agente puede probar una página, observar el resultado y ajustar código sin que el humano copie logs entre herramientas.

El caso más claro es QA de interfaces. Una tarea como "arregla el formulario de registro en mobile" puede volverse más verificable si el agente:

• abre la ruta exacta;
• reproduce el flujo;
• lee consola y errores de red;
• toma screenshot cuando falla;
• ajusta código;
• vuelve a probar el mismo flujo.

Eso ayuda especialmente en equipos pequeños de Latinoamérica que no tienen una suite Playwright completa para cada pantalla. No reemplaza tests, pero reduce la zona gris entre "parece bien en el diff" y "funcionó en un navegador real".

El control no es un detalle

La parte importante del changelog está en los límites. GitHub dice que las tabs humanas son privadas por defecto: el agente no puede leer ni interactuar con una página abierta por el usuario hasta que se comparta con él. Las tabs que abre el agente corren en sesiones frescas, sin cookies ni storage del navegador diario.

También hay permisos sensibles que no se conceden automáticamente: cámara, micrófono, ubicación, notificaciones y lectura del portapapeles requieren aprobación explícita. Ese diseño importa porque un agente con navegador puede ver pantallas autenticadas, tocar acciones reales o activar permisos que nunca pondrías en un script de CI.

Para organizaciones, el control aterriza en settings: un switch dedicado para activar o desactivar browser tools y reglas de dominios permitidos o denegados para restringir qué sitios pueden alcanzar los agentes y el navegador integrado. Si vas a usar esto en serio, esas reglas deberían vivir junto a tus instrucciones de agente, no en la memoria de una persona.

Checklist antes de activarlo en equipo

Yo no lo encendería como "todo vale". Lo pondría en una política simple:

1. Crear un perfil o entorno de prueba sin cuentas personales.
2. Definir dominios permitidos para staging, docs y APIs públicas.
3. Bloquear dominios de finanzas, correo, paneles internos sensibles y producción si no hay razón explícita.
4. Exigir que el agente deje evidencia: URL, pasos, error observado y captura cuando aplique.
5. Separar tareas de exploración de tareas con escritura real.

El punto no es desconfiar del agente por deporte. Es evitar que una herramienta útil se convierta en un navegador con permisos ambiguos.