fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp by NianJiuZst · Pull Request #83480 · openclaw/openclaw

NianJiuZst · 2026-05-18T06:48:24Z

Summary

Converts MiniMax OAuth token expired_in from relative seconds to an absolute millisecond timestamp, fixing hasUsableOAuthCredential() always treating the token as expired.

This PR narrows the fix to the MiniMax Portal OAuth expiry path. It does not claim to fix the separate MiniMax API-key path discussed on #83449.

Real behavior proof

Behavior addressed: MiniMax Portal OAuth credentials in OpenClaw should stop looking immediately expired, so requests no longer spend 30-50s repeatedly stuck in auth before reaching the MiniMax provider.

Real environment tested: Local OpenClaw CLI from this branch on macOS, using the existing minimax-portal OAuth profile from ~/.openclaw/agents/main/agent/auth-profiles.json.

Exact steps or command run after this patch:

pnpm openclaw models status
TIMEFMT='real %E'; time pnpm openclaw infer model run --local --model minimax-portal/MiniMax-M2.7 --prompt 'Reply with OK only.' --json
Re-ran step 2 once more without changing auth state.

Evidence after fix:
Terminal capture after this patch:

Auth overview
- minimax-portal effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | minimax-portal:default=OAuth

OAuth/token status
- minimax-portal usage: 5h 0% left
  - minimax-portal:default ok expires in 364d

Error: No text output returned for provider "minimax-portal" model "MiniMax-M2.7": 400 {"type":"error","error":{"type":"invalid_request_error","message":"invalid params, model[MiniMax-M2.7] does not support max tokens > 196608 (2013)"},"request_id":"[redacted]"}.
real 5.78s

Error: No text output returned for provider "minimax-portal" model "MiniMax-M2.7": 400 {"type":"error","error":{"type":"invalid_request_error","message":"invalid params, model[MiniMax-M2.7] does not support max tokens > 196608 (2013)"},"request_id":"[redacted]"}.
real 6.18s

Observed result after fix: The stored MiniMax Portal OAuth credential was recognized as valid (ok expires in 364d), and two consecutive real local minimax-portal requests reached the provider and returned the same provider-side 400 in about 6 seconds instead of reproducing the original 30-50s auth-stage stall.

What was not tested: Successful MiniMax text generation beyond this provider-side 400 response, the separate MiniMax API-key path, and the installed 2026.5.12 gateway binary outside this local branch run.

Root Cause

MiniMax returns expired_in from the token endpoint as a relative duration in seconds (standard OAuth expires_in semantics), but the auth profile store's hasUsableOAuthCredential() expects an absolute millisecond timestamp:

// credential-state.ts: remainingMs = expires - Date.now()
// 86400 - 1716000000000 < 0 → always "expired"

Without conversion the token appears perpetually expired, triggering a slow OAuth refresh network call to api.minimaxi.com on every request. Combined with CN network latency this causes the reported 30-50s auth-stage delay.

Changes

extensions/minimax/oauth.ts: Added normalizeOAuthExpires() that handles three possible expired_in formats:

Relative duration in seconds (< 1B): Date.now() + expiredIn * 1000
Absolute Unix timestamp in seconds (1B–1T): expiredIn * 1000
Absolute millisecond timestamp (>= 1T): use as-is

extensions/minimax/oauth.test.ts: Added focused regression coverage for relative seconds, Unix seconds, and millisecond timestamps.

Verification

MiniMax OAuth expiry normalization tests: 3 pass
MiniMax provider extension tests: 9 pass
MiniMax extension tests: 107 pass
Auth controller tests: 7 pass
Auth profile tests: 70 pass
MiniMax contract tests: 7 pass
Build succeeds
Formatting clean

Related #83449.

🤖 Generated with Claude Code

clawsweeper · 2026-05-18T06:49:32Z

Codex review: needs maintainer review before merge.

Latest ClawSweeper review: 2026-05-20 10:10 UTC / May 20, 2026, 6:10 AM ET.

