Summary

On a long-running OpenClaw installation, openclaw gateway can enter a sustained high-CPU state during task registry maintenance when ~/.openclaw/tasks/runs.sqlite* contains stale task/session entries.

In my case the gateway was technically live, but it consumed most of one CPU core for many minutes and made the machine feel very sluggish. Rebuilding only the task registry database fixed the issue.

Environment

• OpenClaw: 2026.4.25 (aa36ee6)
• Install method: npm global install
• Runtime: Node v25.9.0, npm 11.12.1
• OS: Arch Linux systemd user service
• Gateway service: openclaw-gateway.service
• Model configured: openai-codex/gpt-5.5

Actual behavior

After starting the gateway, the process became live but continued burning CPU:

openclaw-gateway.service active (running)
MainPID=openclaw-gateway
CPU: ~90-105% of one core for several minutes
RSS: commonly ~700-1000 MB during the bad state
/health: sometimes live, but CLI/gateway calls could time out while the box was saturated

Representative samples before the fix:

pid_cpu_pct_30s=100.37 rss_kb=768xxx
pid_cpu_pct_25s=100.40 rss_kb=758xxx
pid_cpu_pct_25s=64.72  rss_kb=710xxx

The process log around startup looked normal enough, so this was not obvious from logs alone:

[gateway] ready (1 plugin: memory-core; ...)
[gateway] starting channels and sidecars...
[agents/auth-profiles] kept local oauth over external cli bootstrap-only provider
[codex/catalog] codex model discovery failed; using fallback catalog
[model-pricing] ... timeout
[heartbeat] started
[plugins] [hooks] running gateway_start (1 handlers)

CPU profile evidence

A Node CPU profile pointed to task registry maintenance repeatedly loading/cloning session state while checking stale tasks:

runTaskRegistryMaintenance
  -> shouldMarkLost
  -> hasBackingSession
  -> loadSessionStore
  -> readSessionStoreCache
  -> structuredClone

Another hot stack from the same profile:

shouldMarkLost
  -> hasBackingSession
  -> deriveSessionChatType
  -> iterateBootstrapChannelPlugins
  -> getBootstrapChannelPlugin
  -> resolveActiveBootstrapPlugins
  -> resolveBundledChannelRootScope
  -> resolveBundledPluginsDir
  -> resolveOpenClawPackageRootSync
  -> findPackageRootSync
  -> readPackageNameSync
  -> parsePackageName

Top self samples included:

16.2% structuredClone node:internal/worker/js_transferable
14.1% parsePackageName .../openclaw-root-*.js
 2.5% readFileSync node:fs
 1.5% readFileUtf8

The relevant task DB files before the workaround were:

~/.openclaw/tasks/runs.sqlite      1740800 bytes
~/.openclaw/tasks/runs.sqlite-wal  4152992 bytes
~/.openclaw/tasks/runs.sqlite-shm    32768 bytes

Things I ruled out

I tested these independently and they were not the root cause:

• models.json cache regeneration
• Feishu / Lark channel startup
• custom model provider definitions and fallbacks
• multiple openai-codex auth profiles
• the production workspace directory
• extension discovery warnings from a separate claworld plugin manifest
• ~/.openclaw/plugins/installs.json
• internal hooks config

For example, a temp HOME using the same OpenClaw version, same Codex credentials, same OpenClaw auth profiles, and even the same production workspace idled normally after startup. The high CPU reproduced only with the production task registry DB in place.

Workaround that fixed it

Stopping the gateway, moving the task registry DB aside, and letting OpenClaw recreate it fixed the high CPU:

systemctl --user stop openclaw-gateway.service

mkdir -p ~/.openclaw/_disabled_task_registry/$(date +%Y%m%d-%H%M%S)
mv ~/.openclaw/tasks/runs.sqlite     ~/.openclaw/tasks/runs.sqlite.disabled-YYYYMMDD-HHMMSS
mv ~/.openclaw/tasks/runs.sqlite-shm ~/.openclaw/tasks/runs.sqlite-shm.disabled-YYYYMMDD-HHMMSS
mv ~/.openclaw/tasks/runs.sqlite-wal ~/.openclaw/tasks/runs.sqlite-wal.disabled-YYYYMMDD-HHMMSS

systemctl --user restart openclaw-gateway.service

After OpenClaw rebuilt the DB:

/health: {"ok":true,"status":"live"}
gateway inference with openai-codex/gpt-5.5: returned OK
idle CPU sample after warmup: 0.77% over 30s

With the full original config restored, keeping only the regenerated task registry DB, the gateway also idled correctly:

pid_cpu_pct_25s=0.00 rss_kb=524804

Expected behavior

Task registry maintenance should not be able to keep the gateway in a sustained hot loop because of stale/corrupt/large historical run data.

Possible mitigations:

• avoid reloading or structuredCloneing the full session store for each task being checked
• cache session-store lookups during a maintenance pass
• batch/limit maintenance work per tick
• detect pathological or corrupt task registries and quarantine/rebuild them automatically
• log a clear warning when maintenance is skipping or quarantining stale task registry data

I did not attach the old runs.sqlite because it may contain private run/session metadata, but I can provide schema/counts or more sanitized profile details if useful.