[Bug]: Severe per-turn latency on Windows 11 after 2026.4.29 even with Active Memory disabled

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On Windows 11 with OpenClaw 2026.4.29, simple Telegram direct-chat turns take roughly 50+ seconds of internal gateway/embedded-run processing before reply delivery, even after disabling Active Memory and reducing MEMORY.md size.

Steps to reproduce

1. Run OpenClaw 2026.4.29 on Windows 11 via npm global install.
2. Use a Telegram direct session with a short prompt such as Test.
3. Observe delayed replies in Telegram.
4. Check gateway log and observe embedded-run startup/prep stages taking ~22s + ~25-27s before reply streaming/dispatch.
5. Disable Active Memory globally, restart gateway, and repeat.
6. Observe that large per-turn latency persists.

Expected behavior

A short Telegram direct-chat turn should respond in a few seconds, especially after Active Memory is disabled and workspace memory bootstrap size is reduced.

Actual behavior

Even after disabling Active Memory and shrinking MEMORY.md from >12 KB to ~2.3 KB, replies remain very slow. Logs show repeated per-turn delays dominated by embedded-run startup and prep stages before the assistant can answer.

OpenClaw version

OpenClaw 2026.4.29 (a448042)

Operating system

Windows 11

Install method

npm global

Model

Observed with openai-codex/gpt-5.4; similar user-visible latency also occurred earlier with ZAI models.

Provider / routing chain

OpenClaw -> local gateway on Windows -> Telegram + model provider

Additional provider/model setup details

• Telegram direct chat session
• Active Memory was initially enabled, then disabled globally for A/B comparison
• Default model path had to be corrected from openai/gpt-5.5 to openai-codex/gpt-5.4 because the former incurred auth failures on this install
• After that config fix, latency still remained high
• MEMORY.md was reduced below bootstrap truncation threshold, but latency still remained high

Logs, screenshots, and evidence

19:04:18 [agent/embedded] [trace:embedded-run] startup stages: runId=0cea60d9-c65c-4ba5-9e76-6e9bbdbc1cff sessionId=eda8d715-1825-45bc-88f9-72db577224a0 phase=attempt-dispatch totalMs=22481 stages=workspace:0ms@0ms,runtime-plugins:2ms@2ms,hooks:0ms@2ms,model-resolution:11149ms@11151ms,auth:7198ms@18349ms,context-engine:1ms@18350ms,attempt-dispatch:4131ms@22481ms

19:04:45 [agent/embedded] [trace:embedded-run] prep stages: runId=0cea60d9-c65c-4ba5-9e76-6e9bbdbc1cff sessionId=eda8d715-1825-45bc-88f9-72db577224a0 phase=stream-ready totalMs=27172 stages=workspace-sandbox:78ms@78ms,skills:0ms@78ms,core-plugin-tools:7658ms@7736ms,bootstrap-context:1122ms@8858ms,bundle-tools:1536ms@10394ms,system-prompt:6092ms@16486ms,session-resource-loader:3917ms@20403ms,agent-session:3ms@20406ms,stream-setup:6766ms@27172ms

Earlier evidence before Active Memory disable:

[hooks] before_prompt_build handler from active-memory failed: timed out after 45000ms
lane task error: lane=main durationMs=51496 error="CommandLaneTaskTimeoutError: Command lane "main" task timed out after 45000ms"
active-memory: agent=atlas session=agent:atlas:telegram:direct:5348413534 activeProvider=openai-codex activeModel=gpt-5.4 start timeoutMs=15000 queryChars=551

After restart with Active Memory disabled, the main remaining issue was still high per-turn embedded-run cost plus event loop warnings:

liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=33s eventLoopDelayP99Ms=14680.1 eventLoopDelayMaxMs=14680.1 eventLoopUtilization=1 cpuCoreRatio=1.083 active=0 waiting=0 queued=0
liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=43s eventLoopDelayP99Ms=20015.2 eventLoopDelayMaxMs=20015.2 eventLoopUtilization=0.996 cpuCoreRatio=1.019 active=0 waiting=0 queued=0

Related config/auth misroute observed after restart:

agent model: openai/gpt-5.5
lane task error: lane=main durationMs=12811 error="FailoverError: No API key found for provider \"openai\". You are authenticated with OpenAI Codex OAuth. Use openai-codex/gpt-5.5, or set OPENAI_API_KEY for direct OpenAI API access."

This misroute was corrected locally, but severe latency persisted.

Bootstrap evidence before memory trim:

workspace bootstrap file MEMORY.md is 13195 chars (limit 12000); truncating in injected context

MEMORY.md was then reduced to ~2325 bytes, but latency remained >1 minute user-visible in Telegram.

Current process evidence during investigation:

Get-Process node
Id   CPU         WS         Path
1912 715.859375  809078784  C:\Program Files\nodejs\node.exe

Telegram transport itself appears capable of successful sends:

telegram sendMessage ok chat=5348413534 message=19999
telegram sendMessage ok chat=5348413534 message=20000

This suggests much of the delay occurs before send.

Impact and severity

Affected: Telegram direct-chat usage on this Windows 11 install Severity: High Frequency: Repeated across many short test prompts Consequence: Even trivial exchanges feel unusable because replies take roughly 1 minute user-visible end-to-end

Additional information

• Active Memory was a real contributor initially, but disabling it did not resolve the main latency problem.
• Last observed remaining bottlenecks are model-resolution, auth, core-plugin-tools, system-prompt, and stream-setup on nearly every turn.
• This looks like a Windows-specific or runtime/regression issue in the embedded-run pipeline rather than a pure provider-latency problem.