Remote control

Drive a captured Chrome remotely from the dashboard, MCP, or BusyBro — navigate, evaluate, screenshot.

Drive a captured Chrome remotely — navigate, evaluate JavaScript, take screenshots, snapshot the page — from the dashboard, MCP, or BusyBro.

What it does

A captured Chrome isn't just a traffic source. With remote control on, you can send Chrome DevTools Protocol commands to it from anywhere Busymate runs — tell it to navigate to a URL, run a script, capture a screenshot, or snapshot the DOM — and get the result back. The browser stays right where it is on your machine; the commands ride a Realtime channel.

This powers the browser_* tools in MCP and the browser-driving BusyBro capabilities, as well as remote-control actions in the dashboard.

On by default for automation devices — owner-gated opt-out

Remote control is a per-device opt-in, and for an automation-class device (a CDP browser, a bmc-daemon host, or an bmfarm host) it is ON by default — those devices exist to be driven. A personal / iOS device stays OFF by default and is never auto-controllable. Either way, bmc refuses every incoming command before it ever touches Chrome while the opt-in is off — so a device you've opted out can't be driven by anyone.

The default is owner-gated, not anonymous: only the device's owner (or an admin) with devices:edit can flip it, and the fold (effective_settings_for_device) is the single source of the default. To turn an automation device off (or a personal device on), open Devices → your device, and toggle Browser Control (the per-device cdpControlEnabled setting). The toggle pushes live over Realtime — no need to restart bmc. An explicit off persists and is always respected.

Heads up: Browser Control lets the dashboard, MCP, and BusyBro run arbitrary CDP commands against that Chrome — navigation, script evaluation, screenshots. It's on by default for automation devices because that's their purpose; turn it off for any device you only want to observe.

How it flows

Dashboard / MCP / BusyBro  ──cdp-command──▶  bmc  ──▶  Chrome
                           ◀──cdp-result──   bmc  ◀──

Commands arrive on the device's private Realtime channel as cdp-command messages and the results come back as cdp-result, correlated by id. Each command is gated by the opt-in and by ownership before it runs.

What you can do

Commands are Chrome DevTools Protocol methods, forwarded verbatim. The common ones the higher-level tools use:

  • Navigate — open a URL in the captured page.
  • Evaluate — run JavaScript in the page and read the result.
  • Screenshot — capture the rendered page as a PNG.
  • Snapshot — capture the page's structure (DOM / accessibility tree).

There's also a small connector-side helper namespace for discovering what to drive:

  • bmc.targets — list the attached page targets.
  • bmc.activePage — resolve the page to drive.

Large results (a screenshot, a PDF) are too big for a single Realtime frame, so bmc uploads them to storage and returns a short-lived signed URL instead of giant inline data — so a screenshot comes back as a renderable link in the dashboard, in MCP, or in a Telegram reply from BusyBro.

Using it

You don't send raw commands by hand — you use the surfaces built on top:

  • Dashboard — remote-control actions on a device under Devices.
  • MCP — the browser_* tools at MCP tools.
  • BusyBro — ask it to navigate or screenshot a device; see BusyBro capabilities.

In every case, the same gate applies: the device must have Browser Control enabled, and you must own it (or be an admin).

Next

Browser profilesCommand reference