feat: add SuperGrok paste, source picker, and Heavy plan to Grok - #3010
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
![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: cf47a6cedc
ℹ️ 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".
| selectedAccountSourceModeResolver: { base, account, _ in | ||
| guard let account else { return base } | ||
| return GrokCredentialRouting.resolve( | ||
| tokenAccountToken: account.token, | ||
| manualCookieHeader: nil).sourceMode ?? base |
There was a problem hiding this comment.
When the app remains on the default Auto source and a user selects a pasted bearer or cookie account, this resolver is never consulted: ProviderRegistry.swift:44-57 passes the configured implementation source directly into ProviderFetchContext. Auto can therefore succeed against the local Grok CLI or auth file before reaching the selected credential, displaying usage for the wrong account; route the app source through selectedAccountSourceMode as the CLI does.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in ebc4a8b. See updated PR description.
| var cacheObservation = CookieHeaderCache.observeForConditionalMutation(provider: .grok) | ||
| var lastCookieError: Error? | ||
| if let cached = cacheObservation.entry { | ||
| if cookieSource != .off, let cached = cacheObservation.entry { |
There was a problem hiding this comment.
When a valid Chrome-derived cookie is already cached and the user switches to Manual or selects a cookie token account, this branch returns data from the cached session before the configured manual header is attempted. The newly selected credential can therefore show usage for the previous browser account indefinitely; cached browser sessions should only be considered for .auto.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in ebc4a8b. See updated PR description.
| if let file = try? fileResult.get() { | ||
| return .success(file) |
There was a problem hiding this comment.
If ~/.grok/auth.json exists but is expired, this returns it instead of the pasted GROK_OAUTH_TOKEN; GrokOAuthFetchStrategy.fetch then immediately rejects it as missing credentials. This breaks the advertised recovery path of pasting a bearer when the auth file is expired until the user deletes that file, so only a non-expired file should take precedence before checking pasted credentials.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in ebc4a8b. See updated PR description.
| let manualHeader = cookieSettings?.manualCookieHeader? | ||
| .trimmingCharacters(in: .whitespacesAndNewlines) |
There was a problem hiding this comment.
When a user follows the field placeholder and pastes Cookie: sso=..., this only trims whitespace, after which the value is assigned to the HTTP Cookie header verbatim as Cookie: sso=.... The resulting cookie name is malformed and authentication fails; normalize this setting with CookieHeaderNormalizer, as is already done for cookie-shaped token accounts.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in ebc4a8b. See updated PR description.
|
|
||
| func isAvailable(_ context: ProviderFetchContext) async -> Bool { | ||
| let cookieSource = context.settings?.grok?.cookieSource ?? .auto | ||
| #if os(macOS) |
There was a problem hiding this comment.
On Linux, a configured manual cookie or cookie token account can never make the new web request because both the availability check and the manual-header fetch are compiled only for macOS. Manual headers require no browser import or Keychain access, and the descriptor's browser-support exemption otherwise permits this source, so codexbar usage skips the only applicable strategy; keep only cache and browser-import operations inside the macOS guard.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in ebc4a8b. See updated PR description.
clawsweeper
Bot
added
merge-risk: 🚨 auth-provider
|
Codex review: needs maintainer review before merge. Reviewed August 17, 2026, 11:08 AM ET / 15:08 UTC. ClawSweeper reviewWhat this changesThis PR adds Grok source selection, pasted SuperGrok OAuth and grok.com cookie credentials, and routes each source through the appropriate usage-fetch path. Merge readinessKeep open for maintainer acceptance: no blocking patch defect was found, but this makes pasted OAuth bearers and web cookies a supported persistent Grok credential surface. Priority: P2 Review scores
Verification
How this fits togetherCodexBar’s Grok provider turns CLI credentials, pasted credentials, and browser cookies into a usage snapshot for the menu-bar app and CLI. The selected source controls which credential path reaches Grok billing services and what account data is displayed. flowchart LR
A[User selects Grok source] --> B[Credential selection]
B --> C[Source-mode routing]
C --> D[CLI proxy or web billing]
D --> E[Usage snapshot]
E --> F[Menu bar and CLI display]
Decision needed
Why: The implementation is coherent, but accepting long-lived user credentials and cookie headers as a first-class provider surface is a support and security-boundary choice that source review cannot make. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: If the credential surface is accepted, merge with the explicit source modes and existing secret-redaction path intact, treating CLI, OAuth, and cookies as independently supportable routes. Do we have a high-confidence way to reproduce the issue? Not applicable as a bug report; the supplied screenshot directly shows the new OAuth settings path producing a live usage result. Is this the best way to solve the issue? Yes conditionally: the routing is narrow, preserves explicit source choices, and reuses existing credential infrastructure, but maintainers must first accept the new persistent auth surface. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 2fe9de487f8a. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (11 earlier review cycles; latest 8 shown)
|
clawsweeper
Bot
added
rating: 🐚 platinum hermit
|
@clawsweeper re-review Restored four-space indent in GrokProviderDescriptor.swift. |
|
🦞👀 Re-review progress:
|
clawsweeper
Bot
added
rating: 🦐 gold shrimp
|
@clawsweeper re-review Honor explicit source modes (Auto-only remapping) and prefer a selected pasted bearer over ~/.grok/auth.json. |
|
🦞👀 |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
@clawsweeper re-review Selected Cookie: accounts now override the Grok settings snapshot. Auto still prefers SuperGrok OAuth over a browser session by design; explicit CLI/Web stay authoritative. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
@clawsweeper re-review Auto is now CLI → cookies → OAuth, matching current main. Selected pasted bearers and explicit SuperGrok OAuth still go OAuth-only. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
clawsweeper
Bot
removed
status: ⏳ waiting on author
|
@clawsweeper re-review Auto now matches current main: CLI → auth.json CLI-proxy → cookies. A failed Auto proxy no longer swallows cookies with bearer gRPC. Explicit SuperGrok OAuth still does proxy then gRPC. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
@clawsweeper re-review Auto now matches current main: CLI → auth.json CLI-proxy → cookies → bearer gRPC. Explicit SuperGrok OAuth stays cookie-free. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
@clawsweeper re-review Auto cookie failures now fall through to bearer gRPC. Explicit Browser cookies still stop there. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
clawsweeper
Bot
added
rating: 🐚 platinum hermit
Keep Auto-only remapping for selected SuperGrok accounts so CLI/web stay authoritative. Prefer GROK_OAUTH_TOKEN over a valid auth.json so a selected pasted bearer cannot display the local grok login account.
Project Cookie: token accounts into the Grok settings snapshot so Auto and Web fetches use the selected header instead of a configured or browser cookie.
Preserve the existing Grok Auto fallback: CLI, then browser cookies, then OAuth. Selected pasted bearers and explicit SuperGrok OAuth still use the OAuth path only.
Auto is CLI, then SuperGrok OAuth CLI-proxy, then browser cookies. A failed Auto proxy no longer falls through to bearer gRPC, so cookies still run next. Explicit SuperGrok OAuth keeps proxy-then-gRPC.
Auto is now CLI, SuperGrok OAuth CLI-proxy, browser cookies, then bearer gRPC. Explicit SuperGrok OAuth stays cookie-free proxy-then-gRPC.
|
@clawsweeper re-review Rebased onto main after 0.52.0. CHANGELOG entries stay under 0.52.1. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
# Conflicts: # CHANGELOG.md
|
Thanks @oakimov! This landed via #3014, which carried your commits onto current main and fixed the CI failures (Grok's GROK_OAUTH_TOKEN injection contract missing from the credential characterization catalog, plus shifted architecture-gatekeeper anchors from the UsageStore+TokenAccounts insertions). GitHub shows this PR as merged since #3014 contains all your commits — the changelog credits you. |
2 participants
Summary
Add SuperGrok OAuth paste and grok.com cookie auth on the Grok provider, beside existing
grok login/~/.grok/auth.json.Cookie:/name=value→ cookies,xai-rejected).oauthis never an empty pipeline~/.grok/auth.json(or~/.grokif the file is missing), not CodexBarconfig.json/v1/settingssubscription_tier_display); this PR reusesGrokPlanRebased onto
mainafter 0.52.0. Codex review comments addressed inebc4a8bf8.Screenshots
Live SuperGrok OAuth on the Grok card:
grok-cli-proxy, SuperGrok plan, weekly 38% left.Also in-tree at
docs/screenshots/grok-supergrok-oauth-settings.png.Commands run
swift test --filter 'GrokSettingsReaderTests|GrokAuthTests|GrokCreditsProxyFetcherTests|GrokWebBillingFetcherTests'make check(pre-rebase)