Version: bb 0.36.0 (macOS)
Problem
Any backend-touching command fails with no diagnostic information:
$ bb thread list --json
Error: fetch failed
fetch failed is a Node constant used for every fetch failure. The real error is on error.cause and is discarded, so "blocked by a sandbox/firewall" is indistinguishable from "bb is not running".
Steps to reproduce
Point the CLI at an address nothing is serving:
$ BB_SERVER_URL=http://127.0.0.1:1 bb thread list --json
Error: fetch failed
The same output appears for any connect-level failure — refused, blocked, wrong port, wrong host — because the message is a constant. bb status still succeeds throughout, since it reads local files and never contacts the backend, which makes it look like a partial outage.
Root cause
The cause carries the diagnosis. Blocked by a sandbox:
cause = connect EPERM 127.0.0.1:38886
code=EPERM errno=-1 syscall=connect port=38886
EPERM means the server is healthy and the caller isn't permitted to reach it; ECONNREFUSED would mean it's down. That distinction is present in the error object and never surfaces.
Where it is dropped
console.error(`Error: ${ii(r)}`), process.exit(1)
function ii(e){ return e instanceof Error ? e.message : String(e) }
ii reads .message only. grep -c "\.cause" over host-daemon/dist/bb returns 0. The exit code is 1 for all failures, so there is nothing to branch on either.
Fix
function ii(e){
if (!(e instanceof Error)) return String(e);
let msg = e.message, c = e.cause;
while (c instanceof Error) { msg += ': ' + c.message; c = c.cause; }
return msg;
}
Verified against the live failure:
current -> Error: fetch failed
unwrapped -> Error: fetch failed: connect EPERM 127.0.0.1:38886 - Local (0.0.0.0:0)
Also worth considering: a distinct exit code for connection failures, and mapping ECONNREFUSED to bb is not running at <serverUrl> and EPERM/EACCES to cannot reach bb at <serverUrl> - connection blocked.
Version: bb 0.36.0 (macOS)
Problem
Any backend-touching command fails with no diagnostic information:
fetch failedis a Node constant used for every fetch failure. The real error is onerror.causeand is discarded, so "blocked by a sandbox/firewall" is indistinguishable from "bb is not running".Steps to reproduce
Point the CLI at an address nothing is serving:
The same output appears for any connect-level failure — refused, blocked, wrong port, wrong host — because the message is a constant.
bb statusstill succeeds throughout, since it reads local files and never contacts the backend, which makes it look like a partial outage.Root cause
The cause carries the diagnosis. Blocked by a sandbox:
EPERMmeans the server is healthy and the caller isn't permitted to reach it;ECONNREFUSEDwould mean it's down. That distinction is present in the error object and never surfaces.Where it is dropped
iireads.messageonly.grep -c "\.cause"overhost-daemon/dist/bbreturns0. The exit code is1for all failures, so there is nothing to branch on either.Fix
Verified against the live failure:
Also worth considering: a distinct exit code for connection failures, and mapping
ECONNREFUSEDtobb is not running at <serverUrl>andEPERM/EACCEStocannot reach bb at <serverUrl> - connection blocked.