Summary
The MiniMax OAuth device-code endpoint returns a verification_uri of the form:
https://www.minimax.io/oauth-authorize?user_code=XXXX&client=OpenClaw
But that page no longer exists -- www.minimax.io/oauth-authorize 307-redirects to the marketing homepage /, which has no OAuth UI. The live OAuth approval page is at platform.minimax.io/oauth-authorize?....
Result: a user who follows the URL Hermes prints lands on the MiniMax marketing site and has no way to approve the device code. The flow then times out.
This appears to be a server-side regression on MiniMax's end -- they renamed/moved the approval host but didn't update the verification_uri returned by the OAuth API.
Repro
curl -i 'https://www.minimax.io/oauth-authorize?user_code=TEST&client=OpenClaw'
# -> HTTP/2 307, location: /
curl -s -o /dev/null -w "%{http_code}\n" 'https://platform.minimax.io/oauth-authorize?user_code=TEST&client=OpenClaw'
# -> 200
End-to-end: run hermes model -> "MiniMax via OAuth browser login" (with #19335 applied so the device-code request itself succeeds). Hermes prints Open: https://www.minimax.io/oauth-authorize?...; the user clicks it, gets redirected to the homepage, and the flow times out.
Possible mitigations
Two options, in increasing order of upstream involvement:
- Defensive client-side rewrite in Hermes. When
verification_uri host is www.minimax.io and path starts with /oauth-authorize, rewrite the host to platform.minimax.io before printing/opening it. Cheap, unblocks users today. Downside: papers over a server bug and would need to be revisited if MiniMax fixes their side or moves it again.
- Escalate to MiniMax to fix the OAuth server so it returns the correct
verification_uri host. Cleanest fix, but on their timeline.
Filing this so maintainers can decide which path (or both) to take. Happy to send a small PR for option 1 if you want it as a temporary workaround.
Environment
- Hermes installed via the official curl installer
- macOS (Darwin 25.4.0)
- Python 3.11
- Real MiniMax Plus account (global region)
Filed separately from #19335 because that PR fixes a clear Hermes-side bug (httpx redirect following), whereas this one is server-side and the right course of action is unclear.
Summary
The MiniMax OAuth device-code endpoint returns a
verification_uriof the form:But that page no longer exists --
www.minimax.io/oauth-authorize307-redirects to the marketing homepage/, which has no OAuth UI. The live OAuth approval page is atplatform.minimax.io/oauth-authorize?....Result: a user who follows the URL Hermes prints lands on the MiniMax marketing site and has no way to approve the device code. The flow then times out.
This appears to be a server-side regression on MiniMax's end -- they renamed/moved the approval host but didn't update the
verification_urireturned by the OAuth API.Repro
End-to-end: run
hermes model-> "MiniMax via OAuth browser login" (with #19335 applied so the device-code request itself succeeds). Hermes printsOpen: https://www.minimax.io/oauth-authorize?...; the user clicks it, gets redirected to the homepage, and the flow times out.Possible mitigations
Two options, in increasing order of upstream involvement:
verification_urihost iswww.minimax.ioand path starts with/oauth-authorize, rewrite the host toplatform.minimax.iobefore printing/opening it. Cheap, unblocks users today. Downside: papers over a server bug and would need to be revisited if MiniMax fixes their side or moves it again.verification_urihost. Cleanest fix, but on their timeline.Filing this so maintainers can decide which path (or both) to take. Happy to send a small PR for option 1 if you want it as a temporary workaround.
Environment
Filed separately from #19335 because that PR fixes a clear Hermes-side bug (httpx redirect following), whereas this one is server-side and the right course of action is unclear.