BMCLI Execution Modes
Reference version: BMCLI 1.6.3. Command names, parameters and machine-readable fields retain their source spelling.
| Mode | When | Channel open/close | Latency |
|---|---|---|---|
| Standalone | Daemon not running | Per-command (~2.75s overhead) | Slow |
| Daemon | Daemon running | Once at startup | ~50ms |
When a daemon is running, commands that support persistent execution are
forwarded to it. Some discovery, file-only, Help, update, and health commands
remain local; some stateful operations require the daemon. Consult command Help
for the installed-version execution requirement. The daemon avoids repeated
USB open/close and preserves channel/protocol state.
Daemon lifecycle commands (daemon start|stop|status) and existing commands
that inspect or change daemon-only state remain governed by their own Help;
they do not gain a standalone-equivalent path from any UDS Helper behavior.
If no live daemon PID exists, BMCLI may execute the command in standalone mode.
If a daemon PID is live but TCP communication fails, BMCLI returns a non-zero
IPC error and does not fall back to standalone. This prevents an enumeration
index such as 0 from resolving to a different physical device while the daemon
holds the originally selected device exclusively. Connection attempts may be
retried only before any command bytes are sent; BMCLI never automatically
re-sends a command that may perform a hardware action.
Explicit start: BMCLI does not automatically create a daemon. Start it with
bmcli daemon start when a workflow needs persistent channel state, and stop
only a daemon owned by that workflow.
Source of truth: BMCLI 1.6.3 repository documentation. Run bmcli help <category> <action> --format=json for the exact contract of the installed version.