fix: honor usage direction in plugin cards - #2837
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
clawsweeper
Bot
added
P2
|
Codex review: needs maintainer review before merge. Reviewed August 10, 2026, 6:35 AM ET / 10:35 UTC. ClawSweeper reviewWhat this changesRoutes the existing used-versus-remaining preference into user-installed provider cards so their percentage text and progress-bar fill use one clamped presentation. Regression provenancePossible regression — probable (reproduction; reviewed change). No predecessor PR is attributed. Merge readinessThis owner-authored PR is a focused repair for the linked user-plugin card inconsistency and should remain open for normal merge validation. The submitted native before/after evidence and targeted regression tests support the change; required CI was still in progress at review time. Priority: P2 Review scores
Verification
How this fits togetherCodexBar collects provider usage snapshots and renders them in menu-bar cards. User-installed provider plugins have a dedicated card view that now consumes the same usage-direction setting as built-in cards before producing text and bar output. flowchart LR
A[Provider plugin snapshot] --> B[User plugin card]
C[Usage-bars preference] --> D[Quota presentation]
B --> D
D --> E[Percentage label]
D --> F[Progress bar]
E --> G[Native menu card]
F --> G
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: Land this localized presentation repair once the required checks validate the reviewed head, leaving provider snapshots and CLI semantics unchanged. Do we have a high-confidence way to reproduce the issue? Yes. The PR provides a deterministic current-main before/after native-menu scenario using the same local plugin snapshot and the remaining-mode preference, alongside focused presentation tests. Is this the best way to solve the issue? Yes. Passing the existing setting into the separate plugin-card presentation boundary reuses the established built-in-card behavior without altering provider data or unrelated output. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against abad945bc07f. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5a422a14f4
ℹ️ 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".
| UsageProgressBar( | ||
| percent: window.usedPercent, | ||
| percent: presentation.percent, | ||
| tint: self.tint, | ||
| accessibilityLabel: "\(title) usage") |
There was a problem hiding this comment.
When Usage bars fill is set to As remaining, this now feeds the remaining percentage into UsageProgressBar, but the accessibility label still hard-codes "Primary usage"/"Secondary usage". VoiceOver users therefore hear an inverted value such as “Primary usage, 96 percent” while the visual label says “96% left”; derive the label from showUsed (as the built-in cards do with usage used vs usage remaining) so the announced semantics match the configured direction.
Useful? React with 👍 / 👎.
|
Landed on Tested:
No provider payload, CLI output, or fixed-semantics spend/headroom surface changed; the repair is confined to user-plugin menu-card presentation. |
1 participant
Summary
Usage bars fillpreference into user-installed provider menu cardsRoot cause
Built-in rich cards already normalize each metric to the selected used/remaining direction before rendering. The bespoke user-plugin card bypassed that model and hard-coded
window.usedPercent,"% used", and a used-oriented bar. As a result,As remainingaffected built-in cards but not user-installed providers.The fix keeps this local to the user-plugin presentation boundary. CLI output, provider snapshots, and semantically fixed spend/headroom displays are unchanged.
Validation
CODEXBAR_SUPPRESS_TEST_KEYCHAIN_ACCESS=1 swift test --filter UserPluginQuotaPresentationTests— 3 tests passedCODEXBAR_SUPPRESS_TEST_KEYCHAIN_ACCESS=1 swift test --filter 'StatusMenuUsageDisplayTests|UsageMenuCardLayoutTests'— 11 tests passedmake check— passedNative before/after proof
Both captures set
Usage bars fillto As remaining and use the same deterministic local plugin snapshot: 4% used, 96% remaining. The manifest retains its existing approved identity; the temporary fetch body makes no network request. The surrounding Sub2API data is synthetic, and personal information is hidden.main)Fixes #2749