[Bug]: browser.act intermittently times out ("Can't reach the OpenClaw browser control service") while snapshot/open works; sometimes followed by "tab not found"

[sovushik]

When using the built-in OpenClaw server-side browser (headless Chrome, profile openclaw), browser.snapshot and browser.open often succeed, but browser.act intermittently fails with:

• Can't reach the OpenClaw browser control service (timed out after 20000ms)
• sometimes followed by: ... (Error: Error: tab not found)
This happens even though the gateway is reachable and the browser profile can be (re)started. As a workaround we often need to restart the browser profile (browser stop/start) and re-open the page.

Environment

• OpenClaw: 2026.2.9 (stable)
• OS: Linux 6.8.0-100-generic x86_64 (Ubuntu)
• Node: v25.6.1
• Chrome: Google Chrome 145.0.7632.45
• Browser config: headless true, noSandbox=true, profile openclaw
• Gateway bind: loopback (local)
What works

• browser.open creates a tab / targetId
• browser.snapshot returns a valid accessibility tree for that targetId (so the page is loaded and readable)
What fails

• browser.act (e.g., clicking a ref from snapshot) sometimes fails with a 20s timeout reaching the browser control service, despite snapshot/open working moments earlier.
Steps to reproduce (approx.)

1. Start gateway and browser profile openclaw (headless).
2. browser.open("https://journal.top-academy.ru/ru/main/dashboard/page/index")
3. browser.snapshot(...) (works)
4. browser.act(click, ref=)
   → intermittently fails with the timeout error.
5. Restarting the browser profile may “fix” it temporarily, but then reusing the old targetId may lead to “tab not found”.
   Logs (excerpt)

From gateway logs (timestamps omitted here for brevity):
info browser/chrome 🦞 openclaw browser started (chrome) profile "openclaw" on 127.0.0.1:18800 (pid 69137)

error [tools] browser failed: Can't reach the OpenClaw browser control service (timed out after 20000ms). Start (or restart) the OpenClaw gateway ...

error [tools] browser failed: Can't reach the OpenClaw browser control service ... (Error: Error: tab not found)

Expected behavior

• If browser.snapshot succeeds for a given targetId, browser.act should be able to operate on the same tab reliably, or fail with a more specific/diagnostic error (e.g., CDP disconnected) rather than generic “can’t reach control service”.
• After a browser profile restart, the system should either: • automatically invalidate/refresh targetIds, or
• return a clearer error / provide an automatic recovery path.

Suggested improvements / ideas

1. Add a single automatic retry for browser.act when the error matches: • “Can’t reach the OpenClaw browser control service (timed out …)”
   • “tab not found”
   Possible recovery: reconnect to the browser control service / restart the profile, re-open the last known URL, then re-run the action once.

2. Improve diagnostics: log control-service connectivity, CDP status/port, and whether the targetId still exists when the action starts.
   If you’d like, I can provide more logs or try to isolate a smaller repro script.

[sovushik]

(Account: @sovushik) Adding two extra data points: (1) In our environment browser.snapshot continues to work right before/while browser.act fails with the control-service timeout, so the page is loaded and readable via CDP. (2) Workaround that often helps: restart browser profile (openclaw browser stop/start --profile openclaw) and re-open the URL; after restart, reusing an old targetId may yield 'tab not found'. Let me know if you'd like a minimal repro script or full log bundle.

[sovushik]

More implementation-oriented suggestions (happy to help test):

1. Differentiate failure modes

   • Right now multiple underlying problems surface as “Can’t reach the browser control service”. If possible, return distinct errors for: control service down, CDP disconnected, target missing, action timeout, etc.

2. Auto-recovery + single retry for known transient errors

   • For browser.act / browser.navigate, if error matches:
     • timed out after ...ms reaching control service
     • tab not found
       then do a single recovery attempt: ensure control service healthy → ensure profile started → re-list targets → if old targetId missing, reopen last URL (or fail with guidance) → retry action once.

3. TargetId lifecycle / invalidation

   • After profile restart, previously issued targetIds become invalid. Consider:
     • returning a structured “stale targetId” error immediately, or
     • mapping “logical tabs” to current targetIds (if you keep a registry), or
     • exposing a lightweight “resolve target” step.

