Add per-provider usage item visibility

[psufka]

Summary

• add per-provider Visible usage items checkboxes for every rendered quota or usage row
• apply each selection consistently to provider menus, Settings previews, and Overview
• persist selections in ProviderConfig, including sync and compatibility with older clients
• migrate the existing Codex Spark and Claude Daily Routines choices into the shared model
• keep hidden rows individually restorable if a provider temporarily stops reporting them

Closes #3182.

This is intended to supersede #3123, whose author recommended this implementation as the more complete version. #3124 remains separate because it chooses which window feeds the menu-bar percentage rather than which rows are shown.

Behavior

All rows remain visible by default, including newly reported rows. This changes presentation only; fetching, alerts, and quota calculations are unchanged.

Hidden unavailable rows remain in Settings as (... unavailable) so they can be restored without resetting other choices. Codex Limit Reset Credits is offered only when that section exists.

Real packaged-app proof

These are captures from a real local setup with live provider data. Personal information was hidden with CodexBar's native Hide Personal Info setting; no synthetic fixture was used.

Settings and live preview

Codex has Weekly and Limit Reset Credits selected; both Spark windows and Credits are hidden. The live Settings preview above the controls reflects the same choice.

Provider menu after relaunch

The exact feature-code head (7fa30cb72) was Release-built, installed into the packaged app, terminated, and relaunched. The Codex provider menu still shows only Weekly and Limit Reset Credits.

Overview after relaunch

The relaunched exact-head app shows Codex Weekly + Limit Reset Credits, Grok Weekly, and Cursor Grok Bot, with no empty sections or layout gaps.

Redacted live-run log, persisted non-secret configuration, build hash, and capture provenance

The Settings capture was taken immediately before the final production commit; that commit only excludes hiddenUsageItemIDs from the provider refresh fingerprint. It changes refresh bookkeeping, not UI or rendering. The exact-head provider-menu and Overview captures above reverify the final rendered behavior. Commit 6f56cac3b adds only these proof artifacts.

Additional deterministic UI-test proof

Validation

• swift build -c release — passed at the exact feature-code head
• packaged bundle codesign --verify --deep --strict — passed
• exact-head packaged app terminate/relaunch — passed; selections persisted
• swift test --filter ProviderUsageItemVisibility — 8 feature tests passed
• make check — passed
• make test — 932 selections in 78 groups; 0 failures and 0 retries

The ClawSweeper test attempt stopped before step 1 because its environment could not download pnpm; the same focused test passes locally as recorded above.

Credit

Includes Nguyễn Nam Long's unavailable-row restoration patch with original commit authorship preserved.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b71d91784e

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 25, 2026, 5:50 PM ET / 21:50 UTC.

ClawSweeper review

What this changes

The PR adds per-provider checkboxes that persist which usage rows appear in provider menus, Settings previews, and the Overview.

Merge readiness

⚠️ Ready for maintainer review - 3 items remain

No actionable patch defect was found, and the added packaged-app evidence resolves the prior proof blocker. This PR remains open for maintainer product-direction review because it adds a synced, per-provider settings surface and current-main/history refresh could not be completed from the grafted checkout.

Priority: P3
Reviewed head: 6f56cac3bf387b05e97d183ad680d640f1679336
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	Strong real-app proof and focused coverage support a good patch; product acceptance and a current-main refresh remain maintainer decisions.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): Redacted packaged-app screenshots show the selected Settings rows and the resulting post-relaunch provider menu and Overview, with a recorded exact-head build and persisted-state log.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): Redacted packaged-app screenshots show the selected Settings rows and the resulting post-relaunch provider menu and Overview, with a recorded exact-head build and persisted-state log.
Evidence reviewed	5 items	Shared visibility model: The model derives stable descriptors for metrics, credits, and Codex reset credits, preserves hidden unavailable rows, and filters only presentation fields. All claimed display surfaces use the filter: Settings builds its controls from the unfiltered model and displays a filtered preview; the status-card builder applies the same saved selection, which is also used to build Overview rows. Persistence and old-client sync handling: The new optional ProviderConfig field round-trips through config coding, while an omitted field from an older sync client preserves the local value; an explicit empty array clears it.
Findings	None	None.
Security	None	None.

Live Verification

Command: swift test --filter ProviderUsageItemVisibility

Result: FAIL (failed) — execution before step 1 run: sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.24.0.tgz

sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.24.0.tgz

Assertions:

• FAIL expect_output: ProviderUsageItemVisibilityTests

How this fits together

CodexBar turns provider usage snapshots into menu cards, Settings previews, and the merged Overview. The PR stores a per-provider visibility selection and applies it to those presentation surfaces without changing provider fetching or alerts.

flowchart LR
A[Provider usage snapshots] --> B[Menu card model]
C[Saved visibility choices] --> D[Visibility filter]
B --> D
D --> E[Provider menu]
D --> F[Settings preview]
D --> G[Overview]

Loading

Decision needed

Question	Recommendation
Should CodexBar adopt a synced per-provider visibility preference for every currently rendered usage row, replacing the Codex Spark and Claude Daily Routines one-off controls?	Sponsor the shared visibility model: Accept the unified per-provider controls and retain the compatibility checks for legacy choices and older sync payloads.

Why: This is a new persistent, cross-device settings surface; correctness and runtime proof do not establish the preferred long-term product contract.

Before merge

• Resolve merge risk (P1) - This introduces a synced persisted preference; the branch has source-level old-client coverage, but a maintainer should refresh the three-way merge against current main before landing because this checkout lacks current-main history.
• Complete next step (P2) - A maintainer must choose whether the new synced per-provider settings surface is desired before any merge or automated repair action.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Change surface	47 files affected; +834/-74	The feature spans rendering, persisted configuration, sync compatibility, tests, proof artifacts, and localized Settings copy.

