Summary

Upgrading OpenClaw from 2026.5.28 to 2026.6.1 (build 2e08f0f) regresses the bundle-tools prep stage from a stable 5–7s to a sustained 21–27s — roughly 3–4× slower per turn — on a host with 3 stdio MCP servers configured (minimax-mcp, minimax-coding-plan-mcp, github-mcp).

The same code, the same config, the same MCP servers, the same node version, the same gateway: only the OpenClaw version changed.

Evidence

Side-by-side prep stage breakdown from gateway journal logs, single host, single day, same model (minimax/MiniMax-M3), same 3 MCP servers, no config edits between runs. Sampling 2 runs from each day; timestamps are wall-clock (Asia/Shanghai):

Other prep stages are stable across the upgrade (workspace-sandbox 0–44 ms, skills 0–130 ms, core-plugin-tools 32–75 ms, bootstrap-context 4–43 ms, system-prompt 5–27 ms, session-resource-loader 5–137 ms, agent-session 1–7 ms, stream-setup 30–110 ms). Only bundle-tools regressed.

[agent/embedded] [trace:embedded-run] prep stages: phase=stream-ready totalMs=27760
  stages=workspace-sandbox:0ms@0ms, skills:0ms@0ms,
         core-plugin-tools:38ms@38ms, bootstrap-context:5ms@43ms,
         bundle-tools:27639ms@27682ms,        ← black box
         system-prompt:7ms@27689ms, session-resource-loader:31ms@27720ms,
         agent-session:1ms@27721ms, stream-setup:39ms@27760ms

Reproduction

1. Install OpenClaw 2026.5.28 on a Linux host with Node v22.22.2.
2. Configure 3 stdio MCP servers (e.g. minimax-mcp, minimax-coding-plan-mcp, github-mcp) via openclaw.json .mcp.servers.
3. Send a few conversational turns; confirm bundle-tools settles around 5–7s.
4. Upgrade in-place to OpenClaw 2026.6.1 (2e08f0f).
5. Send a few more turns; bundle-tools jumps to 21–27s and stays there.
6. openclaw gateway restart does not help. The slow timing is reproducible from the first turn after the upgrade.

Expected

Upgrading OpenClaw minor/major versions should not introduce a 3–4× per-turn latency regression on a configuration that was previously stable. The bundle-tools stage should remain within ±1s of the 5.5.28 baseline (or carry its own release note explaining why).

Actual

bundle-tools consistently takes 21–27s in 2026.6.1, even on the first turn after a fresh gateway start. The other prep stages are unaffected, so the regression is localized to the bundle-tools code path. The agent still produces correct output, so the change is silently degrading UX.

The user's downstream signal was "responses feel slow after the upgrade", which surfaces as a roughly 15s delta to first token for every turn — the difference between interactive and "go make a coffee" cadence.

Environment

• OpenClaw: 2026.6.1 (2e08f0f), reproduced from 2026.5.28 baseline
• Node: v22.22.2
• OS: Linux x86_64
• Channels: feishu (default), qqbot
• Primary model: minimax/MiniMax-M3
• MCP servers configured (3, all stdio):
  • minimax-mcp (uvx minimax-mcp)
  • minimax-coding-plan-mcp (uvx minimax-coding-plan-mcp)
  • github-mcp (npx -y @modelcontextprotocol/server-github)
• Plugins enabled (selected): lossless-claw, active-memory, memory-core, codex, ov-recall-hook, rules-enforcer
• Context engine: [email protected] — see "Context engine disclosure" below

Workarounds tried

1. Restart the gateway after the upgrade — does not change bundle-tools timing.
2. Switch plugins.slots.contextEngine to legacy (temporarily, to isolate) — does not change bundle-tools timing. The slow stage is before the context engine hook, in tool bundling.
3. Downgrade back to 2026.5.28 — restores the 5–7s baseline.

No other prep stage shows a comparable regression, so a per-stage config knob won't help here — the bundle-tools code path itself needs to be examined.

Context engine disclosure

We run [email protected] (by @martian-engineering) as the active context engine plugin: plugins.slots.contextEngine: "lossless-claw". The plugin implements DAG-based conversation summarization on top of OpenClaw's context engine contract and sets ownsCompaction: true (it owns compaction, not OpenClaw core).

This is not implicated in the regression. The bundle-tools stage runs strictly before the context engine's assemble() hook — it serializes tool definitions for the LLM call. To confirm, we temporarily switched plugins.slots.contextEngine to legacy and re-ran; the bundle-tools: 21-27s regression was unchanged. So OpenClaw core's tool-bundling path is the regressing layer, regardless of which context engine sits behind it.

We mention this only so maintainers don't have to ask "could it be lossless-claw?" — answer: no, and we tested.

Related upstream issues

These are the closest existing reports and discussions; this report adds a clean before/after diff that points specifically at the 2026.5.28 → 2026.6.1 upgrade as the inflection point.

• observability: emit per-MCP-server sub-spans inside bundle-tools so cold-start cost is attributable #81595 — observability: emit per-MCP-server sub-spans inside bundle-tools so cold-start cost is attributable
  Most directly related. PR Add bundle MCP diagnostics timeline spans #81787 (Add bundle MCP diagnostics timeline spans) implements per-MCP-server sub-spans. This would let me prove which of the 3 MCP servers is regressing in 6.1. Without it, I'm reporting a 21s black box.
• perf: per-request auth (5.5s) and tool bundling (8.9s) dominate gateway TTFT #80131 — perf: per-request auth (5.5s) and tool bundling (8.9s) dominate gateway TTFT
  Proposes memoizing bundle-tools and singleton auth. Stale (no movement since 2026-06-02). The fix in perf: per-request auth (5.5s) and tool bundling (8.9s) dominate gateway TTFT #80131 is the structural remedy; this report is the regression evidence that says "now is the time".
• feat(embedded-runner): expose prep stage timings #78381 — feat(embedded-runner): expose prep stage timings ✅ merged
  This is why I can write this report at all. Thank you.
• Gateway lazy-spawns duplicate stdio MCP children with identical ppid+config (memory + CPU leak) #75621 — Gateway lazy-spawns duplicate stdio MCP children with identical ppid+config
  Adjacent: looks at duplicate-child cost in bundle-tools. Less likely to be the cause on my host (no duplicate children observed), but worth ruling out.
• DefaultResourceLoader.reload() blocks event loop for 12-15s on Windows due to synchronous filesystem scanning #79899 — DefaultResourceLoader.reload() blocks event loop for 12-15s on Windows
  Different stage (session-resource-loader), but same family of "sync filesystem scanning inside a prep stage" issues.

What would unblock me (any of these)

1. A per-MCP-server sub-span inside bundle-tools (PR Add bundle MCP diagnostics timeline spans #81787) — would tell me whether the regression is in a specific server's tools/list roundtrip or in the bundling loop itself.
2. A git log pointer on the bundle-tools code path between 2026.5.28 and 2026.6.1 — would help me bisect locally.
3. Confirmation that a 6.1.x patch is already planned.
4. A documented bundle-tools.timeout / bundle-tools.cache knob to short-circuit the regression while the underlying fix lands.

Cross-references

• LCM / lossless-claw is not implicated: bundle-tools happens before the context engine hook, and the regression is identical with slots.contextEngine: legacy (tested).
• The 3 MCP servers are stock public packages (minimax-mcp, minimax-coding-plan-mcp, @modelcontextprotocol/server-github); no exotic transports, no custom fork.