* fix(ui): surface provider-usage failures instead of empty panels
* fix(ui): complete typed route-data fixtures and stop reporting cancelled usage requests as failed
- Add providerUsageUnavailable to the five UsageRouteData fixtures in
gateway-source-replacement.test.ts; check-test-types passes again.
- requestProviderUsage reports failed only for non-cancelled rejections; an
aborted request is the caller superseding its own load, not an outage.
- Cover answered, failed, and cancelled outcomes.
* chore(ui): keep ProviderUsageFetch local to its module
* fix(ui): clear the provider failure flag when an aggregate usage load fails
- A failed aggregate refresh says nothing about provider usage; the stale
flag no longer keeps claiming the last provider request failed after a
later usage.cost or sessions.usage rejection.
- Sequential regression: usage.status failure, then an aggregate failure,
ends with the flag cleared.
* test(ui): type the usage route data on the test element
* test(ui): cover provider usage request outcomes
* fix(ui): model provider usage request outcome
* fix(ui): preserve provider usage outcomes
* fix(ui): resolve provider usage build
`openclaw models auth list` printed `Auth state store:
<state>/agents/main/agent/openclaw-agent.sqlite` on every install created since
a8a9f284fb, and that file does not exist. Credentials now persist in the shared
state database, so an operator debugging auth was sent to the wrong file while
the listed profiles resolved correctly from somewhere else.
`resolveAuthStorePathForDisplay` and `resolveAuthStatePathForDisplay` named the
agent-local file whenever an agent dir was supplied. That matched storage before
shared-auth ownership moved and stopped matching afterwards. The same helpers
feed `models auth order`, `models list --status`, the auth overview, two
auto-reply directive surfaces, and the `path` field of doctor's auth
HealthFindings, so structured diagnostics pointed at the wrong file too.
Display now mirrors the loader's own selection: an agent with a local auth store
shows its own database, otherwise the shared owner. Both helpers move to the
`paths.ts` barrel so they can consult `hasLocalAuthProfileStoreSource` without a
cycle back through `path-resolve`. Nothing about storage or loading changes.
`model-auth-provider` no longer derives the agent dir from the store path -- that
would have reported the state directory once the shared owner is selected -- and
uses the caller's agent dir instead.
Production -4 LOC.
* fix(onboard): honor secret-input-mode ref for the generated gateway token
`openclaw onboard --secret-input-mode ref` was silently ignored for
`gateway.auth.token`: onboarding generated the token and wrote it into
`openclaw.json` as a plaintext string, so `openclaw doctor` warned about
`gateway.auth.token` on the install it had just created. The flag was
honored for provider credentials, so an operator who explicitly opted into
references still ended up with a plaintext secret and a remediation
(`openclaw secrets configure`) that cannot migrate a self-generated value,
because it validates a ref by resolving one that already exists.
Setup mints this token itself, so reference mode now provisions it:
- an ambient OPENCLAW_GATEWAY_TOKEN keeps an `env` ref to that variable, so a
later rotation stays authoritative instead of being pinned by a stale copy
- anything else (freshly generated, or an existing plaintext token being
migrated) goes into the shared SQLite secret store as a write-only `secret`
entry, with config holding only `{source:"store",...}`
An existing store entry wins over a freshly generated one, so reruns never
rotate a token already paired with clients. The store write precedes the
config write: a ref persisted without its value would leave the gateway
unauthenticatable, while an orphaned entry is reused by the next run.
The interactive wizard had the same dead end and is fixed the same way.
Default (plaintext) onboarding is unchanged.
User impact: `--secret-input-mode ref` now keeps the gateway token out of
openclaw.json, and a fresh install no longer self-reports a plaintext-secret
warning.
* test(onboard): split gateway onboarding suite under the max-lines gate
The added gateway auth-token tests pushed
onboard-non-interactive.gateway.test.ts to 1014 lines, over the max-lines
limit (check-lint-core-3). Repo policy is to split, never suppress.
Extract the shared vi.mock/harness preamble into
onboard-non-interactive.gateway.test-mocks.ts, following the existing
agent-command.test-mocks.ts pattern, and move the four gateway auth-token
storage tests into their own suite. The reachability mock becomes a holder
object so both suites can swap it across the module boundary, and hoisted
mocks are re-exported in a separate export clause because Vitest rejects
exporting a vi.hoisted binding at its declaration.
Test set is unchanged: the it-declaration multiset matches the pre-split
file exactly, with no duplication across the two suites.
* test(onboard): give the shared gateway onboarding mocks unique export names
check-export-name-collisions flagged `runtime` and `readConfigFileSnapshotMock`
as colliding with program.test-mocks.ts and plugins-cli-test-helpers.ts once the
gateway onboarding preamble became a shared module. Rename the exports to
gatewayOnboardRuntime / gatewayOnboardConfigSnapshotMock per the repo's
unique-export-name rule; suites alias them locally so the assertions read the
same as before.
* test(tooling): route the new gateway auth-token suite from its test helper
test-projects asserts which suites a change to
onboard-non-interactive.test-helpers.ts should run. The new
onboard-non-interactive.gateway-auth-token.test.ts imports that helper, so it
belongs in the expected routing plan.
* fix(auth): create a fresh install with canonical shared-auth ownership
A brand-new install was born in the retired shape. `parseSharedAuthStoreOwnership(undefined)` returns
`legacy-main`, which is the correct compat answer for an existing install whose profiles really do
live in the main agent database -- but a new install has no ownership row and no legacy data either,
so onboarding wrote its first credential into `agents/main/agent/openclaw-agent.sqlite` and the
operator's very first `openclaw doctor` told them to run a migration for state OpenClaw had created
seconds earlier. The main agent also stayed undeletable until they did.
Record `auth.sharedStore = {"location":"state-db"}` when the shared store is first written and the
legacy source provably holds nothing: no `auth_profile_store` row, no `auth_profile_state` row, and
no unfinished cleanup ledger entry. Any legacy row, or any inspection error, leaves ownership alone
so doctor keeps owning the relocation. The check is memoized per ownership generation with a WeakSet
keyed on the process-stable ownership object, so a legacy root is inspected once per process and
doctor's committed flip naturally invalidates it.
The legacy row inspection moves out of `state-migrations.shared-auth-store.ts` into the auth-profiles
owner so doctor and runtime share one contract instead of runtime importing migration code. Explicit
main-agent credential writes now follow the shared target, which is a no-op on legacy roots where
both routes already resolve to the same file.
No SQLite schema change; the ownership row is data. Existing installs take exactly the path they take
today.
* fix(auth): preserve JSON-era shared credentials
* docs(auth): explain why doctor names the main agent dir during a shared JSON import
* test(auth): assert shared-owner runtime reads
* test(doctor): read migrated catalog credentials through the shared owner
A fresh root records state-db shared ownership, so the model-catalog credential migration persists into the shared store rather than the agent file. The assertion read the agent file directly and saw an empty store while all three credentials were present and correct in state/openclaw.sqlite. Read through the owner for that state root instead of pinning storage layout; the credential contents are still asserted exactly.
* fix(cli): message send cannot address channels from npm-installed plugins
Target resolution, channel enumeration, and target-prefix inference only consulted the process-root channel registry, so message CLI actions running against a scoped registry handle could not see installed channel plugins even though selection and send execution could. Carry the selection-resolved plugin into target resolution, fall back to the registry handle in scope for resolver-owned lookups, and list runtime-visible channel plugins for channel selection and prefix inference.
* fix(cli): keep runtime-visible channel reads import-light
Importing channel-resolution from the target-prefix leaf pulled the plugin bootstrap/loader graph into every consumer and reordered module loading under distant vi.mock factories (subagent-registry.steer-restart failed in CI with a hoisting TDZ). Move the scoped-registry reads into a dedicated import-light module, share its registry matcher with channel-resolution, and drop the mock workarounds the heavier graph had required.
* chore(ui): re-baseline startup JS for the outbound scoped-registry reads
CI measured 348285 B gzip on the merge ref (baseline 347023 + 1056 tolerance). The first CI round measured 347784 B, so most of the growth is main-side drift since the 2026-08-19 baseline; the outbound changes account for roughly 60 B in a local A/B. Updated with the documented --update-baseline --startup-js-bytes flow using the CI value.
* Revert "chore(ui): re-baseline startup JS for the outbound scoped-registry reads"
This reverts commit f60bd4c45f.
* fix(cli): plan broadcast accounts from runtime-visible channel plugins
The unscoped message broadcast --account planner still enumerated only process-root plugins, so a registry-scoped installed channel could not join broadcast candidate planning. Use the runtime-visible read and cover the scoped and no-scope paths.
* fix(cli): honor scoped channel plugin precedence
* fix(outbound): preserve loaded plugin fallback order
---------
Co-authored-by: Patrick Erichsen <patrick.a.erichsen@gmail.com>
Peter Steinberger