Desktop app can't reach getbb.app behind TLS-inspecting proxies (Zscaler): trust the OS certificate store #5260

The workflow

Sign in to a bb account (Settings → sign in, or bb account login) from the macOS desktop app on a corporate network that inspects TLS (Zscaler here; Netskope, Palo Alto and similar work the same way). The proxy re-signs HTTPS traffic with a corporate root CA that IT installs in the macOS System keychain.

What happens today

The sign-in dialog shows:

Couldn't reach getbb.app. Check your connection, then try again.

The network is fine. ~/.bb/logs/server.1.log shows the real cause is certificate verification:

WARN: [server] periodic bb-community catalog refresh failed: unable to get local issuer certificate
WARN: [server] [plugin:bb-account] rpc login.start failed: network

curl https://getbb.app returns 200 and Safari works, because both use the system trust store. bb's bundled Node (Electron's ELECTRON_RUN_AS_NODE runtime, v24.20.0) only uses its built-in Mozilla CA list, so it rejects the corporate root.

The usual workaround, NODE_EXTRA_CA_CERTS in ~/.zshenv, doesn't help, because a Dock or Finder launch never reads shell config. Users have to run launchctl setenv from a LaunchAgent and restart bb.

Repro (no proxy setup inside bb; just a machine behind TLS inspection with the root in the keychain):

B=/Applications/bb.app/Contents/MacOS/bb
S='fetch("https://getbb.app").then(r=>console.log("ok",r.status)).catch(e=>console.log("ERR",e.cause?.code))'
env -i HOME=$HOME ELECTRON_RUN_AS_NODE=1 $B -e "$S"
# ERR UNABLE_TO_GET_ISSUER_CERT_LOCALLY
env -i HOME=$HOME ELECTRON_RUN_AS_NODE=1 NODE_USE_SYSTEM_CA=1 $B -e "$S"
# ok 200
env -i HOME=$HOME ELECTRON_RUN_AS_NODE=1 $B -e 'const tls=require("tls");tls.setDefaultCACertificates([...tls.getCACertificates("default"),...tls.getCACertificates("system")]);'"$S"
# ok 200

The same failure hits everything else the server or daemon fetches over TLS: the plugin catalog refresh, bb Connect, and plugin installs.

What you would expect

bb trusts the OS certificate store in addition to its bundled roots, the way Chromium, curl and Safari already do on the same machine. Sign-in then works out of the box behind corporate TLS inspection, and keeps working when IT rotates the root.

Suggested change: at process start in the server and host daemon, next to the existing installSocketTypeOfServiceGuard() calls (server, host-daemon):

import tls from "node:tls";
// Trust OS-managed roots too (corporate TLS inspection: Zscaler, Netskope, ...)
tls.setDefaultCACertificates([
  ...tls.getCACertificates("default"),
  ...tls.getCACertificates("system"),
]);

This covers every launch path: the desktop app, launchd/systemd services on remote machines, and npx bb-app. A lighter alternative is to default NODE_USE_SYSTEM_CA: "1" in createBbAppProcessEnv, with the user's env still taking precedence. That only covers processes launched by the desktop app.

Two smaller related fixes:

1. Tell users about certificate errors. hosted.ts maps every fetch failure to status: null → "network", and the connect UI renders that as "Check your connection". Detecting UNABLE_TO_GET_ISSUER_CERT_LOCALLY, SELF_SIGNED_CERT_IN_CHAIN and the like in error.cause.code and showing something like "getbb.app's TLS certificate isn't trusted. A corporate proxy may be inspecting HTTPS." would have saved the debugging.
2. Pass NODE_USE_SYSTEM_CA to npm installs. The browser-automation installer's npm env allowlist forwards SSL_CERT_FILE and NODE_EXTRA_CA_CERTS but not NODE_USE_SYSTEM_CA (installer.ts).

Context and alternatives

• bb desktop 0.45.0 (latest), installed as the desktop app on macOS 26 (Darwin 25.6.0), Apple Silicon. Code links are pinned to main at bb5a62f3b64b2f00cb63a39d171e5acdba32ff81.
• Workaround today: a LaunchAgent that runs launchctl setenv NODE_USE_SYSTEM_CA 1 (or NODE_EXTRA_CA_CERTS=<pem>) at login, then a full restart of bb. macOS has no other persistent way to set env vars for GUI apps, since /etc/launchd.conf was removed.
• Ruled out: DNS and connectivity (getbb.app resolves and curl returns 200), and system proxy settings (none set; the inspection is transparent).
• Searched open and closed issues for certificate, TLS, Zscaler, keychain, NODE_EXTRA_CA_CERTS and NODE_USE_SYSTEM_CA, and found no duplicate.
• Suggested priority: hits every user behind TLS inspection, which is common at large companies. A workaround exists but needs terminal and launchd knowledge, and the current error message points away from the cause. Effort is small.

AGENT GENERATED