Entre las decenas de líneas de las notas de la versión 2.1.251 de Claude Code hay una que cambia dónde se decide algo importante: las acciones del navegador de Claude in Chrome pasan a comprobarse siempre contra el sistema de permisos del CLI, incluidas las sesiones con telemetría desactivada, que hasta ahora se apoyaban en los diálogos de la propia extensión. No amplía lo que el navegador puede hacer; mueve la autorización a un único sitio. Y en una herramienta que ya ejecuta comandos y escribe ficheros, eso importa más que muchas funciones nuevas.
Una sola lista de reglas para el disco y para la web
Hasta este cambio convivían dos sistemas de autorización distintos en el mismo flujo de trabajo. Por un lado, las reglas del CLI: las listas de permitido y denegado que gobiernan Bash, Read, Edit y el resto de herramientas, con sus modos de permisos, su sandbox y sus hooks. Por otro, los diálogos propios de la extensión del navegador, que respondían a su propia lógica y a su propia configuración.
Dos sistemas de permisos para un mismo agente es una mala idea por una razón muy concreta: obligan a mantener dos configuraciones coherentes entre sí y a recordar cuál se aplica en cada momento. Cuando eso ocurre, lo que acaba pasando en la práctica es que uno de los dos se configura bien y el otro se deja como venga.
A partir de ahora, la pregunta «¿puede el agente hacer esto?» tiene una sola respuesta y un solo sitio donde consultarla. Las mismas reglas que decides una vez para tu proyecto cubren también lo que ocurre dentro del navegador, con la misma sintaxis y el mismo orden de precedencia entre ajustes de usuario, de proyecto y gestionados.
El detalle está en la coletilla de la telemetría
La parte de la nota que conviene leer con atención es la que menciona las sesiones con telemetría desactivada. Son las de quienes trabajan en entornos donde el envío de datos analíticos está apagado por política de empresa o por decisión propia: perfiles con requisitos de confidencialidad, despliegues internos, consultoría con clientes sensibles.
Justo esas sesiones eran las que se quedaban fuera, apoyándose en los diálogos de la extensión en lugar de en las comprobaciones del CLI. Es un patrón que se repite en muchos productos: la configuración más restrictiva acaba recibiendo el camino menos probado. Cerrar esa asimetría significa que el entorno más exigente deja de ser también el peor cubierto, y es la clase de arreglo que no aparece en ningún titular pero que decide si puedes usar la herramienta en un cliente con requisitos formales.
Dos sistemas de permisos para el mismo agente significan, en la práctica, que uno de los dos está mal configurado.
El navegador es la superficie donde más duele equivocarse
Este movimiento llega pocos días después de que Claude in Chrome pasara a disponibilidad general y de que Cowork estrenara su propio navegador integrado, que abre páginas en un panel lateral sin depender de la extensión. Es decir, en cuestión de una semana el navegador ha pasado de ser una función lateral a ser una vía de trabajo principal, y todas las decisiones de permisos alrededor de él se vuelven más relevantes.
La razón de fondo es conocida por cualquiera que haya seguido el asunto: una página web es contenido que no controlas y que el agente va a leer. Un texto escondido en la página puede intentar dar instrucciones al modelo —lo que se conoce como inyección de prompts— y el único cortafuegos real es que, incluso si el modelo se deja convencer, la acción resultante tenga que pasar por una comprobación de permisos que tú definiste antes.
Que esa comprobación esté ahora en el mismo lugar que las demás no elimina el riesgo, pero convierte una defensa dispersa en una defensa auditable. Puedes leer tus reglas en un fichero y saber qué puede pasar; antes tenías que revisar además cómo estaba configurada la extensión.
⚠️ El navegador integrado no es lo mismo que tu Chrome
El navegador que Cowork abre en su panel lateral no accede a tus servicios con sesión iniciada —correo, banca, paneles de cliente— salvo que introduzcas las credenciales a mano. La extensión de Chrome, en cambio, trabaja sobre tu navegador real y sus sesiones abiertas. Son dos niveles de exposición muy distintos: conviene saber cuál de los dos estás usando antes de mandar al agente a «mirar una web».
Qué revisar hoy en tu configuración
La actualización no requiere que hagas nada para funcionar, pero sí es un buen momento para tres comprobaciones rápidas. La primera: mira tus reglas de permisos con la idea de que ahora también aplican al navegador. Si tienes un modo permisivo activado por comodidad en un proyecto, acabas de ampliarlo a una superficie más.
La segunda: decide de forma consciente qué vía usas para las tareas web. Si lo que necesitas es leer documentación o consultar información pública, el navegador integrado con su aislamiento es la opción sensata. Si de verdad necesitas actuar sobre una aplicación en la que ya tienes sesión, estás en el territorio que exige reglas explícitas, y conviene acotar por sitio en lugar de dar permiso general.
Y la tercera, para quien trabaja con clientes: esta unificación es un argumento que puedes usar por escrito. Cuando un cliente pregunta qué puede tocar la IA en su entorno, ahora la respuesta cabe en un solo documento —tus reglas de permisos— en lugar de repartirse entre la configuración del CLI y la de una extensión de navegador. Ese tipo de simplificación es lo que convierte una herramienta de uso personal en algo defendible en un contrato.
