VS Code 1.127 pone el navegador dentro del loop del agente: pruebas y permisos por sitio
La versión 1.127 de Visual Studio Code, publicada el 1 de julio de 2026, convierte las browser tools de agentes en una capacidad general y añade permisos por sitio. El cambio útil para builders es cerrar el ciclo construir-probar-corregir sin entregar al agente una sesión web sin límites.
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.
Visual Studio Code 1.127, publicada el 1 de julio de 2026, lleva las browser tools de agentes a disponibilidad general. Un agente puede abrir una página, leerla, hacer clic, escribir, tomar capturas, revisar errores de consola y probar el resultado que acaba de construir. La misma versión añade permisos por sitio para cámara, micrófono, ubicación, dispositivos y otras APIs del navegador.
La combinación es más importante que cada novedad por separado. Un coding agent que solo modifica archivos necesita que una persona abra el navegador y confirme si la interfaz funciona. Con browser tools, VS Code intenta cerrar el loop construir → ejecutar → observar → corregir dentro del mismo entorno. Con permisos por sitio, el equipo puede decidir qué superficie web y qué dispositivos quedan dentro de ese loop.
Qué cambia en la práctica
Las herramientas incorporadas incluyen navegación, lectura de página, capturas, interacción con elementos y ejecución de código de Playwright. La guía oficial muestra un flujo deliberadamente pequeño: pedir una calculadora, abrirla en el navegador integrado, probar operaciones, detectar un fallo y pedir al agente que lo corrija.
El detalle de aislamiento también importa. Las páginas abiertas por el agente usan sesiones privadas en memoria que no comparten automáticamente cookies ni almacenamiento con tus otras pestañas. Si una persona comparte de forma explícita una página con el agente, entonces sí puede exponer la sesión existente. Son dos modos diferentes y deben tratarse como tal en una política interna.
La versión también reorganiza sesiones con grupos y arrastrar-y-soltar, muestra el consumo de créditos de subagentes y añade avisos para fallos de CI o comentarios de pull requests. Eso convierte al Agents window en una bandeja de trabajo más continua: el agente no solo ejecuta una tarea, también recibe el siguiente problema de validación.
Permisos por sitio: el límite que faltaba
El navegador integrado puede pedir acceso a geolocalización, cámara, micrófono, sensores, portapapeles, Bluetooth, USB, serie y HID. En vez de asumir que todos los dominios tienen el mismo nivel de confianza, VS Code muestra una decisión por sitio y permite administrar esos permisos desde el menú del navegador.
Para un prototipo local, eso puede parecer excesivo. Para un agente que valida flujos de autenticación, pagos, videollamadas o dispositivos físicos, es una frontera concreta. La política debería responder preguntas como estas:
- ¿El agente solo prueba
localhosty dominios de staging? - ¿Puede acceder a una cámara real o únicamente a un dispositivo simulado?
- ¿Qué ocurre si una página redirige a un proveedor de identidad?
- ¿La sesión debe ser efímera o el equipo necesita compartirla con revisión humana?
Las políticas empresariales permiten desactivar las browser tools o restringir dominios con BrowserChatTools y filtros de red del agente. Eso no reemplaza los permisos del sistema operativo ni la seguridad de la aplicación, pero evita que una instrucción amplia convierta toda la web en una zona de pruebas.
Un flujo de adopción con bajo riesgo
Probaría la función en este orden:
- habilitar browser tools en un proyecto de prueba y confirmar qué herramientas aparecen en el selector;
- levantar una aplicación local con datos sintéticos y errores intencionales;
- pedir al agente que pruebe una ruta funcional y revise consola, capturas y estados vacíos;
- bloquear por política cualquier dominio que no sea local o de staging;
- añadir pruebas de redirección, permisos y sesiones compartidas antes de usar datos reales.
El error común es confundir “el agente puede ver el navegador” con “el agente entiende el producto”. Puede comprobar clics y errores visibles, pero todavía necesita criterios claros para accesibilidad, contenido, seguridad, rendimiento y estados de negocio. Un screenshot verde no demuestra que una operación irreversible sea correcta.
La release también depreca el proveedor Ollama integrado: para continuar usando modelos locales en el chat, la recomendación oficial es instalar la extensión de Ollama. Es un cambio separado, pero relevante si tu flujo combina browser testing con un modelo local y BYOK.
La intención de búsqueda aparece en consultas como VS Code browser tools agentes, probar web apps con agente, permisos por sitio VS Code y browser agent testing. No hay volumen SEO conectado; la demanda se infiere de una capacidad que pasó a general availability, una guía reproducible publicada el 15 de julio y controles empresariales concretos.
Si quieres comparar esta superficie con una política de navegación externa, puedes leer cómo Stagehand 3.7 limita los dominios del browser agent. La decisión práctica no es qué agente hace más clics: es qué páginas, permisos y datos puede tocar mientras verifica tu código.