Root-cause cluster

Relationship: fixed_by_candidate
Canonical: #3182
Summary: This PR is an implementation candidate for the canonical per-provider visibility request; the older visibility PR partially overlaps, while the percent-window PR is distinct.

Members:

• canonical: Feature request: choose visible usage items per provider #3182 - The PR explicitly connects its shared row-visibility controls to this feature request and implements its described presentation surfaces.
• partial_overlap: Add per-provider quota row visibility #3123 - Both propose generic per-provider usage-row visibility, but this PR uses a broader shared presentation and compatibility model; neither branch is merged.
• adjacent_distinct: Add per-provider menu bar percent window picker #3124 - That PR changes which quota window drives menu-bar percentage, not which usage rows are displayed.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge-risk options

Maintainer options:

1. Refresh upgrade compatibility before landing (recommended)
   Rebase or merge-test against current main and confirm an existing configuration and an older sync client preserve the intended visibility state.
2. Decline the new settings contract
   Keep the existing narrower controls if maintainers do not want a synced per-provider row-visibility surface.

Technical review

Best possible solution:

If maintainers want this broader settings direction, land the single shared visibility model with its default-visible behavior and retained legacy-preference compatibility.

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

Not applicable: this PR adds a new configurable presentation capability rather than repairing a reported current-main failure.

Is this the best way to solve the issue?

Unclear: the shared implementation is coherent and proof-backed, but maintainers must decide whether this new synced settings contract is the preferred product direction.

AGENTS.md: found and applied where relevant.

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

Labels

Label changes:

• add proof: sufficient: Contributor real behavior proof is sufficient. Redacted packaged-app screenshots show the selected Settings rows and the resulting post-relaunch provider menu and Overview, with a recorded exact-head build and persisted-state log.
• add proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Redacted packaged-app screenshots show the selected Settings rows and the resulting post-relaunch provider menu and Overview, with a recorded exact-head build and persisted-state log.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): Redacted packaged-app screenshots show the selected Settings rows and the resulting post-relaunch provider menu and Overview, with a recorded exact-head build and persisted-state log.
• remove status: 📣 needs proof: Current PR status label is status: 👀 ready for maintainer look.
• remove rating: 🦪 silver shellfish: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.

Label justifications:

• P3: This is a user-facing presentation preference, not a reliability or security regression.
• merge-risk: 🚨 compatibility: The PR adds a persisted and synced ProviderConfig field that must remain safe across upgrades and mixed client versions.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): Redacted packaged-app screenshots show the selected Settings rows and the resulting post-relaunch provider menu and Overview, with a recorded exact-head build and persisted-state log.
• proof: sufficient: Contributor real behavior proof is sufficient. Redacted packaged-app screenshots show the selected Settings rows and the resulting post-relaunch provider menu and Overview, with a recorded exact-head build and persisted-state log.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Redacted packaged-app screenshots show the selected Settings rows and the resulting post-relaunch provider menu and Overview, with a recorded exact-head build and persisted-state log.

Evidence

What I checked:

• Shared visibility model: The model derives stable descriptors for metrics, credits, and Codex reset credits, preserves hidden unavailable rows, and filters only presentation fields. (Sources/CodexBar/ProviderUsageItemVisibility.swift:46, 6f56cac3bf38)
• All claimed display surfaces use the filter: Settings builds its controls from the unfiltered model and displays a filtered preview; the status-card builder applies the same saved selection, which is also used to build Overview rows. (Sources/CodexBar/StatusItemController+MenuCardModel.swift:167, 6f56cac3bf38)
• Persistence and old-client sync handling: The new optional ProviderConfig field round-trips through config coding, while an omitted field from an older sync client preserves the local value; an explicit empty array clears it. (Tests/CodexBarTests/SyncModelTests.swift:76, 6f56cac3bf38)
• After-fix packaged-app proof: The redacted log records an exact-head release build, app termination/relaunch, persisted selections, and the observed menu and Overview results; the three prepared images directly show the Settings selection and rendered post-relaunch views. (.github/pr-proof/provider-usage-item-visibility-live.log:13, 6f56cac3bf38)
• History and current-main limitation: The local checkout exposes only a grafted PR head; prior PR commit objects and the supplied current-main SHA are unavailable locally, and the remote lookup failed DNS resolution. The source review is therefore limited to the PR head and supplied GitHub metadata. (6f56cac3bf38)

Likely related people:

• psufka: PR metadata attributes the shared visibility implementation and refresh-fingerprint follow-up to this contributor; no usable pre-PR main history is available in the grafted checkout. (role: feature author and recent area contributor; confidence: low; commits: 4764cc8e65f6, 7fa30cb72f79; files: Sources/CodexBar/ProviderUsageItemVisibility.swift, Sources/CodexBar/SettingsStore.swift)
• J2TeamNNL: The PR’s recorded commit metadata attributes the hidden-unavailable-row restoration behavior to this contributor. (role: unavailable-row restoration author; confidence: low; commits: 61a2e4735de4; files: Sources/CodexBar/ProviderUsageItemVisibility.swift)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Refresh the branch against current main and verify the persisted/synced preference through the resulting merge.

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 (1 earlier review cycle)

• reviewed 2026-08-25T19:07:13.200Z sha 7fa30cb :: needs real behavior proof before merge. :: none

[psufka]

@clawsweeper re-review

Added redacted real packaged-app captures for Settings, the Codex provider menu, and Overview, plus exact-head build/relaunch and persisted-config evidence. These use live provider data, not synthetic fixtures.

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.