provider.list_models startup probe logs "ACP agent is not authenticated." at warn on every daemon start

[bradhallett]

1. Summary

Every time the host daemon starts (or restarts), bb's first model-catalog probe for an ACP provider fires before the ACP agent has finished its auth handshake, so the daemon logs a warn-level online host RPC failed for provider.list_models with ACP agent is not authenticated. The probe failure is benign in practice — the server already logs it separately and the model picker falls back to declared/synthetic models, and the next probe succeeds once the agent's auth settles — but the daemon line fires on every single start and reads like a bug.

2. Versions and environment

• bb desktop app (installed builds under /Applications/bb.app and /Applications/bb Nightly.app, per stack traces in ~/.bb/logs/host-daemon.*.log); source audited at fff3ae8 (main).
• macOS (Apple Silicon, darwin 27.0.0). Daemon connecting to local server at http://127.0.0.1:38886.
• Providers affected: acp-cursor (observed in server logs on this host) and acp-omp (OMP ACP agent; same mechanism per the integration post-mortem). The mechanism is generic to any ACP agent whose model-list command reports an auth-required failure.
• Setup context: OMP↔bb integration audit (2026-08-20 → 2026-08-22), 45 threads; this is post-mortem Issue 4b.

3. Steps to reproduce

1. Install bb desktop with at least one ACP provider configured (e.g. custom ACP agent for omp acp, or Cursor's cursor-agent).
2. Restart the bb server/daemon (restart the desktop app, or kill and relaunch the host daemon).
3. Watch ~/.bb/logs/host-daemon.<n>.log for the first ~2 seconds after Host daemon connecting.

Observed every time; the warn lands ~0.6–0.9 s after the daemon's startup banner. No user interaction with the provider is needed. Negative space: the line appears once per daemon session (the first probe), not on later picker opens — later probes succeed once the agent's auth state settles, because probe failures are deliberately not memoized (apps/server/src/services/system/execution-options.ts, listProviderModelsMemoized: "failures are not memoized").

4. Expected vs actual

Actual, ~/.bb/logs/host-daemon.1.log line 59 (trimmed; 33 such lines across host-daemon.1.log/host-daemon.2.log, one per daemon start; each is mirrored by a server-side Failed to resolve provider models warn — 12 + 21):

{"level":40,"time":1787261024711,"component":"host-daemon","serverUrl":"http://127.0.0.1:38886","type":"provider.list_models","err":{"type":"hB","message":"ACP agent is not authenticated.","stack":"JsonRpcResponseError: ACP agent is not authenticated.\n    at MZr (.../host-daemon/dist/daemon-bundle.mjs:49:3384)\n    at gtt (.../daemon-bundle.mjs:49:…)"},"msg":"online host RPC failed"}

Server-side counterpart, ~/.bb/logs/server.1.log line 310:

{"level":40,"time":1787261024715,"component":"server","errorCode":"auth_required","errorMessage":"ACP agent is not authenticated.","errorStatus":502,"errorRetryable":false,"hostId":"host_jgwgbjvi9c","providerId":"acp-cursor","msg":"Failed to resolve provider models"}

Expected: the daemon should not warn for an auth-required probe outcome. The condition is a user state, not a daemon bug; the failure already propagates to the server, which logs it with full context (errorCode, hostId, providerId) and surfaces a model-load error in the UI. A genuinely unauthenticated agent (persistent failure) must still surface — via that server-side path, which this report does not propose to touch.

5. Evidence

Chain, each hop source-cited at fff3ae8:

• Probe origin (server): apps/server/src/services/system/execution-options.ts L679-L700 — the memo key includes the daemon session id ("a reconnected daemon may have a new CLI or account, so its first probe is fresh"), so every fresh daemon session forces a new provider.list_models probe; failures are not memoized.
• Probe execution (daemon → bridge): apps/host-daemon/src/command-router.ts L152-L196 runs the RPC and, on failure, warns online host RPC failed unless isExpectedOnlineRpcFailureError is true. That is the logging site of the noise: this.logger.warn({ type: message.command.type, err: error }, "online host RPC failed").
• Auth classification (daemon): apps/host-daemon/src/command-dispatch-support.ts L314-L335 — getErrorCode maps the message to auth_required (pattern at L149-L150). At fff3ae8 auth_required is not in EXPECTED_ONLINE_RPC_FAILURE_CODES (L135-L138: only file_too_large, provision_cancelled), so the warn fires.
• Bridge origin of the message: plugins/provider-acp/src/bridge/bridge.ts L520-L521 defines "ACP agent is not authenticated."; L774-L822 runs the agent's model-list CLI command and rejects with AcpModelListAuthRequiredError (L1015-L1022) when the CLI output looks like an auth failure (L1024-L1043); runBridgeRequest (packages/provider-bridge-protocol/src/bridge-kit/bridge-harness.ts L59-L70) serializes the throw as a JSON-RPC error, which the daemon's client re-raises as JsonRpcResponseError — matching the log stack.

Race window (measured from log timestamps, daemon ready banner → probe warn):

• host-daemon.1.log L58→L59: Host plugin worker ready @1787261024061 → warn @1787261024711 (+650 ms)
• host-daemon.1.log L114→L115: +663 ms; L123→L124: +640 ms
• host-daemon.2.log L27→L28: +706 ms; L44→L45: +731 ms; L9→L10: +888 ms

So the probe lands well under a second into the daemon session, while the ACP agent's auth state (login-state/token availability for its model-list command, and the agent-side handshake that settles after the agent process comes up) is not yet ready. The timing was measured by differencing time fields of adjacent pino lines in ~/.bb/logs/.

Counts measured by parsing the logs with a JSON-lines script: 12 matching daemon lines in host-daemon.1.log, 21 in host-daemon.2.log; identical counts for the server-side Failed to resolve provider models lines in server.1.log/server.2.log (1:1 with the daemon lines by timestamp).

Investigation report: OMP↔bb integration post-mortem, Issue 4b ("Auth-probe noise: every host-daemon start logs ACP agent is not authenticated. from provider.list_models — the probe fires before the OMP agent completes auth handshake. Benign but recurring.").

6. What you ruled out

• Not a duplicate: bb issue search for the log string / "auth probe" found nothing open or closed (cross-reference table of the fix map lists this as unfiled, minor).
• Still on main at fff3ae8: EXPECTED_ONLINE_RPC_FAILURE_CODES contains only file_too_large and provision_cancelled.
• Not a bridge misclassification: the bridge must keep failing the probe when the agent CLI genuinely reports auth-required (persistent logged-out state) — that behavior is unchanged by the proposed fix, and the server-side surfacing (modelLoadError, errorCode: auth_required) is untouched.
• Not a daemon-side retry problem either: the daemon has no notion of a "startup probe", and the server already re-probes (failures are not memoized), so the transient case self-heals; only the daemon-side duplicate warn is wrong.

7. Suggested priority and effort

Minor. Log noise only — no data or work loss, no functional damage (picker falls back; next probe succeeds). Workaround: ignore the line. Effort: small (one classification-set entry plus a regression test).

AGENT GENERATED