Agents on a host whose server moved to bb Connect get HTTP 401 from bb: launcher prefers config.json serverUrl over BB_SERVER_URL

[brsbl]

Summary

On a machine whose bb server was moved to bb Connect, every agent thread on that machine gets HTTP 401: Unauthorized from the bb CLI, for example from bb thread show, bb project list, and bb machine list. The host daemon gives each thread an authenticated loopback proxy in BB_SERVER_URL. The bb-app launcher replaces it with serverUrl from the machine's config.json (the public https://<handle>.getbb.app URL), and the CLI calls that URL without the machine credential. Restarting doesn't help, because the config file is unchanged.

Versions and environment

• Affected machine: bb 0.43.4-nightly.35739502552.1, installed through the desktop app and npm into ~/.bb, macOS on Apple silicon. It was originally the desktop-hosted server and is now a remote host of a bb Connect server (https://<handle>.getbb.app).
• Minimal repro below: bb 0.43.5-nightly.35773768107.1, macOS 15.2 (Intel), Node 24.18.1.
• Code cited at main dea024ee6cdc8d482ca13713684e8495a112e142.

Steps to reproduce

Minimal, needs no Connect server; it shows only the precedence:

D=$(mktemp -d)
echo '{"serverUrl":"https://example.invalid"}' > "$D/config.json"
(unset BB_CLI; BB_DATA_DIR="$D" BB_SERVER_URL=http://127.0.0.1:59999 bb --help | grep 'BB_SERVER_URL:')
rm "$D/config.json"
(unset BB_CLI; BB_DATA_DIR="$D" BB_SERVER_URL=http://127.0.0.1:59999 bb --help | grep 'BB_SERVER_URL:')
rm -rf "$D"

On a real affected machine:

1. Move a desktop-hosted bb server to bb Connect, so the old desktop becomes a remote host whose ~/.bb/config.json contains serverUrl: https://<handle>.getbb.app and serverHeaders with the machine credential.
2. Start any agent thread on that machine and have it run bb thread show <any-thread-id> --json.

Expected vs actual

Minimal repro, actual:

  BB_SERVER_URL: https://example.invalid      # config.json present: the explicit env var is ignored
  BB_SERVER_URL: http://127.0.0.1:59999       # config.json absent: the env var is used

Expected: the explicitly set BB_SERVER_URL is used in both cases.

Affected machine, actual, from an agent thread whose env has BB_SERVER_URL=http://127.0.0.1:59089 (the daemon's machine-auth proxy):

$ bb thread show thr_… --json
Error: HTTP 401: Unauthorized
{"ok": false, "error": {"code": "http_401", "message": "HTTP 401: Unauthorized"}}

$ bb --help | grep BB_SERVER_URL
  BB_SERVER_URL: https://<handle>.getbb.app

With NODE_DEBUG=net, the CLI connects directly to the Connect hostname on port 443, and never to the loopback proxy.

Expected: the CLI uses the daemon-provided proxy and the command succeeds. The proxy itself works: curl "$BB_SERVER_URL/api/v1/threads/thr_…" returns 200 application/json, and "$BB_CLI" thread show thr_… --json, which bypasses the launcher, succeeds.

Evidence

• The launcher gives config.serverUrl priority over env.BB_SERVER_URL: packages/bb-app/src/launcher.ts#L980-L987, applied to the CLI env at #L1389.
• The launcher turns serverHeaders into BB_SERVER_HEADERS (#L996-L1014), but the CLI's direct requests to the Connect URL still return 401, so the credential doesn't reach them.
• The daemon hands threads the authenticated loopback proxy as BB_SERVER_URL (apps/host-daemon/src/start-host-daemon.ts#L135, apps/host-daemon/src/runtime-shell-env.ts#L413).
• Through the proxy: /api/v1/threads/:id, /api/v1/projects, and /api/v1/hosts return 200, while /health returns 401 (the Connect sign-in page).
• Likely introduced with server migration (Add experimental server migration between machines #3783) and moving a desktop-hosted server away (Install the machine service when a desktop-hosted server moves away #4175), which leave serverUrl in the old desktop's config.json.

What you ruled out

• Not a stale or expired machine credential: the daemon's proxy, which uses the same serverHeaders, authenticates fine.
• Not shell configuration: no BB_SERVER_URL in shell profiles, and ~/.local/bin/bb only execs the installed launcher.
• Still present at 0.43.5-nightly.35773768107.1 (minimal repro) and in main at dea024ee6 (code above).
• No duplicate found in open or closed issues.

Suggested priority and effort

Every CLI call from every agent on an affected machine fails, so agents can't coordinate, report back, or open terminals. The workaround is to invoke "$BB_CLI" directly. Small fix: prefer an explicitly set BB_SERVER_URL over config.serverUrl in resolveServerUrl, or at least when the daemon provides it, plus a regression test. Terminals the user opens themselves don't set BB_SERVER_URL, so they keep resolving to config.serverUrl.

Checks

• I reproduced this on the latest release or on main, or I say above that I could not.
• I searched open and closed issues for the same problem.
• If an agent wrote this, the body ends with > AGENT GENERATED and links the thread or report.

Found while coordinating agent workers on the affected machine, in bb thread thr_ixu6r7h84m.

AGENT GENERATED

[bb-slop-cop]

🚨 SLOP COP 🚨 · new-issue-autopilot

Classification: Bug · Priority: Medium · Effort: Low. Preserved bug, remote, and cli; added partial-repro.

Reproduction report: PARTIALLY REPRODUCED, high confidence in the URL-selection cause. A focused regression fails in two clean checkouts of origin/main: saved configuration replaces the injected thread proxy URL. The CLI transport also does not forward BB_SERVER_HEADERS; live Connect 401s remain unverified.

No PR: an existing passing test explicitly requires config-over-environment precedence, so changing that policy exceeds the automatic simple-fix gate.