We've been running OpenClaw for automated code review on our Jenkins pipeline for a few months now. Generally, it's been solid for small to medium PRs. But we've hit a consistent, critical problem: whenever we trigger a build on a large merge (think a feature branch merging back to main after a few weeks, with hundreds of changed files), the OpenClaw process starts eating RAM uncontrollably until it gets OOM-killed by the kernel, taking our entire Jenkins agent pod down with it.
Our agent has a 4GB memory limit. For normal PRs, OpenClaw uses maybe 500MB-1GB. On these large merges, we see it climb to 2GB, then 3GB, and it just doesn't stop. The `docker stats` output looks like this until the container vanishes:
```
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM %
a1b2c3d4e5f6 jenkins-agent-xy 147% 3.8GiB / 4GiB 95%
```
Our OpenClaw config is pretty standard. We're using the `--all-checks` flag and the `--diff-target origin/main` option. The Jenkinsfile step is straightforward:
```groovy
stage('OpenClaw Review') {
agent {
docker { image 'openclaw/cli:latest' }
}
steps {
sh '''
openclaw review
--repo-path .
--diff-target origin/main
--all-checks
--output json > openclaw-report.json
'''
}
}
```
Has anyone else encountered this? I'm curious if it's a known issue with how OpenClaw processes massive diffs—maybe it's trying to load the entire codebase into memory for analysis? I've checked the documentation for memory tuning flags but didn't find anything obvious. We're considering splitting the analysis by file type or directory, but that feels like a workaround.
What's the internal mechanism here? Is it building a huge AST for everything, or perhaps caching previous analyses in memory? Any insights or config tweaks would be really helpful.
grep is my friend.
The `--all-checks` flag on a huge diff is probably loading every rule and file into memory at once. That's your killer.
Try breaking it up. Run OpenClaw per file type or directory chunk in separate steps. Or skip the all-checks and run only the critical ones for the merge gate. You can also adjust the agent's JVM heap settings if OpenClaw is Java based, but the real fix is to not feed it the entire codebase in one go.
Post your actual openclaw command line, the one you truncated. I'll bet there's a `--max-files` or memory flag you aren't using.
Build once, deploy everywhere