Codex review: found issues before merge. Reviewed June 28, 2026, 1:49 PM ET / 17:49 UTC.

Summary
Adds a disabled-by-default LongCat usage provider with cookie/manual auth settings, browser-cookie import, quota/fuel-pack parsing, provider wiring, docs, icon resources, and focused tests.

Reproducibility: not applicable. as a bug reproduction: this PR adds a new provider. The contributor did provide redacted live output showing the provider path rendering quota data.

Review metrics: 2 noteworthy metrics.

• Changed surface: 25 files, +1149/-4. The PR wires a new provider through app, core, widget, docs, resources, and tests, so integration review matters.
• Auth boundary: 1 full-cookie web provider added. The provider intentionally forwards the full longcat.chat cookie header, which is a maintainer security/product decision.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

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

Rank-up moves:

• Switch LongCat fetches to an ephemeral redirect-guarded cookie-free transport like Sakana.
• Get explicit maintainer acceptance or rejection of the full longcat.chat cookie boundary.

Mantis proof suggestion
A redacted live app proof of the menu/Overview rendering would still help maintainers evaluate the visible provider behavior, even though the remaining blocker is policy and transport hardening. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis visual task: verify CodexBar renders LongCat quota and fuel-pack values from a real longcat.chat session with private cookies/account details redacted.

Risk before merge

• [P1] Merging accepts a new auth-provider boundary that forwards the full longcat.chat cookie jar to undocumented web-console endpoints.
• [P1] The current fetcher uses the shared provider HTTP client instead of an isolated cookie-free transport, so it does not yet match the hardened Sakana cookie-provider pattern.
• [P1] The undocumented response shapes create a support burden if LongCat changes the console endpoints, even though the provider is disabled by default and covered by focused parser tests.

Maintainer options:

1. Accept the LongCat cookie boundary
   A maintainer can explicitly approve the disabled-by-default full-cookie web-console provider after the transport isolation fix lands.
2. Require Sakana-style isolation first (recommended)
   Update LongCat to use an ephemeral redirect-guarded session with cookie storage disabled before any merge decision.
3. Defer until a narrower credential exists
   If full-cookie forwarding is not acceptable for core, pause or close this PR until LongCat documents a usage endpoint or narrower auth token.

Next step before merge

• [P2] The remaining blocker combines a narrow security hardening fix with an explicit maintainer policy decision about full-cookie forwarding, so this should stay in maintainer review rather than an autonomous repair lane.

Security
Needs attention: The diff introduces a new full-cookie web-console auth path and should isolate its transport before merge.

Review findings

• [P2] Use an isolated cookie-free transport for LongCat fetches — Sources/CodexBarCore/Providers/LongCat/LongCatUsageFetcher.swift:118

Thanks for the review — both P2s are addressed in 35076321:

1. Invalid-session surfacing — user-current now propagates envelope auth failures (try instead of try?); .invalidSession is non-fallback, so expired cookies prompt re-auth instead of an empty snapshot.
2. Unused today-token path — removed the never-assigned todayTokens/freeQuota fields and the unreachable tertiary window. LongCat's tokenUsage is a quota snapshot with no per-day figure.

On the cookie import using only the first session: that's intentional parity with the existing Kimi/MiniMax cookie providers (single-account balance read); happy to generalize if you'd prefer.

Behavior proof

The field mapping is not guessed — it's locked against live responses captured from a logged-in longcat.chat console session (the public api.longcat.chat key exposes no usage endpoint, hence the cookie path). Captured shapes (values neutralised):

GET /api/lc-platform/v1/tokenUsage →

{ "code": 0, "message": "SUCCESS",
  "data": { "usage": { "totalToken": 500000, "usedToken": 0, "availableToken": 500000 },
            "extData": { "LongCat-Flash-Lite": { "totalToken": 50000000, "usedToken": 0 } } } }

GET /api/lc-platform/v1/pending-fuel-packages → { "code": 0, "data": { "totalQuota": 0, "list": [] } }
GET /api/v1/user-current → data.name (the body also carries a session token + phone, so it is never logged).

LongCatProviderTests asserts buildSnapshot against these exact shapes (quota %, fuel-pack sum + expiry, envelope invalid-session). Full swift test is green.

@codex review

Re-review follow-up — both findings handled in 4110e2ae / the rebase:

• Env cookie routing (P2): LongCatCookieHeader now resolves the env value via LongCatSettingsReader.cookieHeader(environment:), so the lower-case longcat_manual_cookie alias + quote-trimming apply on the env path. +regression test.
• Changelog daily-token wording (P3): dropped during the rebase onto main (entry now reads "console token quota (总额度) and fuel-pack balance (加油包)").