4. Health/keepalive

   • Add periodic keepalive/ping to the control service/CDP. If it goes unhealthy, restart the service/profile proactively.

5. Better logging & debug bundle

   • When a tool call fails, include in logs: profile name, cdpPort/cdpReady, browser pid, targetId, and time spent in each phase (RPC → control service → CDP command).
   • Optional: a CLI command to dump recent browser-service logs + CDP status in one paste.

If you point me to the relevant files/modules, I can attempt a small PR for the retry + improved error classification.

[sovushik]

Opened a small PR that improves the diagnostics for this failure mode: #14784\n\nIt detects common stale-target messages (e.g. "tab not found") and surfaces them as a clearer "stale targetId" error instead of the generic "Can't reach the browser control service" hint.\n\nThis doesn't fully fix the underlying flakiness, but should reduce confusion and make the recommended recovery (re-open to obtain a fresh targetId) explicit.

[ProtossDragoon]

I'm running into this same problem as well. I'd like to help investigate, but the codebase is so large that I'm having trouble locating the relevant sections. Could someone point me in the right direction?

[sovushik]

Thanks for confirming you’re seeing the same behaviour.

Here’s roughly what I’m seeing and where it seems to live:

• Symptom pattern

  • browser.open and browser.snapshot are consistently fine.
  • browser.act intermittently times out with Can't reach the OpenClaw browser control service.
  • After that, later calls sometimes hit tab not found for the same targetId.
  • Restarting the gateway/browser service “fixes” it for a while.

• Where I’d look in the codebase

  • The path gateway → browser service → DevTools/Playwright layer that actually dispatches act.
  • The code that:
    • looks up the tab/page by targetId,
    • sends the DevTools command,
    • and handles timeouts / reconnects.
  • Any logic that cleans up tabs or restarts the browser service while sessions still hold stale targetIds.

• Environment note

  • In my case I also had a site that returned an empty DOM in headless Chrome until I wrapped Chrome with
    --disable-blink-features=AutomationControlled and pointed browser.executablePath at that wrapper.
    That fixed the blank DOM issue and made snapshot very reliable, but the act timeouts still show up
    over time, which is why I suspect something at the browser-service/tab-registry layer rather than the agent.

I’d love to see better error separation between “browser service unreachable” vs “stale / gone targetId”, and maybe some self‑healing around stale tabs (refreshing the tab registry instead of failing as if the entire control service is unreachable).

If you or maintainers have specific files/areas you’d like logs from, I’m happy to run extra tracing on my side.

[sovushik]

Quick update after upgrading OpenClaw to 2026.2.14 (stable): the browser behaviour is still effectively the same for this issue.

• browser.open and browser.snapshot continue to work reliably.
• browser.act still intermittently fails even on a freshly opened tab with the same generic error ("Can't reach the OpenClaw browser control service" / "fields are required"), so we can't build a stable automation flow on top of it.

This is becoming a bit of a blocker for us: we have a real-world use case (school journal automation) where we need to log in, navigate, and scrape/update data consistently, and right now the unreliability of browser.act makes the whole flow brittle.

Possible directions that might help (at least as mitigations):

1. More precise errors and health checks

   • Distinguish between: control service down, CDP unreachable, stale targetId, invalid arguments, etc.
   • Right now they all surface as the same “can’t reach control service” hint.
   • Maybe add a cheap health endpoint / CLI probe for the browser service so automation can proactively restart the profile when it goes unhealthy.

2. Scoped, single retry for known transient errors

   • For browser.act / browser.navigate only, when errors match known transient patterns (timeout / stale target), do a single recovery attempt: ensure service + profile are up, re-list targets, reopen URL if needed, then retry once.

3. Alternative interfaces for automation-heavy users

   • Even a lower-level “send raw CDP command to this targetId” tool (with minimal safety rails) would be helpful for power users who are willing to manage retries and state on their side.

If there's anything concrete we can do on our side (extra logs, running a debug build, trying experimental patches), I'm happy to help test. Right now the main pain point is that browser.act is the only supported way to interact with the page, and its flakiness is what stops us from shipping a robust workflow.

