Add per-provider usage item visibility - #3196
Conversation
The checkbox list was built only from the current menu-card model, so a lane the user hid disappeared from settings as soon as a partial refresh, an outage, or a plan change dropped it from the snapshot. The stored ID survived, but the only way back was Restore Defaults, which discards every other choice too. Append a row for each hidden item the provider is not reporting right now, labelled so it reads as unavailable rather than as a live lane.
|
🦞👀 Pull request received. I will update this pull request when review starts. |
There was a problem hiding this comment.
💡 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".
|
Codex review: needs maintainer review before merge. Reviewed August 29, 2026, 9:54 AM ET / 13:54 UTC. ClawSweeper reviewWhat this changesThe PR adds per-provider usage-row checkboxes, persists the selections, and applies them to provider menus, Settings previews, and the Overview. Merge readinessKeep open for a maintainer product decision: the implementation is coherent and proven, but it deliberately makes a new display preference part of the synced provider-config contract and maps newer partial choices onto older all-or-nothing controls on downgrade. Priority: P3 Review scores
Verification
How this fits togetherCodexBar turns provider usage snapshots into menu cards, Settings previews, and the multi-provider Overview. This change inserts a persisted per-provider visibility projection before those display surfaces. flowchart LR
A[Provider usage snapshots] --> B[Provider card model]
C[Saved provider preferences] --> D[Visibility projection]
B --> D
D --> E[Provider menu]
D --> F[Settings preview]
D --> G[Overview]
Decision needed
Why: The code safely implements either local or synced presentation, but the persistence scope and downgrade promise are product compatibility choices rather than mechanical correctness questions. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: If maintainers want row visibility to roam with provider settings, land this as the canonical synced display preference and document the intentionally approximate legacy downgrade behavior. Do we have a high-confidence way to reproduce the issue? Not applicable: this PR implements a new feature, and inspected packaged-app evidence demonstrates its intended behavior after relaunch. Is this the best way to solve the issue? Unclear: the implementation is a coherent shared solution, but maintainers must choose whether this display preference belongs in synced provider configuration. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against ce44713574f9. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (3 earlier review cycles) |
|
@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. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
# Conflicts: # Sources/CodexBar/Resources/ca.lproj/Localizable.strings # Tests/CodexBarTests/ProviderArchitectureGatekeeperTests.swift
Summary
ProviderConfig, including sync and compatibility with older clientsCloses #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
hiddenUsageItemIDsfrom 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. Commit6f56cac3badds only these proof artifacts.Additional deterministic UI-test proof
Validation
swift build -c release— passed at the exact feature-code headcodesign --verify --deep --strict— passedswift test --filter ProviderUsageItemVisibility— 8 feature tests passedmake check— passedmake test— 932 selections in 78 groups; 0 failures and 0 retriesThe 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.