Fix Gemini Plus plan display from loadCodeAssist paidTier

[Yuxin-Qiao]

Summary

Fixes #1972.

Google AI Pro/Ultra consumer accounts still report loadCodeAssist.currentTier.id == free-tier, so CodexBar was labeling paid Gemini subscribers as Free.

This mirrors Gemini CLI setup behavior and prefers paidTier.name from the loadCodeAssist response when mapping the displayed plan for personal free-tier accounts.

Changes

• Parse paidTier.name from loadCodeAssist in GeminiStatusProbe
• Show the consumer subscription label (e.g. Plus, Ultra) instead of Free when present
• Preserve existing mappings for Paid, Workspace, Free, Legacy, and blank plan states
• Add fixture-backed regression test and update docs/gemini.md
• Move plan-resolution helpers into a private extension to satisfy SwiftLint type_body_length

Testing

• swift test --filter GeminiStatusProbePlanTests (9/9 passed)
• swiftlint --strict on changed files
• swiftformat on changed files

Made with Cursor

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 8, 2026, 1:44 AM ET / 05:44 UTC.

Summary
The branch teaches GeminiStatusProbe to parse and prefer loadCodeAssist.paidTier.name for displayed Gemini plans, adds fixture-backed plan tests, and updates Gemini docs.

Reproducibility: no. high-confidence live reproduction for the exact original free-tier Plus payload was established in this review. Source inspection shows current main ignores paidTier.name, and the contributor posted live output proving the paidTier field can drive the displayed plan for a real paid account.

Review metrics: none identified.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #1972
Summary: This PR is the candidate fix for the open Gemini Plus-as-Free plan display issue; the OAuth recovery PR is adjacent Gemini work, not the same root cause.

Members:

• canonical: Gemini plan displayed incorrectly #1972 - The PR body uses closing syntax for the Gemini Plus plan display report, and the diff directly changes that plan-label mapping path.
• adjacent_distinct: Fix Gemini OAuth refresh when CLI oauth2.js is missing #1984 - That PR also touches Gemini consumer-account behavior, but it handles OAuth client discovery and refresh recovery rather than displayed plan-label mapping.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• none.

Risk before merge

• [P1] The exact original free-tier Plus live payload is still represented by fixture/source evidence rather than reporter-provided redacted live output; the contributor proof does verify the same live paidTier.name field and after-fix display path for a paid account.

Maintainer options:

1. Decide the mitigation before merge
   Land the narrow paidTier-name mapping after ordinary maintainer review and CI, preserving the existing Free, Workspace, Paid, Legacy, and blank fallbacks.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• No automated repair lane is needed because the prior findings are addressed and the remaining action is ordinary maintainer review and CI completion.

Security
Cleared: The diff only changes Gemini provider response parsing, tests, and provider docs; no dependency, workflow, credential storage, or supply-chain surface was added.

Review details

Best possible solution:

Land the narrow paidTier-name mapping after ordinary maintainer review and CI, preserving the existing Free, Workspace, Paid, Legacy, and blank fallbacks.

Do we have a high-confidence way to reproduce the issue?

No high-confidence live reproduction for the exact original free-tier Plus payload was established in this review. Source inspection shows current main ignores paidTier.name, and the contributor posted live output proving the paidTier field can drive the displayed plan for a real paid account.

Is this the best way to solve the issue?

Yes. Preferring Google’s paidTier.name when present is the narrowest maintainable fix, and the PR keeps the existing fallback mappings documented and tested.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against aa401f1d8b74.

Label changes

Label justifications:

• P2: This is a bounded Gemini provider account-plan display bug with limited blast radius.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The contributor posted redacted live loadCodeAssist output plus after-fix CLI output showing the displayed plan changing from generic Paid to the Google One AI Pro paid-tier label.
• proof: sufficient: Contributor real behavior proof is sufficient. The contributor posted redacted live loadCodeAssist output plus after-fix CLI output showing the displayed plan changing from generic Paid to the Google One AI Pro paid-tier label.

Evidence reviewed

What I checked:

• Current main baseline: Current main maps Gemini plans only from currentTier and hosted-domain state, so personal free-tier accounts still display Free and paidTier.name is ignored. (Sources/CodexBarCore/Providers/Gemini/GeminiStatusProbe.swift:347, aa401f1d8b74)
• PR parses paid tier name: The PR head stores a trimmed paidTier.name from the loadCodeAssist JSON on CodeAssistStatus and passes it into plan resolution. (Sources/CodexBarCore/Providers/Gemini/GeminiStatusProbe.swift:472, 16f882aa2eb8)
• Prior standard-tier finding fixed: The latest head now returns paidTierName for standard-tier before falling back to the generic Paid label. (Sources/CodexBarCore/Providers/Gemini/GeminiStatusProbe.swift:1152, 16f882aa2eb8)
• Regression coverage added: The PR adds fixture-backed tests for both free-tier + paidTier.name displaying Plus and standard-tier + paidTier.name displaying the Google One AI Pro label. (Tests/CodexBarTests/GeminiStatusProbePlanTests.swift:256, 16f882aa2eb8)
• Docs updated: The Gemini docs now list both standard-tier + paidTier.name and free-tier + paidTier.name plan-detection cases. (docs/gemini.md:67, 16f882aa2eb8)
• Live proof reviewed: The contributor posted redacted live loadCodeAssist output with paidTier.name and after-fix CodexBarCLI usage --provider gemini output changing the displayed plan from generic Paid to the Google One AI Pro label. (16f882aa2eb8)

