[obs-gap:openclaw] openclaw: connected provider account priority not captured

[github-actions]

Automated harness-observability audit found a gap for openclaw.

• Harness exposes: Models settings now let a user manage multiple connected provider accounts and set supported account priority (i.e. which credential/account is preferred per provider) directly in the harness.
• ClawMetry misses: The adapter's provider/model surface only covers ClawRouter (_clawrouter_detect, reading ~/.openclaw/clawrouter/config.json) and NemoClaw sandbox inference config (_sandbox_inference_configs). Neither reads the new connected-accounts/priority list, so a misconfigured or deprioritized account (a real cause of auth failures/cost surprises) is invisible.
• Where (harness): CHANGELOG.md 2026.9.3 highlights (#132451)
• Severity: medium
• Closest capability: new

Filed by scripts/harness/audit.py. Fingerprint: hgap-b5710e3e2e (used to dedupe — keep it in the body).

[vivekchand]

Cannot find the feature in the shipped harness, so a reader would be guesswork

Verified the gap is real (no connected-accounts reader anywhere in clawmetry/adapters/openclaw.py). But before writing one, I looked for the format in the installed OpenClaw 2026.9.3 (/opt/homebrew/lib/node_modules/openclaw, 1391f7c):

connectedAccounts   0 matches
connected_accounts  0 matches
accountPriority     0 matches

And on this machine:

~/.openclaw/auth.json                     absent
~/.openclaw/clawrouter/*.json             absent
any ~/.openclaw/**/*.json carrying those keys   none

For contrast, the sibling issue #5747's feature is discoverable the same way: meetingTranscriptDb, meeting_transcript_sessions, meetingSessionId and friends are all present in dist/, with a findable schema.

So this issue's claim came from the changelog wording ("Models settings now let a user manage multiple connected provider accounts and set supported account priority"), and the audit had no adapter-side or harness-side artifact to point at. The persisted names appear to be auth.json (99 refs in dist/) and credentials.json (22), neither of which exists here.

What would unblock it: a machine with more than one provider account connected, and the key names that actually appear in its auth.json (key names only, never values, since that file holds credentials). Without that, a reader would be written against invented field names and would silently read nothing.

Leaving it open and unclaimed rather than shipping a guess.

---

Generated by Claude Code

[vivekchand]

Hi @vivekchand! Took a careful look — including your prior comment, which is thorough and correct. Here's the plan:

The problem
ClawMetry can't see which provider accounts a user has connected or which they've prioritised, so a misconfigured or deprioritised account (a real cause of auth failures and unexpected model choices) is invisible in the dashboard.

Approach
The fix follows the same pattern as _clawrouter_detect in clawmetry/adapters/openclaw.py:

1. Discover the schema — read the actual key names from ~/.openclaw/auth.json on a machine with two or more provider accounts connected. The file exists (99 refs in dist/), but the keys for multi-account state (connectedAccounts? accounts? something else) only appear in a multi-account install. This is the only thing blocking a correct implementation.

2. Add _connected_accounts_detect(openclaw_home) in clawmetry/adapters/openclaw.py (near the existing _clawrouter_detect helper) — reads ~/.openclaw/auth.json, extracts the accounts list and any priority ordering, returns a structured dict. Fail silently (return {}) when the file is absent or single-account.

3. Wire it into the provider/model surface — call it from the same place that calls _clawrouter_detect and merge the result into the snapshot, so it shows up in /api/overview and the existing provider panel without any new endpoint.

4. Test with a fixture — add a test in tests/test_adapters_openclaw.py (following the existing fixture pattern there) with a synthetic auth.json carrying the discovered keys. Two cases: single-account (returns nothing new), multi-account with priority set (returns the expected structure).

Estimated change
~40–60 lines across 2 files (clawmetry/adapters/openclaw.py, tests/test_adapters_openclaw.py).

What would unblock it
Just the key names — not the values — from a multi-account auth.json. Something like:

{ "<key1>": [...], "<key2>": "..." }

Even a redacted snippet showing the top-level structure is enough. Alternatively, if you know which OpenClaw dist file persists the accounts list, a quick grep -r 'connectedAccount\|accountPriority\|providerOrder' /path/to/dist/ would do it.

This one's bigger than I'm comfortable autonomously shipping since it would require guessing field names the harness hasn't shipped to a discoverable location yet. Leaving the plan here for your review — if you can drop the key names (or point me at the dist path), I'll pick it up next run and wire it in.

---

Generated by Claude Code