Environment

• OpenClaw versions tested (all in same VM): 2026.5.3-1, 2026.5.4, 2026.5.6
• Node v22.22.2
• Ubuntu 24.04 LTS, e2-medium GCP VM (2 vCPU, 4GB), us-central1
• Channel: @openclaw/msteams (Bot Framework push, Tailscale Funnel)
• Provider/model: google/gemini-3-flash-preview
• Workspace size: trivial (~5KB SOUL.md, 3 chunks in active-memory store)
• Plugin loadout (after plugins.allow whitelist): google, msteams, active-memory, browser, web-readability, tavily

Symptom

On 2026.5.4 and 2026.5.6, every msteams DM goes through this path:

17:40:28 received message
17:40:29 dispatching to agent
17:42:28 stalled session: ... state=processing age=120s ... lastProgress=model_call:started
17:42:35 [llm-idle-timeout] google/gemini-3-flash-preview produced no reply before the idle watchdog; retrying same model
17:44:35 idle-timeout fires again → user sees "The model did not produce a response before the model idle timeout"

model.completed event recorded for the first attempt:

{
  "type": "model.completed",
  "data": {
    "aborted": true, "timedOut": true, "idleTimedOut": true,
    "promptError": "LLM idle timeout (240s): no response from model | LLM idle timeout (240s): no response from model",
    "promptErrorSource": "prompt",
    "assistantTexts": []
  }
}

The model never emits a single token from the gateway's perspective.

Direct curl to https://generativelanguage.googleapis.com/v1beta/models/gemini-3-flash-preview:generateContent from the same VM, same API key, same prompt: HTTP 200 in 1–3.5s. Network and API are fine.

What we tried (none fixed it on 5.4/5.6)

1. thinkingDefault: low → unchanged
2. models.providers.google.timeoutSeconds: 240 (with required baseUrl+models[]) → idle-timeout simply fires later at 240s
3. plugins.allow whitelist (69 plugins → 7) → unchanged
4. openclaw doctor --fix (24 unused skills disabled) → unchanged
5. NODE_COMPILE_CACHE + OPENCLAW_NO_RESPAWN=1 env → unchanged
6. Hard /reset of the affected user's session (trajectory archived, sessionKey cleared from sessions.json) → fresh sessionId STILL stalls on first turn
7. Stop+start gateway (full, not graceful) several times → unchanged
8. Confirmed Gemini API direct call works in 1–3.5s from same VM/key

What fixed it

Downgrade to 2026.5.3-1. Same config, same workspace, same plugins. Turn time dropped from 240s+ idle-timeout to ~39s end-to-end with dispatch complete.

Notes

• Same Gateway hosting another VM (googlechat channel, OpenClaw 2026.4.23) is unaffected — issue appears specific to the msteams + 5.4+ combination.
• Cluster issue [Bug]: Gateway CPU pinned at 100%: root causes & workarounds (complements #75688) #75707 (Gateway CPU pinned at 100%) was closed as implemented in 5.5/5.6, but the symptom in msteams persists past those releases on this VM.
• All workarounds from the [Bug]: Gateway CPU pinned at 100%: root causes & workarounds (complements #75688) #75707 thread (plugins.allow, session cleanup, lower thinking) were applied and did not resolve.

Repro

1. Provision Linux VM with msteams channel + Bot Framework + Funnel.
2. Install openclaw@2026.5.4 or later, configure channels.msteams.enabled: true, set MSTEAMS_APP_ID/PASSWORD/TENANT_ID.
3. Send a DM from a paired Teams user.
4. Observe: model.completed with idleTimedOut:true, assistantTexts:[] after ~120s/240s; user sees the standard idle-timeout error.
5. npm install -g openclaw@2026.5.3-1 and restart gateway → next DM responds in ~30–40s end-to-end.

Happy to share full trajectory dumps and gateway logs (sanitized) on request.