Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

The browser control HTTP API is documented as available on the local loopback control port, but on OpenClaw 2026.6.6 it does not start unless OPENCLAW_EAGER_BROWSER_CONTROL_SERVER=1 is set manually in the gateway service environment.

This makes the documented curl/API flow fail out of the box even when browser control itself is otherwise working through the CLI. lobster-biscuit

Steps to reproduce

1. Install/run OpenClaw 2026.6.6 with browser control enabled and valid gateway token auth.
2. Confirm browser CLI works:
   • openclaw browser doctor --deep
   • openclaw browser start
3. Try the documented HTTP status endpoint:
   • curl -H "Authorization: Bearer <token>" http://127.0.0.1:18791/
4. Observe that nothing is listening on 127.0.0.1:18791.
5. Add OPENCLAW_EAGER_BROWSER_CONTROL_SERVER=1 to the systemd user service, reload, and restart the gateway.
6. Retry:
   • ss -lntp | grep 18791
   • curl -H "Authorization: Bearer <token>" http://127.0.0.1:18791/

Expected behavior

If the browser control HTTP API is documented and browser control is enabled, the local loopback HTTP server should either:

• start automatically, or
• the docs should clearly state that OPENCLAW_EAGER_BROWSER_CONTROL_SERVER=1 is required.

Actual behavior

Browser control works internally and via CLI, but the standalone HTTP API is not exposed until OPENCLAW_EAGER_BROWSER_CONTROL_SERVER=1 is set manually.

OpenClaw version

2026.6.6 (8c802aa)

Operating system

Linux (root user on VPS)

Install method

No response

Model

N/A

Provider / routing chain

N/A

Additional provider/model setup details

• Gateway auth: token mode
• Browser config: enabled
• Browser executable: /usr/bin/google-chrome-stable
• Browser profile: openclaw
• Headless: true
• noSandbox: true

Logs, screenshots, and evidence

Before setting the env var:
- `openclaw browser doctor --deep` reports browser control reachable.
- `openclaw browser start` works.
- `curl http://127.0.0.1:18791/` fails because no listener is present.

Relevant code paths found in the installed dist bundle:
- `control-service-*.js` starts browser control runtime with `server: null`
- `server-*.js` binds the standalone HTTP API on `127.0.0.1:${controlPort}`
- `plugin-service-*.js` only starts that server when `OPENCLAW_EAGER_BROWSER_CONTROL_SERVER` is truthy

After setting:
- `OPENCLAW_EAGER_BROWSER_CONTROL_SERVER=1`
- listener appears on `127.0.0.1:18791`
- log appears:
  - `Browser control listening on http://127.0.0.1:18791/ (auth=token)`
- `GET /` returns HTTP 200 with browser status JSON

Example successful response after enabling the env var:

{
  "enabled": true,
  "profile": "openclaw",
  "driver": "openclaw",
  "transport": "cdp",
  "running": false,
  "cdpReady": false,
  "cdpHttp": false,
  "pageReady": false,
  "pid": null,
  "cdpPort": 18800,
  "cdpUrl": "http://127.0.0.1:18800",
  "detectedBrowser": "custom",
  "detectedExecutablePath": "/usr/bin/google-chrome-stable",
  "headless": true,
  "noSandbox": true,
  "attachOnly": false
}

Impact and severity

• The documented browser-control HTTP API appears broken.
• curl-based local integrations fail unless the operator knows about an undocumented env flag.
• This creates unnecessary debugging time and makes the docs misleading for self-hosted deployments.

Additional information

Search done

I checked the installed dist code paths and searched the existing issue tracker before filing this.

Workarounds

Set this in the gateway service environment and restart the service:

[Service]
Environment=OPENCLAW_EAGER_BROWSER_CONTROL_SERVER=1

Then run:

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service

Notes

This may be either:

1. a regression in runtime behavior, or
2. a documentation gap if the standalone HTTP API is now intentionally opt-in.

In either case, the current browser-control docs should mention the requirement explicitly.