Remote control

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.
• bmc.click — a trusted click: give it a selector (or an explicit x/y) and it resolves the on-screen point and dispatches a real Chrome Input event sequence (mouseMoved → mousePressed → mouseReleased), so the page sees an ordinary OS-level user gesture instead of a scripted element.click(). This matters for buttons that check event.isTrusted before continuing — Google's "Continue with Google" is the common one: a scripted click is rejected as an untrusted gesture and the tab tears down instead of opening the consent popup, while a bmc.click reaches it the same way a real click would. When the click opens a popup window — which is exactly what a sign-in button does — bmc.click waits for it, gets it running, and reports it back as popup: { targetId, url, navigated }, so you never have to list targets afterwards and guess which one is yours. Ordinary clicks that open nothing answer as fast as they always did.

Any Chrome DevTools Protocol method that needs a specific page — Input.*, Page.*, Runtime.*, DOM.*, and most others — is auto-targeted at the active page when you don't name one explicitly, the same resolution bmc.activePage performs. Only the browser-wide domains (Target.*, Browser.*, SystemInfo.*, IO.*) run without a page.

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

• Update & remove — keep bmc current and tidy up devices.
• Command reference — every bmc command and flag.