TabbitBlog

Cómo reutilizar una sesión iniciada con un agente de navegador

Identifica navegador y perfil, comprueba el espacio autorizado y prueba el reinicio completo sin exportar credenciales.

En este artículo
  1. Identifica instancia, perfil y pestaña
  2. Elige una vía compatible de reutilización
  3. Mantén la autenticación en el navegador
  4. Ejecuta dos veces la misma tarea
  5. Trata explícitamente la caducidad y revocación
  6. Qué muestran dos experiencias
  7. ¿Tengo que copiar cookies?

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.

Browser Use · Real Browser

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.

ModoPerfil
PersistentSesión existente
Existing-session attachSesión existente
IsolatedContexto 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.

Playwright · Authentication

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.

PasoGET /workspaceResultado esperado
1HTTP 200SIGNED-OUT → READY (1)
2HTTP 200READY (0)
3HTTP 200SIGNED-OUT (0)

Primera ejecución de Tabbit con aviso de acceso

Segunda ejecución de Tabbit con el espacio de prueba autorizado

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.

r/automation r/AI_Agents

¿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.

Da el siguiente paso

Deja que Tabbit trabaje junto a ti.

Investiga entre pestañas, automatiza el trabajo repetitivo del navegador y mantén todo el contexto al alcance.