Expose all provider accounts from serve

[VACInc]

Draft / WIP. Authored against main; the change is a close-read patch that has not been compiled or test-run on macOS yet (see "What was not tested"). Opening as a draft to gather direction before running the full build+test matrix.

Summary

High Level TLDR

codexbar serve exposed multiple Codex and claude-swap accounts, but ordinary token-account providers only returned the
active account. This change makes /usage fetch every configured account and makes dashboard snapshots project those
results into one provider row with accounts[], using the same configured account order and active selection as the app.

Root Cause

The app menu reads all ProviderTokenAccountData.accounts, but the headless resolver returned only the clamped active
account unless an interactive CLI caller explicitly passed --all-accounts. The dashboard also disabled its existing
all-account mode and only attached nested accounts through the claude-swap adapter.

Before behavior was established by source and observed route output: Codex /usage returned multiple rows, while a
generic provider with multiple configured accounts returned only one active row and no dashboard accounts field.

What changed

• Generalized serve account collection to every token-account provider.
• Kept Codex on its reconciled live, managed, and profile-home account projection.
• Grouped account usage into providers[].accounts, with the active account retaining provider-level fields.
• Kept single-account providers on the existing shape.
• Preserved claude-swap precedence and separated its cache/in-flight account mode.
• Added opaque account IDs, identity redaction, per-account errors, and collection-level accountsError handling.

Real behavior proof

Linux static proof completed:

• git diff --check a0d77c37f9cc85d8703eb0a501c6764112f5a6e8..HEAD passed.
• The final patch exactly matches commit ee0ae94e312007e63ee42b8226a7ff2e3f0e3ef8.

macOS compilation, focused tests, and live fixture route output are not available from this Linux environment. The
exact macOS commands and route matrix are documented in REPORT-IMPL.md; their copied output must be added before merge.

Verification

Added DashboardMultiAccountSnapshotTests for generic projection, active selection, redaction, opaque IDs, row-local
failure, collection failure, single-account compatibility, and headless all-account resolution. Updated serve cache-mode
coverage and retained the existing claude-swap snapshot suite.

Pending on macOS:

• swiftformat Sources Tests
• swiftlint --strict
• focused dashboard, claude-swap, and serve-router tests
• swift build
• make test
• make check
• before/after route performance samples

What was not tested

• Compilation or tests, because this Linux host has no Swift toolchain.
• AppKit/macOS runtime behavior.
• Real provider, Keychain, bridge, or network account calls.
• Before/after latency and provider call volume.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed August 12, 2026, 11:59 AM ET / 15:59 UTC.

ClawSweeper review

What this changes

The branch fetches every configured token account in serve mode and groups multi-account usage into dashboard provider rows with nested account data.

Merge readiness

⛔ Blocked until real behavior proof is added - 9 items remain

Keep open: the unchanged head still breaks the documented selected-account cardinality of the existing /usage API, and it lacks required macOS and real-route proof.

