Summary

In the managed openclaw browser profile, browser automation around file chooser flows can fail intermittently in a misleading way.

There appear to be two related problems:

1. The effective automation flow can split file upload into two separate requests:

   • browser upload(paths)
   • then a separate browser act click(ref) on the chooser trigger

   On dynamic pages, the trigger ref can go stale between those two requests, so the click fails even though the upload arm step succeeded.

2. When retrying the stale click with timeoutMs=20000, the final error can become:

   • Can't reach the OpenClaw browser control service (timed out after 20000ms)

   even though the gateway is healthy and the browser profile is still running.

That error reads like a transport outage, but the failure is actually inside the browser action path.

Steps to reproduce

1. Use the managed browser profile (profile="openclaw") on a dynamic form page where clicking a button/link opens a file chooser.
2. Take a snapshot and get a ref for the chooser trigger.
3. Call browser upload with paths only (no ref).
4. Then call a separate browser act click on the previously captured ref.
5. If the page re-renders and the ref becomes stale, retry that click with timeoutMs=20000.

Expected behavior

• File chooser flows should be robust on dynamic pages.
• If the click target is stale, the error should stay specific (for example: stale ref / element not visible / re-snapshot required).
• The tool should prefer the atomic path where upload is armed and the trigger is clicked in the same request.
• A browser action timeout should not be reported as "can't reach the browser control service" when the service itself is healthy.

Actual behavior

Observed sequence:

• First failure:
  • Element "e14" not found or not visible. Run a new snapshot to see current page elements.
• Then, after retrying with a longer timeout:
  • Can't reach the OpenClaw browser control service (timed out after 20000ms). Restart the OpenClaw gateway ...

The gateway remained healthy during this (gateway status OK, managed browser profile still running).

Environment

• Clawdbot version: 2026.3.2
• OS: macOS 26.3 (arm64)
• Install method (pnpm/npx/docker/etc): global npm install

Logs or screenshots

Representative errors:

[tools] browser failed: Error: Element "e14" not found or not visible. Run a new snapshot to see current page elements.

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

Relevant code paths that seem involved:

• src/browser/routes/agent.act.ts
  • /hooks/file-chooser already supports the atomic flow: arm upload, then click if ref is provided in the same request.
• src/browser/client-actions-core.ts
  • browser act / file chooser calls use a fixed outer timeoutMs: 20000.
• src/browser/client-fetch.ts
  • fetchBrowserJson() wraps route dispatch in Promise.race(..., setTimeout(...)), which can turn an in-route Playwright stall into a generic browser control timeout.

This feels like a combination of:

• browser tool calling pattern not preferring the atomic upload+click flow for chooser triggers
• and outer timeout/error mapping masking the real browser action failure

If useful, I can follow up with a patch sketch, but I am intentionally omitting any site-specific URLs, tokens, user identifiers, and local private paths from this report.