openclaw - 💡(How to fix) Fix [Bug]: Active Memory Telegram preflight exceeds timeout and retains gateway RSS after idle

Bug type

Behavior bug (latency and retained process memory after completed turns)

Beta release blocker

No

Summary

Consolidated replacement for #83752 with the later live evidence folded into the issue body.

On a live Linux VPS running OpenClaw 2026.5.18 (50a2481), Telegram group-topic turns that trigger Active Memory preflight can sharply increase gateway RSS and leave it elevated after the turn completes, even when /readyz is healthy and OpenClaw reports 0 queued · 0 running.

The strongest later datapoint is that the behavior still reproduced after tuning Active Memory down from full to recent, and then to message with timeoutMs: 5000. In the message / 5s test, the Active Memory hook still surfaced as a 10000ms timeout, RSS rose from roughly 590-607 MB to around 1.0-1.07 GB, and the high RSS remained until a clean gateway restart.

The previous issue #83752 had an initial ClawSweeper review before these later comments existed. This new issue exists to keep all current evidence in the main report and avoid split context.

Steps to reproduce

1. Run OpenClaw 2026.5.18 as a systemd user gateway with Telegram and Active Memory enabled.
2. Use a Telegram group topic/session where Active Memory is allowed for group/channel style sessions.
3. Restart the gateway cleanly and wait for /readyz.
4. Record gateway parent RSS shortly after restart and again after about 90 seconds idle.
5. Send a short Telegram group-topic message that triggers the main agent and Active Memory.
6. Record Active Memory timing, Telegram inbound-to-send timing, task pressure, /readyz, and gateway RSS after the turn completes.
7. Disable Active Memory in the same Telegram topic using /active-memory off and repeat a similar request.
8. Restart the idle gateway and compare the post-restart baseline RSS with the elevated post-Active-Memory value.

Expected behavior

Completed Telegram turns should not leave the gateway retaining hundreds of MB of extra RSS after the system is idle.

If Active Memory times out, it should respect the configured timeout semantics as clearly as possible, release/clean up any transient subagent state it owns, and degrade the reply path without leaving a high retained RSS footprint.

Actual behavior

The affected VPS repeatedly showed:

• clean post-restart gateway parent RSS around 430-570 MB after settling;
• Active Memory Telegram turns increasing RSS to around 1.0-1.08 GB;
• /readyz healthy and task pressure 0 queued · 0 running while RSS stayed elevated;
• a clean restart bringing the gateway back to the lower baseline.

The latest controlled test also showed timeoutMs=5000 surfacing as a hook timeout after 10000ms and Active Memory done status=timeout elapsedMs=10016.

OpenClaw version

OpenClaw 2026.5.18 (50a2481)

Operating system

Ubuntu 24.04.3 LTS, Linux 6.17.0-1011-oracle, aarch64

Install method

System-global npm install:

node=v22.22.0
npm=10.9.4
install root=/usr/lib/node_modules/openclaw
service=/home/ubuntu/.config/systemd/user/openclaw-gateway.service
ExecStart=/usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789

Model

openai/gpt-5.5

Provider / routing chain

OpenClaw gateway -> OpenAI Codex/ChatGPT auth, effective Codex harness for agent turns.

Active Memory configurations tested

Initial heavy configuration:

{
  "agents": ["main"],
  "allowedChatTypes": ["direct", "group", "channel"],
  "enabled": true,
  "logging": true,
  "maxSummaryChars": 220,
  "persistTranscripts": false,
  "promptStyle": "contextual",
  "queryMode": "full",
  "setupGraceTimeoutMs": 30000,
  "timeoutMs": 30000
}

Reduced configuration, still reproduced:

{
  "queryMode": "recent",
  "promptStyle": "balanced",
  "timeoutMs": 15000,
  "setupGraceTimeoutMs": 15000,
  "allowedChatTypes": ["direct", "group", "channel"]
}

Lowest-latency controlled Telegram-topic configuration, still reproduced:

{
  "queryMode": "message",
  "timeoutMs": 5000,
  "setupGraceTimeoutMs": 5000,
  "allowedChatTypes": ["direct", "group", "channel"]
}

Enabled plugins and local state size

plugins list: 92 known, 11 enabled/loaded, 0 errors
enabled: active-memory, anthropic, file-transfer, google, memory-core, memory-wiki, ollama, openai, telegram, tokenjuice, codex
codex plugin source: ~/.openclaw/npm/node_modules/@openclaw/codex
codex plugin version: 2026.5.6

~/.openclaw total: 7.7G
~/.openclaw/agents/main/sessions: 376M, 687 jsonl files
~/.openclaw/agents/codex/sessions: 368K, 10 jsonl files
~/.openclaw/agents/main/agent/codex-home/logs_2.sqlite: 714,862,592 bytes

Evidence: original full-context observation

Before clean restart on 2026.5.18:
RSS: ~1.4-1.6 GB
Memory diagnostic fired: rssBytes=1651253248 heapUsedBytes=498389504 thresholdBytes=1610612736

After clean restart:
~446 MB RSS shortly after ready
~509 MB RSS after ~90s
~570 MB RSS after ~6m45s
~566 MB RSS after ~9m27s

After one Telegram weather ask plus a follow-up log-check turn:
~1,001,404 kB RSS (~978 MiB)
readyz healthy
0 queued / 0 running
gateway process threads: 12
no child processes observed
swap: 0

Full-context timing:

