fix(providers): close Windows Antigravity and Grok gaps - #6
Conversation
Antigravity 2.3.1 installs its pairable OAuth client in %LOCALAPPDATA%\Programs\antigravity\resources\bin\language_server.exe. Add that evidence-backed Windows candidate with a user-home fallback while preserving environment overrides, macOS app-bundle discovery, OAuth protocol, refresh transactions, and account-scope handling. Focused Antigravity tests pass (22 tests), including Windows root ordering, fallback, deduplication, and empty-root coverage. git diff --check passes. Co-Authored-By: Claude <noreply@anthropic.com>
Include a fixed cli/oauth/other source classification in the existing AgentUsage smoke summary so Windows live gates can distinguish Antigravity local IDE and OAuth fallback paths. Preserve the existing window-count/error status and never print raw errors, identity, quota values, paths, or credentials. Validated with TokenBar.Smoke build, a no-network smoke run, and git diff --check. Co-Authored-By: Claude <noreply@anthropic.com>
Antigravity 2.3.1's Windows language_server embeds valid Google client IDs immediately after an alphanumeric prefix. Scan numeric-run starts within the existing token span and retain the first candidate accepted by the unchanged client-ID validator, preserving suffix iteration, deduplication, secret scanning, and pairing behavior. Focused synthetic scanner tests pass, including attached-prefix and ordered duplicate cases; git diff --check passes. Real installed-artifact verification remains a separate Windows gate. Co-Authored-By: Claude <noreply@anthropic.com>
Parse the live Grok unified-billing onDemandUsed and onDemandCap objects as defensive raw JSON without weakening the existing GrokBuild productUsage and creditUsagePercent precedence. Valid finite nonnegative pairs now append an Extra usage card with the stable extra_usage.v1 identity, the billing-period end as display reset evidence, and typed nonRecurring pace state so the financial cap never enters recurring pace history. A zero cap is treated as recognized but disabled; malformed, missing, negative, non-finite, overflowed, or underflowed values fail closed without breaking a valid legacy subscription card. prepaidBalance, topUpMethod, and isUnifiedBillingUser remain non-quota metadata. Expose only a narrow UsageWindow::with_non_recurring crate API rather than allowing provider modules to set arbitrary unavailable reasons. Add focused coverage for legacy/new coexistence, source precedence, ratio boundaries, over-cap clamping, exact zero spellings, signed underflow, malformed evidence isolation, and prepaid-balance exclusion. Verified with cargo test -p tb_core_ffi --release agent_grok::tests (24 passed) and git diff --check. Co-Authored-By: Claude <noreply@anthropic.com>
Update the Phase 9 and provider-runtime matrix with the 2026-07-20 Windows evidence: Codex, Claude, Copilot, and Antigravity returned live cards from their expected sources; Grok accepted the unified-billing response as a successful recognized-disabled result; and the installed Antigravity 2.3.1 OAuth client artifact paired without exposing embedded values. Keep the unavailable Antigravity remote OAuth path explicit because this Windows profile has no Gemini OAuth credential, distinguish live checks from hermetic coverage, and record that all seven monitored credential/account-scope paths retained identical exists/hash state across the exact-head polls. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6be0844472
ℹ️ 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".
Parse Grok unified-billing config.used and config.monthlyLimit objects as a recurring included-credit percentage before a disabled on-demand cap can produce an empty successful snapshot. The existing GrokBuild productUsage and creditUsagePercent order remains authoritative; explicit invalid legacy evidence does not fall through to the unified fields. Represent included evidence as absent, invalid, or valid. Valid finite nonnegative usage with a positive monthly limit is clamped to 100% and routed through the existing period/reset semantics, defaulting to the stable billing.monthly.v1 card when the provider supplies no recognized period type. Invalid included evidence cannot be hidden by cap=0, while a separately valid positive Extra usage window remains available and valid legacy evidence ignores malformed new fields. Add focused precedence, period, boundary, overflow, underflow, partial-shape, disabled-cap, and independent-window regressions. Verified with cargo test -p tb_core_ffi --release agent_grok::tests (31 passed) and git diff --check. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e4b4dfcafd
ℹ️ 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".
Accept Grok unified billing amounts as either strict bare JSON numbers or objects containing a strict numeric val field. Both representations share the same finite-number, exact-zero, overflow, and signed-underflow validation; numeric strings and unrelated JSON shapes remain rejected. Keep matching GrokBuild percentages authoritative, including zero. Treat only an exact raw zero from creditUsagePercent as lower-confidence when valid unified included amounts are present, allowing used/monthlyLimit to provide the recurring percentage and stable monthly identity. Nonzero credit percentages still win, explicit invalid legacy evidence remains fail-closed, and absent or malformed included data cannot poison a valid legacy zero. Nonzero decimal percentages that underflow in f64 are not mistaken for default zero. Add focused coverage for bare and wrapped included/on-demand values, numeric-string rejection, exact-zero credit fallback, malformed included preservation, GrokBuild-zero precedence, and nonzero underflow. Verified with cargo test -p tb_core_ffi --release agent_grok::tests (37 passed) and git diff --check. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 47d40230f0
ℹ️ 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".
Separate malformed legacy percentage state from unified included evidence in map_billing. Explicit invalid GrokBuild usagePercent or creditUsagePercent now returns the existing response-shape error without being masked by a disabled on-demand cap. Classify strict exact-zero used/monthlyLimit pairs as disabled so they emit no included card. Preserve GrokBuild and nonzero legacy precedence, keep exact-zero credit fallback to valid positive-cap included ratios, and leave positive usage against a zero limit invalid. Use nested currentPeriod timestamps only for recognized weekly or monthly kinds. Synthesized monthly included cards ignore unrecognized nested periods and rely solely on billingPeriodStart/billingPeriodEnd, while malformed fields on recognized periods remain fail-closed. Add focused regressions for malformed legacy evidence with disabled on-demand, fully disabled zero-window billing, and DAILY nested-period isolation. Verified 40 focused Grok tests, the full 285-test tb_core_ffi release suite, and git diff --check. Co-Authored-By: Claude <noreply@anthropic.com>
Scan every matching GrokBuild productUsage entry before accepting the first valid percentage. Any explicitly malformed matching usagePercent now makes legacy evidence invalid regardless of entry order, so a later malformed duplicate cannot bypass the fail-closed path or be hidden by disabled on-demand billing. Preserve the existing first-valid GrokBuild value when all matching entries are valid, and continue to ignore non-GrokBuild products or matching rows without usagePercent. Add an order-independent regression covering valid-then-malformed and malformed-then-valid duplicate rows with a disabled on-demand cap. The focused Grok release suite passes 41 tests and git diff --check passes. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 88bb72d29c
ℹ️ 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".
Parse onDemandCap before onDemandUsed in extra_usage_window so a strict finite exact-zero cap is recognized as disabled even when usage is missing or null. The cap remains the source of truth for whether pay-as-you-go is enabled. Positive caps still require a strict finite nonnegative usage amount before creating extra_usage.v1. Negative, malformed, non-finite, and syntactically nonzero underflowed cap evidence remains unrecognized and fail-closed through the shared raw amount parser. Add regressions for missing usage, null usage, and the fully disabled included 0/0/default-zero response shape. Existing coverage continues to enforce positive-cap usage requirements, accepted exact-zero spellings, legacy precedence, and disabled billing semantics. Verified with 42 focused Grok release tests, the full 287-test tb_core_ffi release suite, and git diff --check. Co-Authored-By: Claude <noreply@anthropic.com>
Summary
{ "val": number }for unified Grok amounts, distinguish disabled quota pairs from malformed evidence, recognize a zero on-demand cap without requiring usage, and isolate synthesized monthly cards from unrecognized nested period evidence.Data flow and runtime behavior
Antigravity now resolves Windows candidates from
%LOCALAPPDATA%/Programs/antigravity/resources/bin/language_server.exe, with the equivalent platform-home fallback whenLOCALAPPDATAis unavailable. The scanner searches within the binary token span for a grammar-valid numeric Google client-ID start, then uses the existing client-ID/secret pairing policy. Embedded client values are neither logged nor persisted.Grok keeps the legacy subscription order: matching
GrokBuild.productUsage.usagePercentevidence wins, including zero, and a valid nonzerocreditUsagePercentremains the fallback when no matching product percentage is supplied. Every matching GrokBuild row is scanned before accepting the first valid value; any explicitly malformed matching row fails closed regardless of duplicate order. Explicit-invalid legacy evidence is tracked independently and cannot be masked by disabled on-demand billing.An exact raw zero
creditUsagePercentis treated as lower-confidence only when a validused / monthlyLimitpair exists. A strict exact-zerousedplus exact-zeromonthlyLimitpair is explicitly disabled and creates no included card; positive usage against a zero limit remains invalid. With an independently recognized zero on-demand cap, a fully disabled unified account succeeds with zero windows. Absent or malformed unified evidence otherwise preserves a valid legacy zero, while matching GrokBuild zero and valid nonzero legacy credit retain precedence.Unified amounts share one strict parser that accepts a bare JSON number or
{ "val": number }. Numeric strings, booleans, nulls, arrays, missingval, negative values, overflow/non-finite values, and syntactically nonzero values that underflow to signed zero fail closed. When legacy evidence is absent,used / monthlyLimitbecomes the recurring included-quota percentage and defaults to the stablebilling.monthly.v1card when the provider supplies no recognized period type.Nested
currentPeriod.start/endevidence is used only whencurrentPeriod.typemaps to the existing weekly or monthly kinds. A synthesized monthly included card ignores unrecognized nested periods and uses onlybillingPeriodStart/billingPeriodEnd, preventing a daily or future period type from entering monthly pace/history. Present malformed fields on a recognized period still cannot be hidden by billing-level fallback.A finite nonnegative on-demand pair with a positive cap produces
extra_usage.v1, clamps over-cap use to 100%, uses the billing-period end only as display reset evidence, and marks pace asnonRecurringso the card never enters recurring history. Zero cap is recognized as disabled before reading on-demand usage, so missing or nullonDemandUseddoes not invalidate an exact-zero cap. Positive caps still require strict valid nonnegative usage; malformed included evidence cannot be hidden by a disabled cap, while independently valid positive Extra usage remains available.prepaidBalance,topUpMethod, andisUnifiedBillingUserare not treated as quota.Windows live validation
Exact head
6f99d3c6543b2889505521f111d19b0d399e74a3passed the x64BuildTbNativepath, managed Smoke build, and credential-bound live poll:oauth:2winoauth:2wincli:8winoauth:2winoauth:0win(successful recognized-disabled unified-billing result, notresponse_shape)The installed Antigravity 2.3.1
language_server.exepassed a Windows-only temporary discovery assertion against the committed scanner. The final live poll retained identical exists/hash state for all seven monitored credential and account-scope paths. Antigravity remote OAuth success is intentionally not claimed because this Windows profile has no~/.gemini/oauth_creds.json; the remote flow remains covered hermetically.Verification
Latest exact head:
cargo test -p tb_core_ffi --release agent_grok::tests— 42 passedcargo test -p tb_core_ffi --release— 287 passedscripts/check.sh— Rust workspace checks/tests, native build, 275 .NET tests, and Smoke passedBuildTbNative+ managed Smoke + credential-bound live poll — passedgit diff --check— passedCONFIRMEDThe local macOS host does not have the Windows ARM64 Rust target and Windows SDK/
clang-cl; the latest-headarm64-crossGitHub job remains the required ARM64 build/package gate for this PR.🤖 Generated with Claude Code