Add Charm Hyper provider (API key + session) - #2502
Conversation
Co-authored-by: JavaGT <java@javagrant.com> Co-authored-by: Akshay Prabhu <12824090+akshayprabhu200@users.noreply.github.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 83c38bd083
ℹ️ 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".
| if context.settings?.hyper?.cookieSource == .off { | ||
| [HyperAPIFetchStrategy()] | ||
| } else { | ||
| [HyperSessionFetchStrategy(), HyperAPIFetchStrategy()] |
There was a problem hiding this comment.
Honor selected Hyper API-token accounts
When a Hyper token account is selected, the fetch context carries that account's API key in context.env, but Auto mode still tries hyper.web first. If the user is also signed in to Hyper in Chrome, every per-account refresh can succeed with the ambient browser session before the selected account's API key is used, so account snapshots and the active balance can be sourced from the wrong Hyper account. Please skip the session strategy (or force .api) when context.selectedTokenAccountID is set for this API-key token-account provider.
Useful? React with 👍 / 👎.
|
Codex review: needs changes before merge. Reviewed August 12, 2026, 6:09 AM ET / 10:09 UTC. ClawSweeper reviewWhat this changesAdds Charm Hyper as an opt-in balance provider using a browser session or API key, with settings, CLI, menu presentation, documentation, and tests. Merge readiness⛔ Blocked by patch quality or review findings - 6 items remain This owner-authored provider implementation remains useful, but it needs a rebase onto the current manifest architecture, a selected-token-account routing fix, and real-account session proof before merge. Priority: P2 Review scores
Verification
How this fits togetherCodexBar resolves configured credentials or browser sessions into provider fetch strategies, then displays returned balances in its menu bar, cards, and CLI. This PR adds Charm Hyper to that provider pipeline. flowchart LR
A[Settings and environment] --> C[Authentication selection]
B[Chrome Hyper session] --> C
C --> D[Credits endpoint]
D --> E[Balance validation]
E --> F[Provider manifests]
F --> G[Menu bar, card, and CLI]
Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Copy recommended automerge instructionTechnical reviewBest possible solution: Rebase onto current main, regenerate both manifests, make selected token accounts authoritative over ambient sessions, then attach redacted real-account proof for session preference, fallback, and API-key balance display. Do we have a high-confidence way to reproduce the issue? Not applicable as a bug report; mocked strategy tests exist, but the real session flow has not been exercised on this head. Is this the best way to solve the issue? No—the branch needs the current manifest registration path and explicit token-account precedence before its session design can be considered merge-ready. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against a90dfed5c264. LabelsLabel justifications:
EvidenceAcceptance criteria:
What I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (10 earlier review cycles; latest 8 shown)
|
My previous merge commit staged unresolved conflict markers. Resolve all four conflicts for real: keep both the Hyper and xAI provider slugs, icon cases, and prepaid-balance cost sections; take main's provider ID list with `hyper` reinserted; bump the advertised provider count to 67 across README, docs, and all 23 site locales. Keeping both balance-only cost blocks pushed providerCostSection past the 150-line body limit, so extract the six limit-less prepaid-balance providers into `balanceOnlyCostSection`.
Summary
HYPER_API_KEY, saved keys, or token accountsGET https://hyper.charm.land/v1/creditsendpoint and render the returned value as a native HC balanceThis combines and credits the work from @JavaGT in #2379 and @akshayprabhu200 in #2476 for #2318. Both contributors are recorded as co-authors on the combined commit.
Authentication order
Auto mode follows the existing descriptor pipeline convention used by mixed-auth providers:
hyper.web: a signed-inhyper.charm.landsession, imported from Chrome or supplied as a manual Cookie header.hyper.api: an explicit API key from configuration,HYPER_API_KEY, or a token account.A missing or expired session may fall back to the API key. Malformed successful responses fail closed so an upstream contract change is not hidden. With neither source configured, CodexBar reports setup guidance instead of a fake empty balance.
Verification
swift test --filter Hyper— 14 tests passedmake checkThe focused coverage includes API-key-only routing, session preference when both sources exist, neither-configured guidance, cookie and bearer request construction, login redirects, malformed/short responses, native HC menu/card/CLI presentation, provider registration, and icon availability.
Live verification blocker
Live verification is pending — Peter is on the Charm Hyper waitlist. Do not merge this PR until a real account confirms the combined behavior.
When access arrives, verify all of the following on this exact PR head:
hyper.charm.landin Chrome and confirm Auto selectshyper.web, including when an API key is also configured./v1/creditsrequest returns HTTP 200 with a numericbalance; record the actual cookie/session contract without exposing cookie values or account identity.hyper.apiwithout browser or Keychain prompts beyond the expected Chrome cookie access./v1/creditsand the value matches the Charm dashboard.Balance: <amount> HCand never showCost,/ 0, a fabricated limit, or a reset countdown.No authenticated Hyper request, browser-cookie import, or live account UI capture was performed for this combined head.