Likely related people:

• steipete: Current main blame attributes the existing Gemini plan mapping to the v0.41.0 integration commit, and recent commits by this handle touched Gemini helper and loadCodeAssist behavior. (role: recent area contributor and release integrator; confidence: high; commits: a83a83fa4131, 4c2ede08b80d, 7accce1c1c2f; files: Sources/CodexBarCore/Providers/Gemini/GeminiStatusProbe.swift, Tests/CodexBarTests/GeminiStatusProbePlanTests.swift, docs/gemini.md)
• 381181295: GitHub commit metadata maps the original Gemini CLI provider integration to this handle, including the Gemini status probe surface this PR changes. (role: original Gemini provider introducer; confidence: medium; commits: 47015e38e7e3; files: Sources/CodexBarCore/Providers/Gemini/GeminiStatusProbe.swift, Tests/CodexBarTests/GeminiStatusProbeTests.swift)
• Yuxin-Qiao: This handle authored recent merged Gemini consumer-tier migration work touching GeminiStatusProbe, Gemini tests, and docs/gemini.md, so they have adjacent history beyond this PR. (role: recent adjacent contributor; confidence: medium; commits: 63c69fdcc47f; files: Sources/CodexBarCore/Providers/Gemini/GeminiStatusProbe.swift, Tests/CodexBarTests/GeminiConsumerTierMigrationTests.swift, docs/gemini.md)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (3 earlier review cycles)

• reviewed 2026-07-08T02:27:08.324Z sha b8a40a1 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-08T03:26:17.690Z sha b8a40a1 :: needs real behavior proof before merge. :: [P2] Honor paidTier.name for standard-tier accounts
• reviewed 2026-07-08T04:05:47.897Z sha fec0b0b :: needs changes before merge. :: [P3] Document standard-tier paid tier names

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b8a40a1f93

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Prefer paid tier names before generic standard labels

When loadCodeAssist returns currentTier.id == "standard-tier" together with paidTier.name—a shape used by Google One AI Pro responses—the new paid-tier parsing is still bypassed because this branch returns the generic "Paid" first. Gemini CLI’s setup path prefers loadRes.paidTier?.name ?? loadRes.currentTier.name, so these paid consumer accounts will continue to be mislabeled instead of showing the actual subscription name.

Useful? React with 👍 / 👎.

[Yuxin-Qiao]

Live behavior proof (contributor account, redacted)

Contributor has an active Google One AI Pro subscription. Captured from the contributor machine on 2026-07-08 (tokens/project IDs redacted).

loadCodeAssist (live)

{
  "currentTier": {
    "id": "standard-tier",
    "name": "Gemini Code Assist"
  },
  "paidTier": {
    "id": "g1-pro-tier",
    "name": "Gemini Code Assist in Google One AI Pro"
  },
  "cloudaicompanionProject": "dari***"
}

CodexBar output (current main + this PR branch)

Account: yxqiao46@gmail.com
Plan: Paid

Interpretation

• This contributor account is standard-tier, so it already maps to Paid on current main and is not the #1972 failure path (free-tier mislabeled as Free).
• It still confirms Google's live loadCodeAssist response includes a real paidTier object with a human-readable name, matching the fixture shape used in this PR and Gemini CLI setup (paidTier?.name ?? currentTier.name).
• #1972 targets consumer Google AI Plus accounts that report currentTier.id == free-tier while paidTier.name is a consumer label such as Plus; the added fixture test covers that path.

Upstream contract reference

Gemini CLI setup uses the same precedence:

userTierName: loadRes.paidTier?.name ?? loadRes.currentTier.name

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

[Yuxin-Qiao]

Live proof after standard-tier + paidTier.name fix

Pushed commit fec0b0b — resolveAccountPlan now honors paidTier.name for standard-tier (aligns with Gemini CLI paidTier?.name ?? currentTier.name).

CLI (CodexBarCLI usage --provider gemini, contributor account)

Account: yxqiao46@gmail.com
Plan: Gemini Code Assist In Google One Ai Pro

Before: Plan: Paid (generic fallback for standard-tier)

Unit test

uses paid tier name for standard tier subscriptions — asserts Gemini Code Assist in Google One AI Pro from mocked loadCodeAssist.

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.