Fix Xiaomi MiMo fallback after auth redirect

[Yuxin-Qiao]

Summary

• Treat Xiaomi MiMo API auth redirects as loginRequired instead of a terminal network error.
• Preserve browser import order while allowing a stale cached/Chrome session to fall through to a later valid imported session.
• Add focused regression coverage for redirects and stale-Chrome-to-Safari fallback.

Root Cause

A stale session can make the MiMo API return a login redirect. Classifying that redirect as a terminal network error prevents the web strategy from clearing stale state and trying later browser sessions. Mapping it to login-required uses the existing bounded retry path.

Proof

• swift test --filter MiMoProviderTests: 35 tests passed on the exact head.
• make check: format and strict lint clean on the exact head.
• Exact-head Codex autoreview clean, confidence 0.82.
• Exact CLI browser-cookie routing reached the real Chrome Safe Storage Keychain prompt; the read stopped there because unattended login-keychain entry was unavailable. No live account-success claim is made.

Exact candidate: 215584c29306bb016f35662a235fe48cf703ca7f.

Fixes #1548.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed June 19, 2026, 4:43 AM ET / 08:43 UTC.

Summary
This PR maps Xiaomi MiMo API 3xx redirects to loginRequired, adds redirect and stale-Chrome-to-Safari regression tests, and adds a changelog entry.

Reproducibility: yes. at source level: current main maps direct MiMo 3xx API responses to networkError, and the MiMo web strategy does not retry sessions for networkError. I did not run live cookie validation because AGENTS.md warns that browser-cookie and Keychain-backed validation can prompt macOS permissions.

Review metrics: 1 noteworthy metric.

• Diff scope: 3 files changed, +90/-0. The code change is narrow, so proof of the live auth fallback is the main remaining merge input.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #1548
Summary: This PR is an implementation candidate for the Xiaomi MiMo stale Chrome with valid Safari fallback described in the linked issue comments; the Firefox session-restore PR is adjacent but distinct.

Members:

• canonical: Currently, the tool only supports reading Chrome cookies. I would appreciate it if support could be added for other browsers, like Safari and ChatGPT Atlas. #1548 - The issue comment provides the stale Chrome/logout plus Safari-still-logged-in reproduction that this PR targets.
• adjacent_distinct: Fix MiMo Firefox session cookie import #1565 - That open PR also touches MiMo browser-cookie import, but it addresses Firefox session cookie recovery rather than stale Chrome redirect fallback.

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

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦞 diamond lobster
Result: blocked until real behavior proof is added.

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

Rank-up moves:

• [P1] Add redacted terminal output, logs, a recording, or a linked artifact showing stale Chrome redirecting and a valid Safari MiMo session succeeding.
• Update the PR body after adding proof; if a fresh review does not run automatically, ask a maintainer to comment @clawsweeper re-review.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR body lists tests and a stopped Keychain-prompt attempt, but no redacted terminal output, logs, recording, or linked artifact showing after-fix stale-Chrome to valid-Safari success; update the PR body after adding proof so ClawSweeper can re-review.

Risk before merge

• [P2] Real after-fix MiMo proof is absent; the PR body lists tests and a Keychain-prompt stop, but not a successful stale-Chrome to valid-Safari fallback in a real setup.
• [P2] The auth-provider behavior change treats all MiMo API 3xx responses as loginRequired, so maintainers should see live or redacted diagnostic proof before accepting the fallback behavior.

Maintainer options:

1. Require live MiMo fallback proof (recommended)
   Wait for redacted terminal output, logs, a recording, or a linked artifact showing stale Chrome redirecting and Safari succeeding before merge.
2. Accept source-only auth validation
   Maintainers may choose to merge based on focused stubs and own the remaining live-account fallback uncertainty.
3. Pause until safe account proof exists
   If no one can provide safe redacted MiMo proof, keep the PR paused until a maintainer can validate the account path directly.

Next step before merge

• [P2] Contributor or maintainer proof is needed for the real MiMo browser-cookie fallback; there is no concrete code repair for ClawSweeper to automate.

Security
Cleared: No concrete security or supply-chain concern was found; the diff only changes MiMo HTTP status classification, focused tests, and a changelog note.

Review details

Best possible solution:

Merge the narrow redirect-classification fix after required checks pass and redacted real behavior proof shows stale Chrome redirects falling through to a valid Safari MiMo session.

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