Branch is rebased onto latest main, swift build + swift test green locally.

@codex review

Both cookie-source findings fixed in 670a9d25:

• Off now fully disables web auth (env override gated in resolveCookieOverride).
• Manual no longer silently browser-imports — browser/keychain fallback is Auto-only.

+2 regression tests. swift build + swift test green locally.

@codex review

All Codex review threads have been addressed and resolved. PR body now documents the latest cookie-source guardrails, Chrome-only LongCat auto import default, missing-quota behavior, validation, and the maintainer auth/privacy decision point.

@codex review
@clawsweeper re-review

🦞🧹
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.

Codex Review: Didn't find any major issues. You're on a roll.

Reviewed commit: 5197371d69

@openclaw-mantis visual task: verify CodexBar renders LongCat quota and fuel-pack values from a real longcat.chat session with private cookies/account details redacted.

Redacted live behavior proof

Ran a local live proof against the current PR head (5197371d694e8283de0ee0120ab80c9dfceb19ac) using the LongCat provider path with:

• runtime: app
• interaction: userInitiated
• cookie source: auto
• import policy: macOS Chrome-only browser cookie import

No cookie values, auth tokens, account names, phone numbers, IPs, raw response bodies, or endpoint URLs are included below.

{
  "commit": "5197371d694e8283de0ee0120ab80c9dfceb19ac",
  "provider": "longcat",
  "runtime": "app",
  "interaction": "userInitiated",
  "cookieSource": "auto",
  "importPolicy": "macOS Chrome-only browser cookie import",
  "strategyAvailable": true,
  "fetchSource": "web",
  "identityPresent": true,
  "primaryRendered": true,
  "primaryUsedPercent": 0,
  "primaryDescription": "0/500000",
  "fuelPackEndpointObserved": true,
  "fuelPackEndpointTotalQuota": 0,
  "fuelPackEndpointPackageCount": 0,
  "fuelPackRendered": false,
  "timestamp": "2026-06-24T06:22:54Z"
}

Notes:

• Quota rendering is visible through the primary usage window (0/500000, 0%).
• The fuel-pack endpoint was reached successfully and returned total quota 0 with 0 active packages for this account, so no secondary fuel-pack window is rendered; that matches the current UsageSnapshot behavior.
• The proof was generated with a temporary local test harness and then removed from the worktree; no proof-only code is part of this PR.

Maintainer sign-off still requested: this PR intentionally forwards the full longcat.chat cookie jar because the LongCat/Meituan auth cookie name is undocumented. Please confirm whether that boundary is acceptable while the provider remains disabled by default and Auto import is Chrome-only/user-initiated.

@clawsweeper re-review

Maintainer sign-off requested for the final ClawSweeper gate.

The remaining decision is whether CodexBar core accepts forwarding the full longcat.chat cookie jar for this disabled-by-default provider, given that LongCat/Meituan does not document a narrower usage credential. Current mitigations are:

• provider disabled by default
• Auto import is app-runtime + user-initiated only
• Auto import defaults to Chrome-only on macOS
• Manual/Off do not silently browser-import
• user-current bodies are never logged
• redacted live proof is now posted and ClawSweeper marked proof: sufficient

@steipete could you explicitly confirm whether this full-cookie boundary is acceptable for merge?

Rebased onto latest main and resolved the conflicts introduced by the Sakana provider landing in #1774 across the shared provider-registration surfaces (Providers, ProviderDescriptor, UsageStore, CostUsageScanner, widgets, and docs/configuration.md). Both providers now coexist; the documented ID list is regenerated in enum order and CodexParserHash is regenerated.

I also folded in the same hardening pattern #1774 applied to Sakana: a blocked 3xx response (e.g. an expired-cookie login redirect that the shared transport's redirect guard drops) is now classified as .invalidSession instead of a generic HTTP <code> error, so users see "sign in again" rather than "HTTP 302". The existing envelope surfaces invalid session on auth code test already covers LongCat's primary expired-session path (the Meituan envelope returns HTTP 200 with an inner code: 401); the 3xx guard is defense-in-depth.

swift build is clean and the affected suites pass locally — LongCatProviderTests, ConfigurationDocsProviderIDTests, ProviderIconResourcesTests, and CostUsage* (239 tests). The only failures in the full local run were the known wall-clock-timing flaky suites (CodexLoginRunner, Antigravity*Deadline, DeepSeek/CommandCode grace, SubprocessRunner) that slip under local CPU load; CI is the authoritative signal there.

Now that #1774 established that core accepts cookie-source providers, this should be ready for the final maintainer look. Happy to adjust anything to match the Sakana hardening bar.