Workflow note: Future ClawSweeper reviews update this same comment in place.

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.

Summary
The PR normalizes MiniMax OAuth expired_in values into absolute millisecond expires timestamps, adds focused expiry-format tests, and updates raw-fetch allowlist line numbers.

Reproducibility: yes. by source inspection: current main stores MiniMax expired_in directly as expires, while shared auth subtracts Date.now() from that field. I did not run a live MiniMax OAuth reproduction in this read-only review, but the PR body supplies after-fix terminal proof.

PR rating
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🐚 platinum hermit
Summary: Focused auth fix with sufficient terminal proof, targeted tests, and no blocking findings; remaining risk is normal auth-provider merge judgment.

Rank-up moves:

When reconciling with feat(minimax): migrate OAuth to account/oauth2 endpoints + add refresh #82056, keep this expiry normalization in any migrated token or refresh path.

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.

Real behavior proof
Sufficient (terminal): The PR body supplies redacted terminal proof from a real local MiniMax Portal OAuth setup showing the credential recognized as valid and requests reaching MiniMax after the patch.

Risk before merge

This changes MiniMax OAuth credential freshness semantics, so maintainers should treat it as an auth-provider behavior change even though the diff is small.
The supplied live proof shows the credential becomes usable and requests reach MiniMax, but it stops at a provider-side 400 rather than successful text generation.
Already-persisted profiles that were saved with a bad relative expires value are not proven to self-repair without refresh or re-login.
The open MiniMax OAuth2/refresh PR touches the same files; if that branch lands first or later, it should preserve this expiry normalization in token and refresh paths.

Maintainer options:

Land the OAuth-only expiry fix (recommended)
Accept the narrow provider-local normalization now, while keeping API-key latency and broader MiniMax OAuth2/refresh work scoped to their own items.
Ask for stored-profile recovery proof first
If maintainers require existing bad MiniMax OAuth profiles to recover without re-login, request a focused refresh or re-login upgrade proof before merge.
Reconcile with the OAuth2 migration PR
Pause this PR only if maintainers plan to land the broader MiniMax OAuth2/refresh branch first and absorb this normalization into both token and refresh paths there.

Next step before merge
No automated repair is needed; maintainers should make the auth-provider merge decision and coordinate this narrow fix with the broader MiniMax OAuth2/refresh branch.

Security
Cleared: The diff only changes MiniMax OAuth expiry normalization, focused tests, and raw-fetch allowlist line numbers; I found no new dependency, workflow, permission, secret-handling, or supply-chain surface.

Review details

Best possible solution:

Land the narrow provider-local expiry normalization if maintainers accept the OAuth-only scope, and make any broader MiniMax OAuth2 or refresh branch reuse the same expiry contract.

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

Yes, by source inspection: current main stores MiniMax expired_in directly as expires, while shared auth subtracts Date.now() from that field. I did not run a live MiniMax OAuth reproduction in this read-only review, but the PR body supplies after-fix terminal proof.

Is this the best way to solve the issue?

Yes, normalizing MiniMax token expiry at the provider boundary is the narrowest maintainable fix for this OAuth path. Any recovery for already-bad stored profiles should be handled as separate refresh or re-login proof, not by broadening core auth semantics.

Label justifications:

P1: The PR addresses a reported MiniMax OAuth regression that can add 30-50 seconds of auth delay on every affected request.
merge-risk: 🚨 auth-provider: The diff changes how MiniMax OAuth expiry is interpreted, which affects credential freshness, refresh decisions, and provider auth routing.
rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🐚 platinum hermit, patch quality is 🐚 platinum hermit, and Focused auth fix with sufficient terminal proof, targeted tests, and no blocking findings; remaining risk is normal auth-provider merge judgment.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The PR body supplies redacted terminal proof from a real local MiniMax Portal OAuth setup showing the credential recognized as valid and requests reaching MiniMax after the patch.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body supplies redacted terminal proof from a real local MiniMax Portal OAuth setup showing the credential recognized as valid and requests reaching MiniMax after the patch.

What I checked:

Current main stores MiniMax token expiry without normalization: pollOAuthToken() currently maps tokenPayload.expired_in directly into the stored expires field, so a relative seconds value is persisted as if it were an absolute timestamp. (extensions/minimax/oauth.ts:175, 167e73cd5f84)
Shared auth contract expects an absolute millisecond timestamp: resolveTokenExpiryState() subtracts Date.now() from expires, and hasUsableOAuthCredential() only accepts the credential when that computed state is valid. (src/agents/auth-profiles/credential-state.ts:31, 167e73cd5f84)
Documentation matches the absolute-expiry contract: The OAuth docs state that profiles store an expires timestamp and runtime uses it to decide whether to use the stored access token or refresh. Public docs: docs/concepts/oauth.md. (docs/concepts/oauth.md:138, 167e73cd5f84)
PR diff applies the normalization at the provider boundary: The PR adds normalizeOAuthExpires() and uses it when converting the MiniMax token response, with tests for relative seconds, Unix seconds, and millisecond timestamps. (extensions/minimax/oauth.ts:62, 445a94e5c251)
Contributor supplied real terminal proof: The PR body includes redacted terminal output from a local MiniMax Portal OAuth profile showing models status reports ok expires in 364d and two real minimax-portal requests reached the provider in about 6 seconds after the patch. (445a94e5c251)
Related issue context narrows the scope: The referenced MiniMax auth latency issue was closed after maintainer live tests pointed away from API-key auth on current main, while this PR explicitly targets the narrower OAuth expiry normalization path.

Likely related people:

Ayaan Zaidi: Current checkout blame for the MiniMax OAuth expiry parsing and shared credential expiry evaluator points to commit 289eea0. (role: current-source introducer in local history; confidence: medium; commits: 289eea04d055; files: extensions/minimax/oauth.ts, extensions/minimax/provider-registration.ts, src/agents/auth-profiles/credential-state.ts)
Maosghoul: GitHub PR history shows early MiniMax OAuth work and the merged MiniMax OAuth library/docs update associated with the old portal-auth files. (role: original MiniMax OAuth contributor; confidence: medium; commits: 73c405f74aa8, 27185ad060e1, 938b1d8e3d28; files: extensions/minimax-portal-auth/oauth.ts, extensions/minimax-portal-auth/index.ts, docs/providers/minimax.md)
RyanLee-Dev: Merged PR history shows work on MiniMax portal OAuth config patching in extensions/minimax/provider-registration.ts and adjacent tests. (role: recent merged portal OAuth config contributor; confidence: medium; commits: 415578c4dc0a, 5f864aa6726e; files: extensions/minimax/provider-registration.ts, extensions/minimax/index.test.ts)
openperf: Merged MiniMax OAuth proxy-dispatcher work touched extensions/minimax/oauth.ts, which is the same runtime OAuth flow this PR changes. (role: adjacent OAuth transport contributor; confidence: medium; commits: 4e849ac1279d, 2dfb5bd445a1; files: extensions/minimax/oauth.ts, src/plugin-sdk/infra-runtime.ts)
hclsys: Recent PR history includes multiple MiniMax OAuth/refresh proposals touching the same OAuth runtime and raw-fetch allowlist, useful for routing overlap even though the inspected refresh PR is not merged. (role: recent proposed MiniMax OAuth refresh contributor; confidence: low; commits: 87ba6b16d9c4, a9d3a0c44e9b, fe83b0985dff; files: extensions/minimax/oauth.ts, extensions/minimax/provider-registration.ts, scripts/check-no-raw-channel-fetch.mjs)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 167e73cd5f84.

NianJiuZst · 2026-05-20T08:55:21Z

@clawsweeper re-review

clawsweeper · 2026-05-20T08:57:12Z

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

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/26152262971
Updated: 2026-05-20T09:04:40.353Z

clawsweeper · 2026-05-20T09:04:31Z

ClawSweeper PR egg

✨ Hatched: 🌱 uncommon Mossy Patch Peep

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

Merged PRs are hatchable.
Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 🌱 uncommon.
Trait: collects tiny proofs.
Image traits: location CI tidepool; accessory proof snapshot camera; palette seafoam, black, and opal; mood determined; pose sitting proudly on a smooth stone; shell soft velvet shell; lighting soft studio lighting; background tiny artifact crates.
Share on X: post this hatch
Copy: My PR egg hatched a 🌱 uncommon Mossy Patch Peep in ClawSweeper.

What is this egg doing here?

Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.

NianJiuZst · 2026-05-20T09:35:22Z

@clawsweeper hatch

clawsweeper · 2026-05-20T09:37:09Z

🦞👀
ClawSweeper PR egg hatch requested.

I queued a comment sync for this PR. If the egg is hatchable, ClawSweeper will generate the image once and update the existing review comment.
Action: PR egg hatch queued (workflow sweep.yml, event repository_dispatch).
The ASCII egg stays as the fallback.

…mestamp MiniMax returns expired_in from the token endpoint as a relative duration in seconds (standard OAuth expires_in semantics), but the auth profile store's hasUsableOAuthCredential() expects an absolute millisecond timestamp. Without conversion the token appears perpetually expired, triggering a slow OAuth refresh network call to api.minimaxi.com on every request — the root cause of the 30-50s auth-stage delay. Fixes openclaw#83449. Co-Authored-By: Claude Opus 4.6 <[email protected]>

@NianJiuZst

@NianJiuZst)

steipete · 2026-05-24T04:22:48Z

Thanks @NianJiuZst, landed with a small maintainer follow-up on top.

Proof:

pnpm test extensions/minimax/oauth.test.ts
pnpm run lint:tmp:no-raw-channel-fetch
env -u OPENCLAW_TESTBOX -u OPENCLAW_TESTBOX_REMOTE_RUN pnpm check:changed
MiniMax OAuth code endpoint probe confirmed expired_in from the authorization endpoint is already an absolute millisecond timestamp; token responses are now normalized before storing.
CI: https://github.com/openclaw/openclaw/actions/runs/26351650034
CodeQL Critical Quality: https://github.com/openclaw/openclaw/actions/runs/26351650012

Merged as d4e42d6.

@NianJiuZst

