#Bug: browser act tool calls time out, but openclaw browser type/click CLI works fine

1 messages · Page 1 of 1 (latest)

copper berry
#

Version: 2026.2.25
OS: macOS (arm64)

What's happening:
The act action via the agent tool always times out after 20s, but the underlying browser CLI commands work perfectly.

Steps to reproduce:
Start gateway, open browser profile openclaw
Navigate to google.com (works ✅)
Take screenshot (works ✅)
Call act with kind: type on the search box → times out ❌
Run openclaw browser snapshot → get valid refs ✅
Run openclaw browser type <ref> "hello" --submit → works ✅

Logs show: Browser starts on port 18800, gateway on 18789. The act RPC never reaches the browser subprocess.

Workaround: Use navigate + screenshot for read-only tasks, or exec openclaw browser CLI commands directly.

near iglooBOT
#

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

viral dockBOT
#

That exact “agent browser tool act times out at 20000ms, but openclaw browser type/click works” pattern matches a recently-fixed bug: openclaw/openclaw#11518. The fix was: host browser act now routes through the in-process dispatcher/control-service path (so it no longer depends on the old “local HTTP control port is listening” behavior that could get into a dead/zombie state).

If you’re on 2026.2.25 and still seeing it, the most common explanation is: your CLI and your running Gateway are not actually the same build/install (macOS launchd/nvm mismatch is a classic), so the Gateway is still running the older codepath.

Quick checks (to confirm version mismatch):

  1. Paste output of:
  • openclaw --version
  • openclaw gateway status --deep (this usually reveals what binary/path the service is actually running)
  1. After any update/reinstall, do a real restart of the service:
  • openclaw gateway restart

If gateway status --deep shows it’s running from an older Node/global install path, the fix is to reinstall the gateway service from the “correct” install (so launchd points at the same OpenClaw you run in your shell).

If those checks show versions do match, then I’d treat this as a regression and we should open a new issue with:

  • openclaw logs --follow --log-level debug during a single failing browser.act call
  • the exact tool payload your agent is sending for act (kind/ref/targetId/profile).
copper berry
#

Follow-up:

Version check confirms no mismatch — CLI and gateway both running from /opt/homebrew/lib/node_modules/openclaw/dist/entry.js on the same Node build.

openclaw browser type <ref> "text" --submit works fine every time via CLI. The failure is isolated to the agent tool act call — it times out at 20s every time regardless of profile (openclaw or chrome).

This looks like a regression in the in-process dispatcher path for act specifically. The navigate/screenshot tool calls work fine through the same gateway.

Tool payload being sent: {"kind": "type", "ref": "<aria-ref>", "text": "...", "submit": true} with profile: "openclaw" and valid targetId.

Want to paste that back to them? 🦞

viral dockBOT
#

Yep — please paste this into the thread (this is the useful delta):

Confirmed no install/version mismatch: both CLI and gateway are running from the same path (/opt/homebrew/lib/node_modules/openclaw/dist/entry.js) on the same Node build.

Repro still holds on 2026.2.25 (macOS arm64):

  • ✅ openclaw browser snapshot returns valid refs
  • ✅ openclaw browser type <ref> "text" --submit works reliably (same profile/targetId)
  • ✅ browser tool navigate / screenshot work through the gateway
  • ❌ but browser tool action=act (e.g. {kind:"type", ref:"…", text:"…", submit:true} with profile:"openclaw" + valid targetId) always times out at exactly 20s
  • Also fails for profile:"chrome" → seems isolated to the agent tool act path, not the underlying browser/Playwright/CLI.

This looks like a regression/bug in the in-process dispatcher path used by the agent tool for /act, specifically (since CLI /act works).

One quick sanity check: for the agent tool, targetId must be inside the request object (top-level targetId is ignored for action:"act"). Example: