Summary
After ~13 hours of continuous operation, the openclaw-gateway process reaches 69.9% CPU and 1.9GB RSS (VmSize 24GB), becoming effectively stuck. The process remains functional (delivers Slack messages) but consumes excessive resources.
Environment
- OpenClaw version:
2026.2.3-1
- OS: Amazon Linux 2023 (t3.medium, 4GB RAM)
- Node.js: v22.**
- Channel: Slack
- Model: Bedrock Claude Opus 4.6
Reproduction Steps
- Run gateway for extended period (12+ hours) with active tool use (exec sessions, Claude Code child processes)
- Trigger conditions that cause LLM request timeouts (600s timeout, occurred 7 times in this incident)
- Have exec tool failures (e.g.,
git checkout failing due to uncommitted changes)
- Observe CPU gradually climbing and never recovering
Timeline of Events
| Elapsed |
Event |
| T+0h |
Gateway running normally |
| T+1h |
ImportError in exec (child process) |
| T+1.5h |
First LLM timeout (600s) — embedded run timeout |
| T+1.5h |
Second LLM timeout (600s) — 2 lane errors |
| T+2h |
git checkout exec failure (uncommitted changes block checkout) |
| T+2.25h |
Third LLM timeout (600s) — 2 lane errors |
| T+2.25h+ |
Gateway continues operating but CPU stuck at ~70% |
| T+13h |
Still at 69.9% CPU, 563min CPU time, 1.9GB RSS |
Observed Behavior
ELAPSED 13:26:42 | CPU 69.9% | RSS 1.9GB | VmSize 24GB | Threads 12
- Gateway still delivers Slack messages (not a total hang)
- High CPU suggests V8 GC thrashing due to memory pressure
- No automatic recovery mechanism
- Child
claude process (Claude Code CLI) runs under the gateway tree
Expected Behavior
- Gateway should have memory limits / self-monitoring
- After LLM timeouts, resources should be properly freed
- Failed exec sessions should be cleaned up (no dangling state)
- Consider: automatic restart when RSS exceeds a configurable threshold
Possible Root Causes
- Memory leak on LLM timeout paths — 600s timeout fires, but request context / conversation history may not be fully GC'd
- Exec session cleanup — failed exec (git checkout error) may leave internal state that prevents cleanup
- No
--max-old-space-size limit — Node.js defaults to ~4GB heap on 64-bit, allowing unbounded growth
- Long-running conversation context accumulation — 13 hours of active sessions without compaction
Suggested Improvements
- Set
--max-old-space-size (e.g., 1536MB) to bound heap growth
- Add periodic memory self-check — if RSS > threshold, log warning or trigger graceful restart
- Ensure LLM timeout error paths properly release conversation buffers
- Add exec session reaping for sessions in error state
Logs
[diagnostic] lane task error: lane=main durationMs=600463 error="FailoverError: LLM request timed out."
[tools] exec failed: error: Your local changes to the following files would be overwritten by checkout:
[agent/embedded] embedded run timeout: timeoutMs=600000
Summary
After ~13 hours of continuous operation, the openclaw-gateway process reaches 69.9% CPU and 1.9GB RSS (VmSize 24GB), becoming effectively stuck. The process remains functional (delivers Slack messages) but consumes excessive resources.
Environment
2026.2.3-1Reproduction Steps
git checkoutfailing due to uncommitted changes)Timeline of Events
git checkoutexec failure (uncommitted changes block checkout)Observed Behavior
claudeprocess (Claude Code CLI) runs under the gateway treeExpected Behavior
Possible Root Causes
--max-old-space-sizelimit — Node.js defaults to ~4GB heap on 64-bit, allowing unbounded growthSuggested Improvements
--max-old-space-size(e.g., 1536MB) to bound heap growthLogs