…mestamp (openclaw#83480) * fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp MiniMax returns expired_in from the token endpoint as a relative duration in seconds (standard OAuth expires_in semantics), but the auth profile store's hasUsableOAuthCredential() expects an absolute millisecond timestamp. Without conversion the token appears perpetually expired, triggering a slow OAuth refresh network call to api.minimaxi.com on every request — the root cause of the 30-50s auth-stage delay. Fixes openclaw#83449. Co-Authored-By: Claude Opus 4.6 <[email protected]> * fix(minimax): cover oauth expiry normalization * fix: polish minimax oauth expiry normalization (openclaw#83480) (thanks @NianJiuZst) * fix: update minimax raw fetch allowlist (openclaw#83480) --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

@NianJiuZst

…mestamp (openclaw#83480) * fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp MiniMax returns expired_in from the token endpoint as a relative duration in seconds (standard OAuth expires_in semantics), but the auth profile store's hasUsableOAuthCredential() expects an absolute millisecond timestamp. Without conversion the token appears perpetually expired, triggering a slow OAuth refresh network call to api.minimaxi.com on every request — the root cause of the 30-50s auth-stage delay. Fixes openclaw#83449. Co-Authored-By: Claude Opus 4.6 <[email protected]> * fix(minimax): cover oauth expiry normalization * fix: polish minimax oauth expiry normalization (openclaw#83480) (thanks @NianJiuZst) * fix: update minimax raw fetch allowlist (openclaw#83480) --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

@NianJiuZst

…mestamp (openclaw#83480) * fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp MiniMax returns expired_in from the token endpoint as a relative duration in seconds (standard OAuth expires_in semantics), but the auth profile store's hasUsableOAuthCredential() expects an absolute millisecond timestamp. Without conversion the token appears perpetually expired, triggering a slow OAuth refresh network call to api.minimaxi.com on every request — the root cause of the 30-50s auth-stage delay. Fixes openclaw#83449. Co-Authored-By: Claude Opus 4.6 <[email protected]> * fix(minimax): cover oauth expiry normalization * fix: polish minimax oauth expiry normalization (openclaw#83480) (thanks @NianJiuZst) * fix: update minimax raw fetch allowlist (openclaw#83480) --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

@NianJiuZst

…mestamp (openclaw#83480) * fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp MiniMax returns expired_in from the token endpoint as a relative duration in seconds (standard OAuth expires_in semantics), but the auth profile store's hasUsableOAuthCredential() expects an absolute millisecond timestamp. Without conversion the token appears perpetually expired, triggering a slow OAuth refresh network call to api.minimaxi.com on every request — the root cause of the 30-50s auth-stage delay. Fixes openclaw#83449. Co-Authored-By: Claude Opus 4.6 <[email protected]> * fix(minimax): cover oauth expiry normalization * fix: polish minimax oauth expiry normalization (openclaw#83480) (thanks @NianJiuZst) * fix: update minimax raw fetch allowlist (openclaw#83480) --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

@NianJiuZst

…mestamp (openclaw#83480) * fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp MiniMax returns expired_in from the token endpoint as a relative duration in seconds (standard OAuth expires_in semantics), but the auth profile store's hasUsableOAuthCredential() expects an absolute millisecond timestamp. Without conversion the token appears perpetually expired, triggering a slow OAuth refresh network call to api.minimaxi.com on every request — the root cause of the 30-50s auth-stage delay. Fixes openclaw#83449. Co-Authored-By: Claude Opus 4.6 <[email protected]> * fix(minimax): cover oauth expiry normalization * fix: polish minimax oauth expiry normalization (openclaw#83480) (thanks @NianJiuZst) * fix: update minimax raw fetch allowlist (openclaw#83480) --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

@NianJiuZst

…mestamp (openclaw#83480) * fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp MiniMax returns expired_in from the token endpoint as a relative duration in seconds (standard OAuth expires_in semantics), but the auth profile store's hasUsableOAuthCredential() expects an absolute millisecond timestamp. Without conversion the token appears perpetually expired, triggering a slow OAuth refresh network call to api.minimaxi.com on every request — the root cause of the 30-50s auth-stage delay. Fixes openclaw#83449. Co-Authored-By: Claude Opus 4.6 <[email protected]> * fix(minimax): cover oauth expiry normalization * fix: polish minimax oauth expiry normalization (openclaw#83480) (thanks @NianJiuZst) * fix: update minimax raw fetch allowlist (openclaw#83480) --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

@NianJiuZst

…mestamp (openclaw#83480) * fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp MiniMax returns expired_in from the token endpoint as a relative duration in seconds (standard OAuth expires_in semantics), but the auth profile store's hasUsableOAuthCredential() expects an absolute millisecond timestamp. Without conversion the token appears perpetually expired, triggering a slow OAuth refresh network call to api.minimaxi.com on every request — the root cause of the 30-50s auth-stage delay. Fixes openclaw#83449. Co-Authored-By: Claude Opus 4.6 <[email protected]> * fix(minimax): cover oauth expiry normalization * fix: polish minimax oauth expiry normalization (openclaw#83480) (thanks @NianJiuZst) * fix: update minimax raw fetch allowlist (openclaw#83480) --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

@NianJiuZst

…mestamp (openclaw#83480) * fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp MiniMax returns expired_in from the token endpoint as a relative duration in seconds (standard OAuth expires_in semantics), but the auth profile store's hasUsableOAuthCredential() expects an absolute millisecond timestamp. Without conversion the token appears perpetually expired, triggering a slow OAuth refresh network call to api.minimaxi.com on every request — the root cause of the 30-50s auth-stage delay. Fixes openclaw#83449. Co-Authored-By: Claude Opus 4.6 <[email protected]> * fix(minimax): cover oauth expiry normalization * fix: polish minimax oauth expiry normalization (openclaw#83480) (thanks @NianJiuZst) * fix: update minimax raw fetch allowlist (openclaw#83480) --------- Co-authored-by: Claude Opus 4.6 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

openclaw-barnacle Bot added extensions: minimax size: S triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 18, 2026

NianJiuZst force-pushed the fix/minimax-oauth-expiry-83449 branch from 33702de to 8ca77fd Compare May 18, 2026 07:03

openclaw-barnacle Bot added size: XS and removed size: S labels May 18, 2026

NianJiuZst changed the title ~~fix(minimax): normalize OAuth token expiry and add prepareRuntimeAuth cache~~ fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp May 18, 2026

yyds-xxxx mentioned this pull request May 19, 2026

[Bug]: Session resource loader grows unbounded across warm turns — 5.x regression vs 4.23 baseline (Windows + Feishu + MiniMax OAuth) #83943

Closed

openclaw-barnacle Bot added scripts Repository scripts size: S proof: supplied External PR includes structured after-fix real behavior proof. and removed size: XS triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 19, 2026

steipete self-assigned this May 24, 2026

NianJiuZst and others added 2 commits May 24, 2026 04:37

fix(minimax): cover oauth expiry normalization

cb45c3e

fix: polish minimax oauth expiry normalization (openclaw#83480) (thanks

026b625

@NianJiuZst)

steipete force-pushed the fix/minimax-oauth-expiry-83449 branch from 445a94e to 026b625 Compare May 24, 2026 04:11

openclaw-barnacle Bot added size: XS and removed size: S proof: sufficient ClawSweeper judged the real behavior proof convincing. labels May 24, 2026

fix: update minimax raw fetch allowlist (openclaw#83480)

ea3cd49

steipete merged commit d4e42d6 into openclaw:main May 24, 2026
92 checks passed

github-actions Bot mentioned this pull request May 24, 2026

📡 Upstream Digest — 2026-05-24 06:54 UTC curtismercier/openclaw-mods#931

Open

clawsweeper Bot mentioned this pull request Jun 26, 2026

[Bug] MiniMax Portal OAuth token cannot auto-refresh — refreshOAuth method not implemented #77467

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp#83480

fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp#83480
steipete merged 4 commits into
openclaw:mainfrom
NianJiuZst:fix/minimax-oauth-expiry-83449

NianJiuZst commented May 18, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 18, 2026 •

edited

Loading

Uh oh!

NianJiuZst commented May 20, 2026

Uh oh!

clawsweeper Bot commented May 20, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 20, 2026 •

edited

Loading

Uh oh!

NianJiuZst commented May 20, 2026

Uh oh!

clawsweeper Bot commented May 20, 2026

Uh oh!

Uh oh!

steipete commented May 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

NianJiuZst commented May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Real behavior proof

Root Cause

Changes

Verification

Uh oh!

clawsweeper Bot commented May 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NianJiuZst commented May 20, 2026

Uh oh!

clawsweeper Bot commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Hatch command

Uh oh!

NianJiuZst commented May 20, 2026

Uh oh!

clawsweeper Bot commented May 20, 2026

Uh oh!

Uh oh!

steipete commented May 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

NianJiuZst commented May 18, 2026 •

edited

Loading

clawsweeper Bot commented May 18, 2026 •

edited

Loading

clawsweeper Bot commented May 20, 2026 •

edited

Loading

clawsweeper Bot commented May 20, 2026 •

edited

Loading