Las llamadas al tool/browser con:• target host• profile user

[somber pecan]

fallan con timeout, por ejemplo:

• browser status
• y desde tool:
• timed out. Restart the OpenClaw gateway ... Do NOT retry the browser tool

Lo que ya descarté

• no parece faltar plugin, skill o extensión
• la cuenta Gmail ya está abierta
• el gateway sí está arriba
• el browser service sí arranca
• el problema parece estar específicamente en el attach de OpenClaw a la sesión existing-session de Chrome

Hallazgos adicionales

• intentar crear perfiles persistentes en caliente por browser CLI devuelve:
• browser.request cannot mutate persistent browser profiles
• al editar config para agregar un perfil browser explícito, OpenClaw exigió color en el perfil
• el perfil/logged-in Chrome real en esta máquina parece estar bajo:
• /home/cuba/.config/google-chrome/Default

Preguntas

1. ¿Hay algún requisito adicional para que existing-session funcione con Chrome ya abierto?
2. ¿Hace falta lanzar Chrome con algún flag especial o remote debugging?
3. ¿El perfil user con transport: chrome-mcp debería poder auto-adjuntarse sin más?
4. ¿Hay algún bug conocido donde el browser service levanta bien pero el tool/browser siempre entra en timeout con existing-session?

[twilit herald]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[pulsar crown]

Primero, pasá openclaw --version, porque acá sí hubo fixes relevantes.

Sobre tus preguntas:

1. Sí, existing-session tiene requisitos extra:

   • Gateway y Chrome en la misma máquina. existing-session es host-local.
   • Chrome/Chromium 144+.
   • Chrome abierto, con al menos una pestaña.
   • En chrome://inspect/#remote-debugging, remote debugging habilitado.
   • Aceptar el prompt de consentimiento cuando OpenClaw se adjunta.

2. Para existing-session con chrome-mcp, no deberías necesitar --remote-debugging-port=9222.
   Ese flag es para raw CDP, no para Chrome MCP. Si querés un workaround/aislamiento, ahí sí conviene probar CDP aparte.

3. Sí, profile: "user" con transport: "chrome-mcp" debería auto-adjuntarse, pero solo si se cumplen esos prereqs.
   Ojo con esto: si configurás userDataDir, lo correcto parece ser el user data dir raíz, no .../Default.
   O sea, probaría:

• /home/cuba/.config/google-chrome
  • no /home/cuba/.config/google-chrome/Default

4. Sí, hubo bugs/reportes conocidos:
   • en 2026.3.23 salió un fix para reducir timeouts en existing-session / Chrome MCP
   • todavía hay casos donde un fallo real de attach termina viéndose como timeout genérico

Dos notas importantes:

• browser.request cannot mutate persistent browser profiles no parece ser la causa del timeout. Eso solo indica que no podés mutar perfiles persistentes “en caliente” por ese camino.
• Que el config exija color en el perfil es normal, el schema lo requiere.

Mi recomendación corta:

1. confirmá openclaw --version
2. si seguís con existing-session, usá user o un perfil explícito con:
   • driver: "existing-session"

• attachOnly: true
  • color: "#..."
  • userDataDir: "/home/cuba/.config/google-chrome" si hace falta

3. no pongas cdpUrl en ese perfil
4. si sigue timeouteando, probá raw CDP con Chrome lanzado con --remote-debugging-port=9222, para separar “Chrome MCP attach roto” de “browser service roto”

Docs:

• https://docs.openclaw.ai/help/faq
• https://docs.openclaw.ai/tools/browser
• https://docs.openclaw.ai/tools/browser-linux-troubleshooting
• https://docs.openclaw.ai/gateway/troubleshooting

Si querés, te dejo el bloque exacto de config para ambos caminos, existing-session y fallback por CDP.

[somber pecan]

Probé y sigue fallando igual: timeout al adjuntarse al navegador.

Así que, por ahora, el reinicio sí tomó el cambio, pero sigue faltando la parte de Chrome en tu sesión gráfica.

Lo más probable ahora es una de estas dos:

1. no hay consentimiento aceptado en Chrome para el attach
2. remote debugging / inspect no está listo en esa sesión abierta

Lo importante

Ya llegamos a un punto donde yo no puedo destrabarlo solo desde remoto.

Cuando puedas hacer el paso visual en la compu

revisa estas 3 cosas:

• Chrome abierto con al menos una pestaña
• abrir chrome://inspect/#remote-debugging
• aceptar cualquier prompt de consentimiento que aparezca cuando OpenClaw intente adjuntarse

Mi lectura honesta

Ya no estamos adivinando:

• Gmail está bien
• config está mejor
• OpenClaw está actualizado
• el cuello de botella ahora parece estar del lado del attach visual de Chrome

Si quieres, te puedo dejar un checklist muy corto para hacer apenas tengas acceso a la computadora.

[pulsar crown]

Sí, eso ya lo acota bastante. Huele a Chrome MCP attach, no a gateway caído.

Yo probaría esto, en este orden:

1. Pasá openclaw --version
   Quiero ver si estás ya en una build posterior al fix de 2026.3.23.

2. Si pusiste userDataDir explícito, cambiá esto
   probá con:

   • /home/cuba/.config/google-chrome
     y no con:
   • /home/cuba/.config/google-chrome/Default
     En docs/código se trata como user data dir, no la subcarpeta del perfil.

3. Reseteá solo la sesión MCP, no todo Chrome

   openclaw browser stop --browser-profile user

Eso cierra la sesión de control, útil si quedó colgada.

4. En la sesión gráfica real de Chrome

   • abrí una pestaña normal
   • abrí chrome://inspect/#remote-debugging
   • asegurate de que remote debugging esté habilitado
   • aceptá cualquier prompt de attach

5. Reintentá con esto

   openclaw browser --browser-profile user tabs
   

Si sigue fallando, lo más útil ya no es reiniciar más, sino ver la causa concreta en logs, porque el tool muchas veces la aplana a “timeout”.

Buscá y pegá estas 3 salidas:

openclaw --version
openclaw browser profiles
openclaw browser --browser-profile user tabs

y además un snippet de:

openclaw logs --follow

mientras hacés el intento, sobre todo si aparece algo como:

• Chrome MCP existing-session attach failed