[sovushik]

Quick follow-up after updating to OpenClaw 2026.2.15 (stable): the browser.act behaviour for this issue is still effectively the same.

• browser.open and browser.snapshot continue to work reliably on the fresh install.
• browser.act still intermittently fails even on a newly opened tab with the same generic error ("Can't reach the OpenClaw browser control service" / "fields are required"), so we still can't build a robust automation flow on top of it.

In our case this remains a practical blocker for automating a real-world flow (school journal login + navigation + scraping/update). After the upgrade we re-ran the same login sequence, and the very first browser.act(fill) on the login form sometimes hits the control-service error, while open/snapshot for the same page stay healthy.

Just wanted to confirm that 2026.2.15 does not change observable behaviour here; the suggestions in my last comment (better error separation, a scoped retry path, or a lower-level CDP escape hatch) still apply. Happy to test any experimental patches or additional logging around browser.act.

[sovushik]

Update from a user on 2026.2.17 (stable):
just re-tested the Top Academy journal flow on 2026.2.17.

• browser.open https://journal.top-academy.ru/ru works and browser.snapshot now returns proper aria refs for the login form (e.g. textbox "Логин" [ref=e17], textbox "Пароль" [ref=e19], button "Вход" [ref=e21]).
• • However, the original failure mode for browser.act still reproduces: a simple browser.act(fill, ref=e17, text=<login>) immediately fails with:
• • Can't reach the OpenClaw browser control service. Start (or restart) the OpenClaw gateway (OpenClaw.app menubar, or ) and try again. (Error: fields are required)
• • Gateway is running locally and other tools are fine; this is the same error text we were seeing on 2026.2.14/2.15. So for now any automation that needs to actually type into the journal login form is still blocked on this issue, even though snapshotting refs looks better in 2.17.
• • If you need more detailed logs or are experimenting with a fix, I'm happy to re-test on my setup after a patch lands.

[sovushik]

Quick status update from a self-hosted Telegram+browser setup (Ubuntu 24.04, gateway on loopback).

After updating to 2026.2.21-2 (stable) and re-testing the headless Chrome browser:

• browser.open / browser.snapshot against our school journal site still work fine (login form is visible in the DOM).
• Any attempt to use browser.act (e.g. fill on the login form fields by ref) still returns the same error as in earlier versions:

"Can't reach the OpenClaw browser control service. Restart the OpenClaw gateway and try again. (Error: fields are required)"

So from the perspective of this issue, behavior on 2026.2.14 → 2.15 → 2.17 → 2.19-2 → 2.21-2 remains unchanged: act is the blocker, while open/snapshot are fine.

Happy to re-test or provide more concrete payload examples if that would help nail this down.

[sovushik]

Quick follow-up from the same self-hosted Telegram+browser setup after updating to 2026.2.23 (stable).

Browser control improvements in 2.23 look promising in the changelog, but the behavior for this issue is still unchanged on my side:

• browser.open / browser.snapshot against our school journal site continue to work: the login form is visible with refs like e2 (login), e3 (password), e4 (submit button).
• Any call to browser.act (e.g. fill on ref: e2) still immediately returns:

"Can't reach the OpenClaw browser control service. Restart the OpenClaw gateway and try again. (Error: fields are required)"

This happens even though the gateway is healthy (openclaw status OK, Telegram channel OK, browser control enabled) and the page is clearly reachable via snapshot.

From a user perspective, the situation across 2026.2.14 → 2.15 → 2.17 → 2.19-2 → 2.21-2 → 2.22-2 → 2.23 remains the same for this specific journal scenario: act is still the blocker, open/snapshot are fine.

Happy to provide more detailed payloads or run extra diagnostics if that helps track down the underlying cause.

[sovushik]

Confirmed fix: after the patch handling legacy fill (when value is missing), the browser.act scenario has been working consistently for us.

Validation on a real case (journal.top-academy.ru):
browser.act → fill login/password fields: ✅
browser.act → click the login button: ✅
subsequent actions in the user account (clicks/navigation): ✅

Before the patch, we were consistently hitting the fields are required error; after the patch, this case is no longer reproducible.

Please include this fix in the next release — it is a critical automation blocker for us.