fix: allow MiniMax usage on Linux with a configured API key - #2475
Conversation
![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: 07a76c8b9a
ℹ️ 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".
| } | ||
| if provider == .minimax, | ||
| sourceMode == .auto, | ||
| environment.map({ MiniMaxAPISettingsReader.apiToken(environment: $0) != nil }) == true |
There was a problem hiding this comment.
When MINIMAX_API_KEY contains a standard sk-api-... key, this condition now bypasses the non-macOS web-support gate, but MiniMax auto resolution does not actually run the API strategy for standard keys: MiniMaxProviderDescriptor.resolveStrategies returns only MiniMaxCodingPlanFetchStrategy for .standard, and MiniMaxAPIFetchStrategy.isAvailable also rejects .standard. On Linux that web strategy is unavailable without cookies, so users with the documented MINIMAX_API_KEY path fall through to No available fetch strategy instead of using HTTPS or being correctly gated; only coding-plan/unknown keys can safely skip this check.
Useful? React with 👍 / 👎.
|
@clawsweeper re-review |
|
🦞👀 Command router queued. I will update this comment with the next step. |
|
🦞👀 Command router queued. I will update this comment with the next step. |
The MiniMax descriptor advertises [.auto, .web, .api], so the CLI's web-support gate rejected the provider under Auto on non-macOS hosts even when an API key was configured. The MiniMax API fetch is plain HTTPS with Bearer auth, so only its web/cookie path needs macOS. Exempt Auto from the gate when an API key resolves, matching the existing Factory and Kimi credential exemptions. Explicit --source web and the no-credential case still require web support. Closes steipete#2474
07a76c8 to
7191cac
Compare
clawsweeper
Bot
added
rating: 🦪 silver shellfish
|
Codex review: needs real behavior proof before merge. Reviewed July 29, 2026, 10:43 AM ET / 14:43 UTC. ClawSweeper reviewWhat this changesThis PR refactors CodexBar’s non-macOS web-support gate, permits MiniMax Auto mode to bypass that gate only for key kinds that resolve to its HTTPS API strategy, and adds Linux regression tests. Merge readiness⛔ Blocked until real behavior proof from a real setup is added - 4 items remain Keep this PR open: the maintainer corrected the original key-class bug and added a strategy-level regression test, but current Priority: P2 Review scores
Verification
How this fits togetherCodexBar’s CLI reads provider configuration and credentials, then decides whether an Auto source can run without macOS web support before selecting a usage-fetch strategy. This gate determines whether MiniMax proceeds to its API request path or reports that the selected source requires macOS. flowchart LR
Config[Provider config and API key] --> Gate[Non-macOS source gate]
Source[Requested source mode] --> Gate
Gate --> Planner[MiniMax strategy planner]
Planner --> API[HTTPS API usage request]
Planner --> Web[macOS web and cookie path]
API --> Output[CLI usage output]
Web --> Output
Before merge
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Land the narrow corrected exemption only after a redacted Linux CLI transcript demonstrates a coding-plan key reaches the MiniMax API path successfully and the required Linux/macOS checks pass; retain the gate for standard keys, explicit web mode, and missing credentials. Do we have a high-confidence way to reproduce the issue? Yes, from source: current main’s Auto gate sees MiniMax’s web-capable descriptor and blocks Linux before strategy selection; the PR’s focused Linux tests encode the corrected key-kind cases. A live credentialed CodexBar run has not yet been supplied. Is this the best way to solve the issue? Yes, with the maintainer’s correction: exempting only credentials that resolve to the Linux-capable API strategy is narrower and safer than bypassing the gate for every MiniMax API key. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against b7553b104158. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (2 earlier review cycles) |
|
Maintainer review — thanks @OfficialAbhinavSingh, this needed a correction before it could land, and I've pushed it rather than bouncing it back to you. The defect: the exemption was applied to any configured MiniMax key, but What I changed ( I also pushed Driving CI now; will land once green. |
|
Thanks for pushing the correction rather than bouncing it back — it's the right fix. I did read The complexity refactor makes sense too — that function was already close to the limit before I added another branch. |
|
Merged after full verification. MiniMax now works on Linux when a usable API credential is configured — scoped, after review, to keys that actually resolve a Linux-capable strategy: standard Includes a maintainer refactor grouping the CLI web-support exemptions into |
2 participants
Closes #2474.
Problem
On Linux,
minimaxfails even with an API key configured:MiniMaxProviderDescriptoradvertisessourceModes: [.auto, .web, .api], so under Auto the CLI'ssourceModeRequiresWebSupportgate returnstruepurely because.webis in the list — the APIstrategy never gets a chance to run. But
minimax.apiiskind: .apiToken, a plain HTTPS requestwith
Authorization: Bearer …: no WebKit, no cookie import, no JS.Fix
Exempt Auto from the gate when a MiniMax API key actually resolves, mirroring the existing
credential exemptions in the same function (
.factoryreadsFactorySettingsReader.apiKey,.kimireadsProviderTokenResolver.kimiAPIToken):MiniMaxAPISettingsReader.apiTokencovers bothMINIMAX_API_KEYandMINIMAX_CODING_API_KEY, andProviderConfigEnvironment.directAPIKeyEnvironmentKeymaps.minimaxto that same key — so keysstored via
config set-api-keyare seen here too, not just environment variables.Scope is deliberately narrow: explicit
--source weband the no-credential case still require websupport, so nothing that genuinely needs macOS is bypassed.
Scope note
The issue also reports
--source apifailing. I could not reproduce that from source: the gate'sfinal switch already returns
falseforcase .cli, .oauth, .api, so the explicit-API path shouldnot hit it. This PR therefore fixes only the Auto path, which is reproducible and covered below.
Validation
Built and tested on Linux in
swift:6.3.3; macOS CI validates the rest.Green — with the fix (4/4):
Red — same tests with the fix reverted (simulating current
main):Note the two negative controls pass in both states — they confirm the gate still fires for
explicit
.weband for the no-credential case, so the exemption is scoped rather than a blanketbypass.
Lint:
Not tested: a live MiniMax account round-trip — I don't have MiniMax credentials. The issue
reporter already verified the endpoint answers on Linux via
curl, and this change only affectsthe CLI platform gate, not the request itself.
Competing open PR scan: none — no other open PR references #2474 or touches
sourceModeRequiresWebSupport.