Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
After upgrading from 4.23 to 5.x (tested on 5.7, 5.12), every single message
triggers an auth stage that takes 30–50 seconds before the agent can respond.
In 4.23, the same setup responded in under 5 seconds. The auth delay alone
makes the agent unusable for daily conversation.
This is a Windows + MiniMax CN (api.minimaxi.com) + Feishu/Lark specific
combination. The issue persists regardless of whether minimax-portal (OAuth)
or minimax (api_key) is used as the provider.
Steps to reproduce
- Windows 11, Node.js v22.16+
- OpenClaw 5.12 (or 5.7), installed via npm
- Model: minimax-portal/MiniMax-M2.7
Provider: minimax-portal with OAuth (CN endpoint: api.minimaxi.com)
Fallback: custom-api-deepseek-com/deepseek-chat
- Channel: Feishu/Lark (5 bot accounts, WebSocket mode)
- Send any message to any Feishu bot
- Observe auth stage in logs
Expected behavior
Auth stage should complete in under 1 second, as it did in 4.23.
The agent should respond to a simple "Hello" within 10–15 seconds total.
Actual behavior
Auth stage consistently takes 30–50 seconds on every single message request.
This happens regardless of session warmup state — even warm sessions trigger
the full auth delay on every message. Combined with session-resource-loader
(20–35s) and tool-policy (3–5s), total response time reaches 3–5 minutes
for a simple greeting.
Confirmed: rolling back to 4.23 with identical config reduces auth to <1s
and total response time to under 10s.
OpenClaw version
5.7 (f066dd2), also reproduced on 5.12 (eeef486)
Operating system
Windows 11 (Build 26200.8457)
Install method
npm
Model
minimax-portal/MiniMax-M2.7
Provider / routing chain
openclaw -> minimax-portal/MiniMax-M2.7 (primary) openclaw -> custom-api-deepseek-com/deepseek-chat (fallback)
Additional provider/model setup details
openclaw -> minimax-portal/MiniMax-M2.7 (primary)
openclaw -> custom-api-deeps- Provider: minimax-portal
- Auth mode: OAuth (CN endpoint)
- Base URL: https://api.minimaxi.com/anthropic/v1
- Also tested with api_key mode (minimax provider) — same auth delay
- minimax-portal OAuth token is valid (expires in 332 days per models status)
- Providers w/ OAuth/tokens: confirmed clean (0 stale OAuth entries)
- Direct curl to api.minimaxi.com takes ~18s from this network
(network latency contributes, but 4.23 handled same network in <1s)eek-com/deepseek-chat (fallback)
Logs, screenshots, and evidence
// Gateway startup — auth resolution already slow at startup
12:11:32 [gateway] loading configuration…
12:11:41 [gateway] resolving authentication… ← 9 seconds at startup
// Per-message auth stage — 48 seconds every time
[trace:embedded-run] startup stages:
phase=attempt-dispatch totalMs=51381
stages=workspace:1ms,runtime-plugins:70ms,hooks:0ms,
model-resolution:283ms,auth:48727ms,context-engine:2ms,
attempt-dispatch:2298ms
// Same pattern repeated on every message:
auth:32514ms (message 1)
auth:40253ms (message 2)
auth:45935ms (message 3)
auth:48727ms (message 4)
// 4.23 baseline (same config, same network):
auth: <500ms
Impact and severity
Additional information
Tested cconfigurations @cconfigurationsonfigurationsonfigurations to isolate the issue:
- Removed all minimax-portal-cn and minimax-portal OAuth entries → no change
- Switched from minimax-portal (OAuth) to minimax (api_key) → same auth delay
- Cleared session history → session-resource-loader improved, auth unchanged
- Tested on 5.7 → same auth delay, confirmed regression started after 4.23
- Rolled back to 4.23 → auth <500ms, full response <10s
The auth stage delay appears to be unrelated to OAuth specifically,
since api_key mode exhibits the same behavior. Suspect the issue is in
how 5.x initializes the provider connection on each embedded run.
8888 (1).txt
Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
After upgrading from 4.23 to 5.x (tested on 5.7, 5.12), every single message
triggers an auth stage that takes 30–50 seconds before the agent can respond.
In 4.23, the same setup responded in under 5 seconds. The auth delay alone
makes the agent unusable for daily conversation.
This is a Windows + MiniMax CN (api.minimaxi.com) + Feishu/Lark specific
combination. The issue persists regardless of whether minimax-portal (OAuth)
or minimax (api_key) is used as the provider.
Steps to reproduce
Provider: minimax-portal with OAuth (CN endpoint: api.minimaxi.com)
Fallback: custom-api-deepseek-com/deepseek-chat
Expected behavior
Auth stage should complete in under 1 second, as it did in 4.23.
The agent should respond to a simple "Hello" within 10–15 seconds total.
Actual behavior
Auth stage consistently takes 30–50 seconds on every single message request.
This happens regardless of session warmup state — even warm sessions trigger
the full auth delay on every message. Combined with session-resource-loader
(20–35s) and tool-policy (3–5s), total response time reaches 3–5 minutes
for a simple greeting.
Confirmed: rolling back to 4.23 with identical config reduces auth to <1s
and total response time to under 10s.
OpenClaw version
5.7 (f066dd2), also reproduced on 5.12 (eeef486)
Operating system
Windows 11 (Build 26200.8457)
Install method
npm
Model
minimax-portal/MiniMax-M2.7
Provider / routing chain
openclaw -> minimax-portal/MiniMax-M2.7 (primary) openclaw -> custom-api-deepseek-com/deepseek-chat (fallback)
Additional provider/model setup details
openclaw -> minimax-portal/MiniMax-M2.7 (primary)
openclaw -> custom-api-deeps- Provider: minimax-portal
(network latency contributes, but 4.23 handled same network in <1s)eek-com/deepseek-chat (fallback)
Logs, screenshots, and evidence
Impact and severity
Additional information
Tested c
configurations@cconfigurationsonfigurationsonfigurations to isolate the issue:The auth stage delay appears to be unrelated to OAuth specifically,
since api_key mode exhibits the same behavior. Suspect the issue is in
how 5.x initializes the provider connection on each embedded run.
8888 (1).txt