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 27, 2026, 8:11 AM ET / 12:11 UTC. ClawSweeper reviewWhat this changesThis PR adds per-provider checkboxes that persist which usage rows appear in provider menus, Settings previews, and the Overview. Merge readinessKeep open: current main still has only the two provider-specific visibility controls, while this branch implements the requested generic selection model. The implementation and packaged-app proof are credible, but adopting a synced persisted preference and replacing the existing controls needs maintainer product approval plus a current-main merge refresh. Priority: P3 Review scores
Verification
Live VerificationCommand: Result: FAIL (failed) — execution before step 1 Assertions:
How this fits togetherCodexBar turns provider usage snapshots into card models, which feed the provider menu, Settings preview, and Overview. This change keeps an unfiltered model for Settings controls and applies a persisted per-provider filter to the rendered card surfaces. flowchart LR
A[Provider usage snapshots] --> B[Unfiltered usage card]
B --> C[Visible usage item settings]
C --> D[Persisted provider preference]
D --> E[Filtered usage card]
B --> F[Settings selection list]
E --> G[Provider menu]
E --> H[Overview]
Decision needed
Why: The implementation is coherent, but permanently expanding the user preference and sync contract is a product and upgrade-policy choice rather than a mechanical defect repair. Before merge
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: If maintainers want a generic per-provider display filter, land this opt-in model after refreshing it against current main and preserving the tested legacy-toggle migration and old-client sync behavior. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a requested new presentation capability, and the supplied real packaged-app captures directly demonstrate its intended behavior. Is this the best way to solve the issue? Unclear: the shared model is narrower and more maintainable than adding provider-specific switches, but accepting its persistent sync contract requires maintainer product judgment. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against d9e950e49c95. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
History |
|
@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. |
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.