Si el agente siempre ve la pantalla de acceso, identifica qué instancia y perfil abrió. Un perfil nuevo no contiene estado del sitio. Uno persistente y autorizado puede conservar una sesión válida entre ejecuciones. El sitio decide si la acepta. Comprueba la cuenta o el espacio visible antes de actuar.
Identifica instancia, perfil y pestaña
El proceso del agente y el del navegador pueden estar en equipos distintos. Una pestaña pertenece a un contexto y los perfiles pueden tener cuentas diferentes. Registra el entorno, el perfil o etiqueta de conexión y el origen exacto. Abre en solo lectura una página con un marcador conocido. Conexión correcta y HTTP 200 no prueban que sea la cuenta prevista.
Elige una vía compatible de reutilización
Para pruebas repetibles, usa un perfil persistente dedicado si la herramienta lo admite. Un conector autorizado puede adjuntarse a un perfil con sesión. Un contexto nuevo sirve para páginas públicas o la variante sin sesión. Un navegador remoto no hereda la sesión del equipo. Usa un acceso separado aprobado o persistencia del proveedor.
| Modo | Perfil |
|---|---|
| Persistent | Sesión existente |
| Existing-session attach | Sesión existente |
| Isolated | Contexto limpio |
Playwright MCP · Profile and state OpenClaw · Browser profiles
Mantén la autenticación en el navegador
Pide al operador entrar en el sitio o usar un flujo de prueba aprobado. El agente suele necesitar un marcador de espacio, no el valor de una cookie o token. Un archivo de estado puede contener credenciales; guárdalo solo si es necesario y trátalo como secreto. Evita compartir el directorio entre procesos simultáneos. Comprueba permisos antes de actuar.
Ejecuta dos veces la misma tarea
Usamos un perfil dedicado de Tabbit Browser Dev y una página de práctica local. El primer GET /workspace mostró H01-FIXTURE-SIGNED-OUT. Una pulsación en Authorize demo estableció una sesión de prueba y mostró H01-FIXTURE-READY. Cerramos el navegador por completo. Otro proceso abrió el mismo perfil y URL y leyó H01-FIXTURE-READY con cero autorizaciones. Todo era sintético.
| Paso | GET /workspace | Resultado esperado |
|---|---|---|
| 1 | HTTP 200 | SIGNED-OUT → READY (1) |
| 2 | HTTP 200 | READY (0) |
| 3 | HTTP 200 | SIGNED-OUT (0) |


Trata explícitamente la caducidad y revocación
Antes de una tercera ejecución el servidor revocó la sesión. El mismo perfil y URL mostraron H01-FIXTURE-SIGNED-OUT con HTTP 200. No hubo acceso automático. Si aparece una pantalla de acceso, otro espacio o una solicitud de permiso en una tarea real, pausa y pide al operador verificar o renovar el acceso aprobado. Luego comprueba el resultado. La persistencia no impide la caducidad en el servidor.
Qué muestran dos experiencias
En r/automation, un usuario perdió la sesión al mover una tarea programada. En r/AI_Agents, un creador de herramientas dijo que el navegador nuevo abrió sin sesión mientras el anterior seguía conectado. Son experiencias individuales. Comprueba el perfil y el marcador visible.
¿Tengo que copiar cookies?
No. Una conexión compatible al perfil válido y autorizado puede reutilizar su sesión. Comprueba sitio, espacio y permisos antes de actuar.
Preguntas frecuentes
¿Tengo que copiar cookies?
No. Una conexión compatible al perfil válido y autorizado puede reutilizar su sesión. Comprueba sitio, espacio y permisos antes de actuar.
¿Cómo confirmo el perfil activo?
El proceso del agente y el del navegador pueden estar en equipos distintos. Una pestaña pertenece a un contexto y los perfiles pueden tener cuentas diferentes. Registra el entorno, el perfil o etiqueta de conexión y el origen exacto. Abre en solo lectura una página con un marcador conocido. Conexión correcta y HTTP 200 no prueban que sea la cuenta prevista.
¿Qué opciones de reutilización hay?
Para pruebas repetibles, usa un perfil persistente dedicado si la herramienta lo admite. Un conector autorizado puede adjuntarse a un perfil con sesión. Un contexto nuevo sirve para páginas públicas o la variante sin sesión. Un navegador remoto no hereda la sesión del equipo. Usa un acceso separado aprobado o persistencia del proveedor.
¿Cómo verifico la reutilización?
Usamos un perfil dedicado de Tabbit Browser Dev y una página de práctica local. El primer GET /workspace mostró H01-FIXTURE-SIGNED-OUT. Una pulsación en Authorize demo estableció una sesión de prueba y mostró H01-FIXTURE-READY. Cerramos el navegador por completo. Otro proceso abrió el mismo perfil y URL y leyó H01-FIXTURE-READY con cero autorizaciones. Todo era sintético.
¿Qué hago si caduca la sesión?
Antes de una tercera ejecución el servidor revocó la sesión. El mismo perfil y URL mostraron H01-FIXTURE-SIGNED-OUT con HTTP 200. No hubo acceso automático. Si aparece una pantalla de acceso, otro espacio o una solicitud de permiso en una tarea real, pausa y pide al operador verificar o renovar el acceso aprobado. Luego comprueba el resultado. La persistencia no impide la caducidad en el servidor.