startup: hung 'tailscale serve' silently blocks bb from starting at login; optional Tailscale surfaced as "Attention needed"

Hit these while following the Clean macOS installation walkthrough on macOS 15 (Darwin 25.5.0), bb via npx bb-app@latest, Node v24.18.0 installed with nvm. The npx-resolution and LaunchAgent-PATH bugs I also hit are already fixed in 8ee1e1620eae — thanks for the quick turnaround. These two are still open.

1. tailscale serve can block forever, silently preventing bb from starting at login

wrapperScript() ends with:

'/usr/local/bin/tailscale' serve --bg 38886 || true
exec "$npx_path" --yes bb-app@latest start

If Serve is not enabled on the tailnet, tailscale serve does not fail — it prints an enablement URL and then blocks indefinitely waiting for the operator to click through:

Serve is not enabled on your tailnet.
To enable, visit:

         https://login.tailscale.com/f/serve?node=<redacted>

Because it blocks rather than exits non-zero, || true never fires and the final exec is never reached. Net effect: bb never starts.

The failure is silent and looks healthy from the outside:

• launchctl list shows app.getbb.startup with a live PID and exit status 0
• the plugin's own status panel reports Startup: enabled (loaded)
• but nothing is listening on 38886, and there is no bb-app process

What it actually looks like:

$ pgrep -fl start-bb.sh
13512 /bin/zsh /Users/<user>/.bb/startup/start-bb.sh
$ pgrep -P 13512
13894 /bin/sh /usr/local/bin/tailscale serve --bg 38886   # hung, 25s+ and counting
$ lsof -nP -iTCP:38886 -sTCP:LISTEN
(nothing)

Killing the hung child let the wrapper proceed and bb came up normally, which confirms it as the sole blocker.

This hits every user whose tailnet has not enabled Serve — a default-off, tailnet-wide admin setting — and Tailscale is documented as optional, so it should never be able to block bb from starting.

Suggested fix: bound it, so a hang degrades to "no serve config" instead of "no bb".

/usr/bin/timeout 15 '/usr/local/bin/tailscale' serve --bg 38886 || true

Backgrounding it would work too, since the serve config isn't a prerequisite for bb listening on the port. Passing a non-interactive flag, if tailscale serve has one, would be even better — the timeout still costs 15s of startup latency on every login for affected users.

2. An unconfigured optional dependency is surfaced as "Attention needed"

Once bb was running under launchd with everything required in place, the panel still showed:

Attention needed — Tailscale Serve is not confirmed for bb's port.

Tailscale is optional in the README ("Optional: install and configure Tailscale for remote access"), and I had never configured Serve. But the plugin writes a tailscale serve call into the wrapper as soon as it finds the binary on disk, then treats the resulting unconfigured state as a warning — so merely having Tailscale installed is enough to produce a persistent warning about a feature the user never opted into.

Suggested options, roughly in order of preference:

• Only wire up Serve when the user explicitly opts in, rather than on binary presence
• Report an unconfigured optional dependency as informational, not "Attention needed" — reserve that for states that actually impair bb
• If the warning stays, make it actionable: surface the enablement URL, since that's the one thing standing between the user and a working serve config

The two interact: because Serve is wired up on binary presence alone, users who never wanted it are exactly the users most likely to hit issue 1.

Start by locating wrapperScript() and the startup status-panel logic in the startup plugin, then reproduce the Clean macOS installation flow with an unconfigured Tailscale Serve setup. Verify that bb starts at login even when Serve waits for enablement, and that merely having Tailscale installed does not produce an inappropriate Attention needed state.