Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On Windows 11 with Feishu/Lark + MiniMax OAuth (minimax-portal), two
compounding regressions make the agent unusable for daily conversation
in 5.x versions (tested 5.7, 5.12, 5.18):

1. session-resource-loader grows unbounded across warm turns:
   starts at ~14s after cleanup, grows to 35-42s within the same
   gateway session, with no recovery path without manual cleanup.

2. MiniMax OAuth auth stage takes 30-42s per request regardless of
   token validity or network conditions.

In 4.23 with identical config: auth < 1s, session-resource-loader
< 2s, total response < 30s. In 5.18: total response 4-5 minutes
for a simple "hello".

Note: #83480 targets the auth regression. This issue focuses on the
session-resource-loader growth, which is a separate compounding problem.

Steps to reproduce

1. Windows 11 (Build 26200.8457), Node.js v24.14.0
2. OpenClaw 5.18, installed via npm
3. Model: minimax-portal/MiniMax-M2.7 (OAuth, CN endpoint)
4. Channel: Feishu/Lark (5 bots, WebSocket mode, HTTP_PROXY=127.0.0.1:7890)
5. Start gateway, send any message
6. Observe session-resource-loader time
7. Send a second message without restarting gateway
8. Observe session-resource-loader time increase
9. Repeat — the time grows with each warm turn

I want most of the configurations to be similar to my current txt configuration. Thanks.

99999 (1).txt

Expected behavior

session-resource-loader should remain stable across warm turns, as it
did in 4.23. Loading the same session should not get progressively
slower without new data being added.

In 4.23: session-resource-loader consistently < 2s regardless of
how many messages have been sent in the same gateway session.

Actual behavior

session-resource-loader grows progressively per warm turn:

• After cleanup (fresh session): ~14s
• After 2-3 messages: ~31-35s
• After 4-5 messages: ~42-47s
• If left running: approaches the 300s timeoutSeconds limit

Combined with auth regression (30-42s), total response time reaches
4-5 minutes for a simple message.

OpenClaw version

2026.5.18

Operating system

Windows 11 (Build 26200.8457)

Install method

npm

Model

minimax-portal/MiniMax-M2.7

Provider / routing chain

Primary: minimax-portal/MiniMax-M2.7 (OAuth, CN endpoint: api.minimaxi.com/anthropic/v1) Fallback: custom-api-deepseek-com/deepseek-chat

Additional provider/model setup details

No response

Logs, screenshots, and evidence

// Fresh session after cleanup — session-resource-loader baseline
startup stages: auth:32326ms
prep stages: session-resource-loader:14518ms  ← baseline after cleanup

// Second message, same gateway session
startup stages: auth:31766ms  
prep stages: session-resource-loader:31521ms  ← doubled

// Third message, same gateway session
startup stages: auth:38411ms
prep stages: session-resource-loader:42293ms  ← tripled

// Full timing breakdown (message 3):
[trace:embedded-run] startup stages:
  auth:38411ms
  
[trace:embedded-run] core-plugin-tool stages: totalMs=12204
  tool-policy:4825ms
  video-generate-tool:1971ms  ← not used, still loaded
  plugin-tools:3637ms

[trace:embedded-run] prep stages: totalMs=59717
  core-plugin-tools:12205ms
  session-resource-loader:42293ms  ← main bottleneck
  
// Liveness warning fires during session-resource-loader block:
[diagnostic] liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu
  eventLoopDelayMaxMs=42412.8
  eventLoopUtilization=1
  cpuCoreRatio=0.994

// ws timeout caused by event loop block:
[error] timeout of 15000ms exceeded

// 4.23 baseline (identical config, identical network):
startup stages: auth:<500ms
prep stages: session-resource-loader:<2s
Total response: <30s

Impact and severity

Proxy configuration: HTTP_PROXY=http://127.0.0.1:7890 (Clash)
Tested without proxy: auth increases to 38s (proxy helps MiniMax CN latency)
Tested with proxy: auth ~32s

Config notes:

• 4 Feishu bots (lobster-bot, aochuang-bot, zhoubapi-bot, jiaweisi-bot)
• memory-core enabled with dreaming (22:00 Asia/Shanghai)
• session.maintenance: pruneAfter=30d, maxEntries=80
• hooks: boot-md, bootstrap-extra-files, command-logger, session-memory all enabled
• MEMORY.md size: 11KB (ruled out as cause)
• sessions cleanup performed before testing — growth resumes immediately

Hypothesis: the session-resource-loader is re-reading and re-indexing
the session JSONL on every turn rather than caching the loaded state
between warm turns. The growth pattern (roughly linear with turn count)
suggests O(n) reads per turn rather than incremental/cached reads.

This was filed alongside #82021 and is referenced in IsItStable #82
as a contributing regression to the 5.12 stability score of 20-29.

• [Bug]: All model requests timed out #82021 — original report (auth + general timeout)
• [Bug]: MiniMax auth stage takes 30-50s on every request in 5.x — worked fine in 4.23 #83449 — MiniMax auth 30-50s regression (IsItStable evidence)
• fix(minimax): normalize OAuth token expiry to absolute millisecond timestamp #83480 — PR fixing MiniMax OAuth token expiry normalization (auth fix)
• [Bug]: Feishu plugin: slow response after v2026.5.12 — start-account re-probes on every message #83103 — Feishu plugin start-account re-probes
• [Regression]: OpenClaw 2026.5.12 is dramatically slower than 2026.5.7 (QQBot / status / overall responsiveness) #82264 — 5.12 dramatically slower than 5.7
• [Bug]: Embedded run attempt-dispatch span lacks dispatch subphase detail #82782 — slow embedded-run attempt-dispatch startup (fixed in beta)

This regression makes 5.x completely unusable on Windows with Feishu +
MiniMax OAuth for daily conversation. Every warm turn adds ~10-15s to
session-resource-loader, pushing total response time to 4-5 minutes
within a normal conversation session.

Workaround: none that preserves session history. openclaw sessions
cleanup resets the timer but destroys conversation context, which is
unacceptable for a production assistant setup.

Rolling back to 4.23 fully resolves the issue. Tested across 5.7,
5.12, and 5.18 — all affected.

Additional information