Summary

OpenClaw becomes very slow/unreliable for simple Telegram direct messages when using:

• active-memory enabled
• openclaw-honcho as memory backend
• lossless-claw as context engine
• OpenAI/Codex-backed main model
• Active Memory pinned to openai/gpt-5.4-mini

Even after pinning Active Memory to a cheaper/faster mini model with minimal thinking, the active-memory recall still times out and the logs show Codex app-server startup aborts in both the main lane and active-memory lane.

This suggests the issue is not Honcho itself or model intelligence/latency, but the OpenClaw runtime path around Active Memory embedded sub-agents, Codex app-server startup/thread binding, context-engine projection, and OpenAI/Codex auth prewarm.

Environment

• OpenClaw: 2026.5.22 (a374c3a)
• Node: v22.22.2
• OS: Ubuntu 24.04 / Linux 6.8.0-111-generic x64
• Install: npm global / systemd user gateway
• Channel: Telegram direct chat
• Gateway service: systemd user service
• Memory slot: openclaw-honcho
• Context engine slot: lossless-claw

Relevant config

{
  "plugins": {
    "slots": {
      "memory": "openclaw-honcho",
      "contextEngine": "lossless-claw"
    },
    "entries": {
      "active-memory": {
        "enabled": true,
        "config": {
          "enabled": true,
          "agents": ["main"],
          "allowedChatTypes": ["direct"],
          "queryMode": "message",
          "promptStyle": "strict",
          "thinking": "minimal",
          "timeoutMs": 2000,
          "setupGraceTimeoutMs": 0,
          "maxSummaryChars": 160,
          "recentUserTurns": 1,
          "recentAssistantTurns": 0,
          "recentUserChars": 180,
          "recentAssistantChars": 80,
          "cacheTtlMs": 60000,
          "circuitBreakerMaxTimeouts": 2,
          "circuitBreakerCooldownMs": 120000,
          "persistTranscripts": false,
          "logging": false,
          "model": "openai/gpt-5.4-mini"
        }
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai/gpt-5.5"
      }
    }
  }
}

openclaw models status --json reports:

openai via codex uses openai-codex

So even openai/gpt-5.4-mini appears to route through the Codex runtime/auth path in this setup.

Reproduction

1. Enable Honcho memory plugin.
2. Enable Active Memory for direct chats.
3. Use an OpenAI/Codex-backed default model such as openai/gpt-5.5.
4. Configure Active Memory model as openai/gpt-5.4-mini, thinking=minimal, timeoutMs=2000.
5. Send a trivial Telegram DM or run a local agent probe such as:

openclaw agent \
  --channel telegram \
  --session-key agent:main:telegram:direct:perf-test-openclaw \
  --message 'Perf test: reply with exactly: ok' \
  --thinking minimal \
  --timeout 90 \
  --json

Expected behavior

A trivial message should complete quickly. Active Memory should either complete within its bounded timeout or skip cleanly without blocking the main run, starving the event loop, or causing Codex app-server startup aborts.

Actual behavior

The test prompt eventually replies correctly, but wall time was about 61 seconds for a trivial ok response.

The gateway logs show:

codex app-server context-engine projection decision
active-memory: agent=main session=... activeProvider=openai activeModel=gpt-5.4-mini start timeoutMs=2000 queryChars=64 searchQueryChars=64
before_prompt_build handler from active-memory failed: timed out after 2000ms
active-memory: ... done status=timeout elapsedMs=3390 summaryChars=0
codex app-server context-engine projection decision
provider auth state pre-warmed in 63135ms eventLoopMax=36171.7ms
Codex agent harness failed; not falling back to embedded PI backend
lane task error: lane=main durationMs=17467 error="Error: codex app-server startup aborted"
lane task error: lane=session:...:active-memory:... durationMs=17472 error="Error: codex app-server startup aborted"
codex app-server wrote context-engine thread binding

The same pattern appeared earlier with timeoutMs=1000 and with the inherited default openai/gpt-5.5 model.

Why this looks like an OpenClaw runtime issue

• Honcho initialization and Telegram send operations are fast.
• Active Memory correctly picks up the pinned mini model.
• The failure still goes through Codex app-server/context-engine/auth startup.
• Logs show both lane=main and lane=...active-memory... hitting codex app-server startup aborted.
• Gateway event loop stalls during provider auth prewarm.

Related public reports

Possibly related:

• [Bug]: Active-memory embedded sub-agent run blocks event loop, starving Telegram polling — agent goes permanently unresponsive #65517
• Codex app-server turns time out after 60s despite meaningful progress #78756
• Community report mentioning Codex app-server hangs with Active Memory enabled: https://www.answeroverflow.com/?cursor=B_cdvZxUw5iVsdSlDNUQs7PFcqWdZiIeNkoLV9Ih1ArghJPxG4dIYuJWpUXmX6LGDq2wOOGDp_IlQyyZz1iIxTCdR0XaGQgG6Q9zOf3W1LpGE9ZVqHRfPw1Kxcs17_LLNH_wPEqpVYEuFZEV-Hh3kaPhhsIjPwlKeZ0qEecmjtwC8nA

Request

Please investigate whether Active Memory embedded recall runs should avoid the Codex app-server/context-engine/auth prewarm path when configured with a lightweight OpenAI model, or whether the Codex app-server startup/auth path should be made non-blocking/isolated so Active Memory cannot stall the main gateway/event loop.

It would also help if openai/gpt-* routing made it clearer whether a run is using direct OpenAI API auth vs openai-codex/Codex app-server auth.