Yes at source level: current main maps direct MiMo 3xx API responses to networkError, and the MiMo web strategy does not retry sessions for networkError. I did not run live cookie validation because AGENTS.md warns that browser-cookie and Keychain-backed validation can prompt macOS permissions.

Is this the best way to solve the issue?

Yes, the code path is the narrow maintainable fix: it reuses the existing stale-session retry path by classifying MiMo API redirects as loginRequired. Merge readiness is still blocked by missing real behavior proof, not by a definite code defect.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

• P2: The PR addresses a bounded Xiaomi MiMo auth fallback bug with limited provider-specific blast radius.
• merge-risk: 🚨 auth-provider: The patch changes MiMo cookie-session handling after API redirects, and live account fallback behavior is not yet proven.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦞 diamond lobster.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body lists tests and a stopped Keychain-prompt attempt, but no redacted terminal output, logs, recording, or linked artifact showing after-fix stale-Chrome to valid-Safari success; update the PR body after adding proof so ClawSweeper can re-review.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its guidance to avoid live browser-cookie or Keychain-backed validation without explicit request affected this review. (AGENTS.md:25, 99cd674ba08e)
• Current main classifies 3xx as network errors: Current main only maps 401 to loginRequired and 403 to invalidCredentials; other non-200 statuses, including 3xx redirects, fall through to networkError. (Sources/CodexBarCore/Providers/MiMo/MiMoUsageFetcher.swift:168, 99cd674ba08e)
• Current main retry gate skips network errors: MiMo retries the next session for login/auth/parse failures, but explicitly does not retry networkError. (Sources/CodexBarCore/Providers/MiMo/MiMoProviderDescriptor.swift:155, 99cd674ba08e)
• PR implementation uses existing login retry path: The PR adds a 300..<400 case that throws MiMoUsageError.loginRequired, routing redirects through the existing retry behavior. (Sources/CodexBarCore/Providers/MiMo/MiMoUsageFetcher.swift:171, 91bedbe51691)
• PR adds focused regression coverage: The branch adds tests for direct 302 classification and stale Chrome redirect fallback to a valid Safari session using stubs and the test keychain store. (Tests/CodexBarTests/MiMoProviderTests.swift:565, 91bedbe51691)
• Proof remains missing: The PR body lists unit tests and a stopped Keychain-prompt attempt, but no after-fix real MiMo stale-Chrome to valid-Safari success output or artifact. (215584c29306)

Likely related people:

• steipete: Current-main blame for the affected MiMo fetcher and retry-gate lines points to the v0.36.1 snapshot, and recent provider-cookie hardening also touched this area. (role: recent area contributor and merger; confidence: high; commits: 06fea2c897cc, 501cb51c210d; files: Sources/CodexBarCore/Providers/MiMo/MiMoUsageFetcher.swift, Sources/CodexBarCore/Providers/MiMo/MiMoProviderDescriptor.swift)
• Yuxin-Qiao: Auth fallback here builds on the merged MiMo multi-browser import work from the same provider area, not only on this PR branch. (role: prior merged browser-cookie contributor; confidence: high; commits: 050b13925da4; files: Sources/CodexBarCore/Providers/MiMo/MiMoCookieImporter.swift, Sources/CodexBarCore/Providers/MiMo/MiMoProviderDescriptor.swift, Sources/CodexBarCore/Providers/MiMo/MiMoUsageFetcher.swift)
• debpramanik: The original Xiaomi MiMo provider commit added the fetcher, descriptor, cookie importer, and test coverage that this PR modifies. (role: introduced MiMo provider behavior; confidence: high; commits: f9a2918afcf1; files: Sources/CodexBarCore/Providers/MiMo/MiMoUsageFetcher.swift, Sources/CodexBarCore/Providers/MiMo/MiMoProviderDescriptor.swift, Tests/CodexBarTests/MiMoProviderTests.swift)

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.

[steipete]

Maintainer proof override: accepting deterministic redirect/fallback coverage plus the focused MiMo suite for this change. Repository policy forbids unsolicited live credential and Keychain probes; the patch changes fallback classification, not credential storage.

Current proof: 35 focused tests green, make check green, full-branch autoreview clean (0.86). Exact-head CI is 7/8 green; macOS shard 1 remains queued.