Version: bb 0.36.0 (macOS)
Problem
When an unknown command triggers the plugin-contribution probe (bb memory ..., bb connect), any fetch failure prints:
bb isn't running — open the bb app, then re-run this command.
The probe catches the error with a bare catch (apps/cli/src/plugin-cli-proxy.ts), so ECONNREFUSED, EPERM/EACCES from a sandboxed shell, and timeouts are indistinguishable — and the message asserts a fact the code has no evidence for. Agents act on it: they declare a healthy bb dead, abandon queued work, and ask the user to open an app that is already open.
Observed in production: an agent's sandboxed shell lost network access while bb was up and listening (lsof showed the listening socket and live connections). Every bb memory ... command printed "bb isn't running"; the agent reported the backend as dead three times and relaunched duplicate jobs.
Steps to reproduce
$ BB_SERVER_URL=http://192.0.2.1:38886 bb memory catalog
bb isn't running — open the bb app, then re-run this command.
The same constant appears for a refused connection, a blocked one (EPERM), and a timeout. Only ECONNREFUSED actually means nothing is listening.
Expected
Only ECONNREFUSED justifies "bb is not running". Blocked connections and timeouts should name the address and the errno so the reader can tell "this shell is blocked" from "the server is down".
Related: the built-in-command formatter losing .cause is #1189 — different code path (this probe discards the error before any formatter runs).
Version: bb 0.36.0 (macOS)
Problem
When an unknown command triggers the plugin-contribution probe (
bb memory ...,bb connect), any fetch failure prints:The probe catches the error with a bare
catch(apps/cli/src/plugin-cli-proxy.ts), so ECONNREFUSED, EPERM/EACCES from a sandboxed shell, and timeouts are indistinguishable — and the message asserts a fact the code has no evidence for. Agents act on it: they declare a healthy bb dead, abandon queued work, and ask the user to open an app that is already open.Observed in production: an agent's sandboxed shell lost network access while bb was up and listening (
lsofshowed the listening socket and live connections). Everybb memory ...command printed "bb isn't running"; the agent reported the backend as dead three times and relaunched duplicate jobs.Steps to reproduce
The same constant appears for a refused connection, a blocked one (EPERM), and a timeout. Only ECONNREFUSED actually means nothing is listening.
Expected
Only ECONNREFUSED justifies "bb is not running". Blocked connections and timeouts should name the address and the errno so the reader can tell "this shell is blocked" from "the server is down".
Related: the built-in-command formatter losing
.causeis #1189 — different code path (this probe discards the error before any formatter runs).