20:25:15.970 inbound Telegram message received
20:25:21.200 embedded agent started (~5.2s after inbound)
20:25:23.381 Active Memory started
20:25:40.285 Active Memory finished: 16.9s, no relevant memory
20:25:44.319 Codex task started
20:26:26.677 wttr.in curl finished in ~80ms
20:26:43.561 final answer generated
20:26:47.728 Telegram sendMessage ok
Total inbound-to-Telegram-send: ~91.8s

Evidence: recent mode still reproduced

After switching from full/contextual/30000ms to recent/balanced/15000ms while keeping group/channel allowed:

Clean post-restart baseline:
~447 MB RSS shortly after ready
~495 MB RSS after ~90s
readyz healthy
0 queued / 0 running

Then one Telegram weather ask plus one log-check follow-up:

20:39:18 inbound Telegram weather message
20:39:26 active-memory start timeoutMs=15000 queryChars=58 searchQueryChars=58
20:39:47 active-memory done status=ok elapsedMs=21269 summaryChars=131
20:40:55 Telegram sendMessage ok

20:41:00 inbound Telegram log-check follow-up
20:41:03 active-memory start timeoutMs=15000 queryChars=593 searchQueryChars=288
20:41:21 active-memory done status=ok elapsedMs=18058 summaryChars=181

RSS after those turns:

PID     ELAPSED RSS     VSZ      %MEM %CPU CMD
1249003 04:24   1080144 44832448 4.3  37.2 /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
VmRSS:  1080144 kB
RssAnon: 699168 kB
RssFile: 380976 kB
readyz healthy
0 queued / 0 running

Evidence: message mode with 5s timeout still reproduced

After tuning to queryMode: "message", timeoutMs: 5000, setupGraceTimeoutMs: 5000, group/channel still allowed:

2026-05-18T21:01:19.922Z inbound Telegram group/topic message, 19 chars
2026-05-18T21:01:21.727Z main embedded agent started
2026-05-18T21:01:22.577Z active-memory start timeoutMs=5000 queryChars=19
2026-05-18T21:01:32.577Z hook failed: timed out after 10000ms
2026-05-18T21:01:33.941Z active-memory done status=timeout elapsedMs=10016 summaryChars=0

RSS moved from roughly 590-607 MB before this turn to a peak around 1.0-1.07 GB during/after the Active Memory timeout.

Then /active-memory off was sent in the same Telegram topic:

2026-05-18T21:01:41.064Z inbound Telegram group/topic message, 18 chars
2026-05-18T21:01:42.244Z outbound send ok

The follow-up weather-style request in the same topic did not show Active Memory hook/log lines:

2026-05-18T21:01:58.576Z inbound Telegram group/topic message, 58 chars
2026-05-18T21:02:00.205Z main embedded agent started
no active-memory start/done lines for this request
2026-05-18T21:02:33.492Z Telegram sendMessage ok

Inbound-to-send was about 34.9s with Active Memory disabled for the topic, versus about 77.7s in the prior message / 5s Active Memory test and about 91.8s before tuning.

Evidence: retained high RSS until restart

At 2026-05-18T21:05:39Z after the Active Memory timeout tests:

gateway parent RSS: 1,020,480 kB (~996 MiB)
process tree RSS: 1,179,660 kB (~1.13 GiB)
children:
  gateway parent: 1,020,480 kB
  codex app-server node child: 46,028 kB
  codex native app-server child: 113,152 kB
OpenClaw task pressure: 0 queued · 0 running
readyz healthy

After restarting an idle gateway:

immediately after restart: parent RSS 697,624 kB, service peak 667.1M
~90s after restart: parent RSS 483,656 kB, systemd service memory 428.3M, readyz healthy

So the high value was not the normal clean-start baseline on this host. It was retained runtime state after the Telegram/Active Memory tests, and a clean restart brought it back to the 430-480 MB range.

Impact and severity

Affected: live gateways using Telegram group topics plus Active Memory on persistent conversations, especially where Active Memory is allowed for group/channel sessions.

Severity: Medium. The gateway remained healthy on this VPS because the host has enough RAM, but RSS crossed OpenClaw's own diagnostic threshold before restart and can grow back quickly after user-visible turns.

Frequency: Observed repeatedly as high peaks across multiple recent versions on this VPS. The exact minimal trigger is still not fully isolated.

Consequence: higher steady-state memory footprint, possible memory pressure on smaller hosts, and slow Telegram replies because Active Memory is a blocking pre-reply step.

Related / not duplicate notes

• Original issue being superseded: #83752
• Related open memory issue mentioned by ClawSweeper: #69451, but this report has a narrower Telegram + Active Memory preflight trigger and should not be closed as a duplicate of session-file memory growth without further proof.
• Adjacent open PR found during contributor duplicate scan: #73667 (Bound active-memory recall latency and jitter QMD startup). It is draft/conflicting and ClawSweeper flagged a P1 timeout regression/no real behavior proof, so it does not currently appear to be a ready fix for this report.

What would help validate a fix

A good fix/proof should ideally capture before/after values for:

• RSS, heapUsed, external, arrayBuffers, active handles, and task pressure before and after idle;
• Active Memory enabled vs disabled in the same Telegram topic;
• queryMode: message, recent, and ideally full if safe;
• whether configured timeoutMs vs setupGraceTimeoutMs behavior is intentional or accidentally doubling the user-visible timeout;
• whether transient Active Memory subagent/codex/session resources are released after timeout and after successful no-memory recall.