Priority: P2
Reviewed head: ee0ae94e312007e63ee42b8226a7ff2e3f0e3ef8

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The patch has useful targeted tests, but the unresolved public-contract regression and missing real behavior proof keep it from merge readiness.
Proof confidence	🧂 unranked krab (1/6)	Needs real behavior proof before merge: The PR body explicitly reports no macOS build, test, or live after-fix route run; add redacted /usage and dashboard snapshot evidence after the compatibility repair. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🦪 silver shellfish (2/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs real behavior proof before merge: The PR body explicitly reports no macOS build, test, or live after-fix route run; add redacted /usage and dashboard snapshot evidence after the compatibility repair. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	5 items	Documented existing contract: Current documentation says the cards-only multi-account behavior leaves codexbar usage and codexbar serve at their existing output cardinality. Branch changes the default route behavior: The branch’s default serve context enables all accounts, and the per-provider command preserves that setting except for Claude with claude-swap; generic /usage requests therefore collect every configured account. Resolver confirms the cardinality change: The branch passes the all-accounts flag into generic token-account resolution, which returns every configured account instead of the clamped active account.
Findings	1 actionable finding	[P1] Preserve the selected-account /usage default
Security	None	None.

How this fits together

Serve mode collects provider usage into the legacy /usage response and the dashboard snapshot API. Configured account selection controls provider fetches, then the dashboard projects those results into provider and account rows.

flowchart LR
    A[Configured provider accounts] --> B[Serve usage collection]
    B --> C[Provider account fetches]
    C --> D[Usage response]
    C --> E[Dashboard snapshot]
    E --> F[Provider row]
    F --> G[Account list]

Loading

Before merge

• Add real behavior proof - Needs real behavior proof before merge: The PR body explicitly reports no macOS build, test, or live after-fix route run; add redacted /usage and dashboard snapshot evidence after the compatibility repair. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Preserve the selected-account `/usage` default (P1) - This repeats the prior blocker on the unchanged head: generic /usage now enables all configured accounts, so a two-account provider returns two rows and performs both credential-backed fetches. Current docs explicitly preserve serve output cardinality; keep all-account collection for dashboard snapshots or add an explicit versioned/opt-in usage API.
• Resolve merge risk (P1) - Existing /usage pollers can receive multiple rows and secondary-account failures where they previously received one active-account result.
• Resolve merge risk (P1) - Polling every configured account serially increases provider calls and can exceed request deadlines or provider rate limits.
• Resolve merge risk (P1) - The PR body reports no macOS compilation, test execution, or after-fix route output; lint and lint-build-test are currently failing.
• Complete next step (P2) - The contributor must repair the documented API regression and supply real macOS route proof; proof from their configured environment cannot be automated by the repair lane.
• Improve patch quality - Restore the selected-account /usage default and add a focused serve-route regression test.
• Improve patch quality - Run the repository-required macOS validation, including make test and make check, and resolve the failing lint jobs.
• Improve patch quality - Attach redacted after-fix output for both a two-account dashboard snapshot and the preserved /usage response, then update the PR body for re-review.

Findings

• [P1] Preserve the selected-account /usage default — Sources/CodexBarCLI/CLIServeCommand.swift:1294-1295

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Patch surface	production +193/-44, tests +234/-20, docs +22/-16	The 15-file change expands two public serve contracts, so compatibility and after-fix route evidence matter more than unit coverage alone.

Merge-risk options

Maintainer options:

1. Preserve the existing /usage contract (recommended)
   Keep generic /usage on the active account while using all-account collection for dashboard snapshots, with a regression test for both routes.
2. Version or opt in to expanded usage output
   If all-account /usage is desired, expose it through a separately documented opt-in or versioned response rather than changing existing pollers silently.
3. Pause the public API expansion
   Pause this draft if the dashboard capability is not worth adding an explicit compatible API surface.

Technical review

Best possible solution:

Keep legacy selected-account behavior for /usage, collect all accounts only for dashboard snapshots, and require an explicitly versioned or opt-in API before widening /usage output.

Do we have a high-confidence way to reproduce the issue?

Yes—source-reproducible with high confidence: configure a generic provider with two token accounts and call /usage?provider=<id>; this branch returns both while current main resolves only the active account.

Is this the best way to solve the issue?

No—the dashboard improvement need not silently alter the established /usage contract; scope all-account collection to snapshots or add an explicit compatible API path.

Full review comments:

• [P1] Preserve the selected-account /usage default — Sources/CodexBarCLI/CLIServeCommand.swift:1294-1295
  This repeats the prior blocker on the unchanged head: generic /usage now enables all configured accounts, so a two-account provider returns two rows and performs both credential-backed fetches. Current docs explicitly preserve serve output cardinality; keep all-account collection for dashboard snapshots or add an explicit versioned/opt-in usage API.
  Confidence: 0.98

Overall correctness: patch is incorrect
Overall confidence: 0.98

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against c4ed34d0e44a.

Labels

Label justifications:

• P2: This is a bounded public API and dashboard behavior change, with a concrete compatibility blocker but no demonstrated urgent outage.
• merge-risk: 🚨 compatibility: The default /usage response changes from one selected generic account to every configured account.
• merge-risk: 🚨 auth-provider: The branch invokes credentials and account resolution for inactive configured provider accounts on routine serve requests.
• merge-risk: 🚨 availability: Serial collection across all configured accounts increases provider work within the existing serve request deadline.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body explicitly reports no macOS build, test, or live after-fix route run; add redacted /usage and dashboard snapshot evidence after the compatibility repair. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

What I checked:

• Documented existing contract: Current documentation says the cards-only multi-account behavior leaves codexbar usage and codexbar serve at their existing output cardinality. (docs/cli.md:75, c4ed34d0e44a)
• Branch changes the default route behavior: The branch’s default serve context enables all accounts, and the per-provider command preserves that setting except for Claude with claude-swap; generic /usage requests therefore collect every configured account. (Sources/CodexBarCLI/CLIServeCommand.swift:1294, ee0ae94e3120)
• Resolver confirms the cardinality change: The branch passes the all-accounts flag into generic token-account resolution, which returns every configured account instead of the clamped active account. (Sources/CodexBarCLI/CLIUsageCommand.swift:288, ee0ae94e3120)
• Feature history: The current serve/dashboard surface was recently developed in the dashboard grouping work, providing the main ownership trail for this review. (Sources/CodexBarCLI/CLIServeCommand.swift:888, 3a9a86c0cf00)
• Not implemented on current main: The PR head is not an ancestor of current main, so its multi-provider account behavior is not already merged or released. (Sources/CodexBarCLI/CLIServeCommand.swift:915, ee0ae94e3120)

Likely related people:

• steipete: Authored the recent serve dashboard, claude-swap snapshot, and grouped dashboard history; this is the central current-main ownership trail. (role: recent serve and dashboard contributor; confidence: high; commits: 3a9a86c0cf00, 8cf897bc9a44, e795d349cb84; files: Sources/CodexBarCLI/CLIServeCommand.swift, Sources/CodexBarCLI/DashboardSnapshotBuilder.swift, docs/cli.md)
• umutkeltek: Introduced the one-shot dashboard command that shares the snapshot producer affected by this change. (role: dashboard command introducer; confidence: medium; commits: e12a824fdb49; files: Sources/CodexBarCLI/CLIDashboardCommand.swift)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (2 earlier review cycles)

• reviewed 2026-08-10T01:11:37.792Z sha ee0ae94 :: needs real behavior proof before merge. :: none
• reviewed 2026-08-11T20:17:53.244Z sha ee0ae94 :: needs real behavior proof before merge. :: [P1] Preserve the selected-account /usage default