OpenClaw 2026.7.2-beta.5 Can Exhaust Gateway Memory When Usage Opens on Large Session Histories

OpenClaw has merged a fix for a Gateway out-of-memory failure in 2026.7.2-beta.5. The upstream reproduction involved opening Control UI Usage/Profile with hundreds of sessions: each cached usage-rollup row embedded a full pricing-catalog fingerprint of roughly 2.6 MB, and the reader materialized all rows at once.

The reported case reached about 2.1 GB across 645 session rows before V8 exhausted its heap. This is not ordinary dashboard slowness; opening an observability surface can take down the Gateway it is meant to inspect.

The fix merged to main at 18:27 UTC on 28 July, well after beta.5 was published. The beta package therefore does not contain the fix merely because the commit now exists upstream.

The operator decision

Do not “solve” this by raising the V8 heap indefinitely. More heap may delay failure while the old rollup layout continues to multiply a large payload by session count.

Why the rollups became explosive

Usage rollups cache per-session accounting so the UI does not have to reconstruct every historical turn. The faulty v1 design stored the complete pricing fingerprint inside every cache_entries row.

That creates multiplicative growth:

• the fingerprint was approximately 2.6 MB;
• each retained session could receive another copy; and
• the SQLite reader used an eager .all() path, putting the selected rows into memory together.

The reported 645-session example therefore produced roughly 2.1 GB of cached row data. SQLite was not the limiting abstraction here: compact source data had been expanded into repeated multi-megabyte values, then loaded eagerly into V8.

What the merged fix changes

Commit 1dd1dc1 replaces the embedded catalog payload with a SHA-256 pricing fingerprint, moves new rollups to a v2 scope, and adds retirement of the bloated v1 scope. The commit also describes:

• pruning v1 rows by scope;
• a doctor --fix cleanup path; and
• one scoped rollup read per agent during refresh.

Interpretation: hashing is appropriate because the rollup needs a stable identity for the pricing inputs, not hundreds of independent copies of the complete catalog. Changing the scope keeps the compact format separate from already persisted v1 rows.

Safe recovery and acceptance

For an affected Gateway:

1. Stop triggering the eager read. Do not keep reopening Usage/Profile to see whether memory has improved.
2. Capture non-sensitive evidence. Record the exact OpenClaw version, session count, process exit reason and heap/OOM log without publishing transcripts or pricing credentials.
3. Back up the complete state boundary. Preserve the SQLite database and active sidecars using a consistent procedure before cleanup or upgrade.
4. Adopt a confirmed containing build. A merge to main is not a package release; check the release notes or exact source SHA.
5. Use the supported repair path. On the containing build, follow its documented doctor --fix workflow rather than deleting arbitrary SQLite rows by hand.
6. Re-test at realistic scale. Open Usage with a copy of the actual session population while watching Gateway resident memory, response time and restart behaviour.
7. Prove ordinary operations still work. Verify chat, schedules, channels and session access after repair and another clean restart.

Do not delete sessions as a first response unless your retention policy already permits it and you have established that they are recoverable. The merged fix is designed to retire the duplicated rollup cache, not require loss of canonical history.

Evidence and limits

The upstream PR attributes the failure to OpenClaw 2026.7.2-beta.5 and reports the 645-row, roughly 2.1 GB reproduction. OpenClaw Academy reviewed the official merged-PR and commit records supplied by the OpenClaw repository collector. Our independent web retrieval was unavailable during verification, and we did not reproduce the heap failure or run Doctor against an affected database. Runtime measurements and implementation claims are attributed to upstream; the containment and acceptance procedure is our operator guidance.

Bottom line

If beta.5 has accumulated hundreds of sessions, its Usage/Profile view can be an outage trigger rather than a safe diagnostic. Avoid that path, preserve state, and move to a release or exact revision that explicitly contains 1dd1dc1; then clean v1 rollups through the supported Doctor workflow and test with production-scale history.