Summary
bb browser-automation open --backend local --headless --machine air returns Host is not connected even though the host daemon is connected, heartbeating, and serving every other RPC fine. The same command with the raw host ID (--machine host_z7pqtcweq8) works on the first try.
This is reproducible against bb-app 0.43.3 on every machine I've tested (the VPS server and a Mac Air host). Every other CLI command that takes --machine <name> resolves the name correctly; only the browser-automation CLI appears to suffer from this.
Repro
# Daemon on Air is connected and serving threads/terminals normally:
$ bb machine show air --json
{ ..., "status": "connected", "lastSeenAt": <recent>, ... }
$ bb thread spawn --machine air --project proj_personal --prompt "date" # works
$ bb terminal create --machine air --command "uptime" # works
$ bb file read "/Users/me/.zshrc" --host air # works
# But browser-automation with the same name fails:
$ bb browser-automation open --backend local --headless --machine air
{
"ok": false,
"error": { "code": "command_failed", "message": "Host is not connected" }
}
# Using the host ID instead succeeds:
$ bb browser-automation open --backend local --headless --machine host_z7pqtcweq8
{ "id": "9306cfe9-...", "hostId": "host_z7pqtcweq8", "backend": "local", "state": "ready", ... }Evidence
- Daemon
lastSeenAt updates every ~5s
host_daemon_sessions row is status='active' with a valid lease_expires_atbb machine list shows the host as connected- The air daemon's stdio log shows other RPCs arriving and being handled (e.g.
thread.start, provider.list_models), but no browser-automation worker ever starts — the open call fails server-side before the RPC is dispatched
- The plugin's KV storage has stale session rows that emit a recurring
Browser Automation cleanup on host <name> incomplete; host expiry and lease revocation remain active. warning every ~30s for every previously-attempted host — possibly related
- The error message
Host is not connected is misleading; the host IS connected for every other surface
Expected
--machine air and --machine host_z7pqtcweq8 should behave identically (both resolve to the same daemon session). The CLI flag help text for --machine says it accepts "an exact ID or unambiguous name" — that contract should hold for browser-automation too.
Workaround
Use the raw host ID instead of the friendly name:
bb machine list --json | jq -r '.[] | "\(.name) \(.id)"' # look up
bb browser-automation open --backend local --headless --machine host_z7pqtcweq8
Versions
bb-app 0.43.3 (server + every host-daemon)- Hosts tested: MacBook Air (macOS 15.5, mDNS-discoverable), Ubuntu VPS (
vps-76e2de35)
- Provider tested:
pi (default for the personal project), same behaviour with no provider attached
- The browser-automation plugin is the built-in shipped with bb-app (not a marketplace plugin)
Where in the code (best guess)
The Host is not connected error is thrown from the host RPC layer in packages/server/dist/start-server.js (assertHostActiveForRead / getOpenDaemonSessionForHost). It looks like the browser-automation plugin's RPC entry point resolves the host by name in a way that doesn't match what the hub expects — possibly bypassing the same name→id lookup that the rest of core uses. Worth checking whether bb.browserAutomation.open does its own host lookup vs. going through the same path as bb thread spawn --machine <name>.
Summary
bb browser-automation open --backend local --headless --machine airreturnsHost is not connectedeven though the host daemon is connected, heartbeating, and serving every other RPC fine. The same command with the raw host ID (--machine host_z7pqtcweq8) works on the first try.This is reproducible against
bb-app0.43.3 on every machine I've tested (the VPS server and a Mac Air host). Every other CLI command that takes--machine <name>resolves the name correctly; only thebrowser-automationCLI appears to suffer from this.Repro
Evidence
lastSeenAtupdates every ~5shost_daemon_sessionsrow isstatus='active'with a validlease_expires_atbb machine listshows the host asconnectedthread.start,provider.list_models), but nobrowser-automationworker ever starts — the open call fails server-side before the RPC is dispatchedBrowser Automation cleanup on host <name> incomplete; host expiry and lease revocation remain active.warning every ~30s for every previously-attempted host — possibly relatedHost is not connectedis misleading; the host IS connected for every other surfaceExpected
--machine airand--machine host_z7pqtcweq8should behave identically (both resolve to the same daemon session). The CLI flag help text for--machinesays it accepts "an exact ID or unambiguous name" — that contract should hold forbrowser-automationtoo.Workaround
Use the raw host ID instead of the friendly name:
Versions
bb-app0.43.3 (server + every host-daemon)vps-76e2de35)pi(default for the personal project), same behaviour with no provider attachedWhere in the code (best guess)
The
Host is not connectederror is thrown from the host RPC layer inpackages/server/dist/start-server.js(assertHostActiveForRead/getOpenDaemonSessionForHost). It looks like the browser-automation plugin's RPC entry point resolves the host by name in a way that doesn't match what the hub expects — possibly bypassing the same name→id lookup that the rest of core uses. Worth checking whetherbb.browserAutomation.opendoes its own host lookup vs. going through the same path asbb thread spawn --machine <name>.