Restart the container on the same image and the Gateway takes about ten minutes to become healthy, roughly seven and a half of them spent writing a copy of the state. That copy lands under the state directory's update-captures/ and is kept for 30 days. On a large install the report behind openclaw/openclaw#173564 measured about 11 GB per restart, so a host that restarts daily accumulates hundreds of gigabytes of captures it will never read.
Why it happens
The image entrypoint runs doctor --fix before every Gateway start, which is deliberate - it is what repairs a torn state after an update. But standalone doctor takes a full pre-repair capture of every local SQLite store before it changes anything, every time it runs, even when the repair pass finds nothing to do. A restart is not an update, so the same stores get copied again on every boot and each copy ages out independently.
The fix
PR #173711 makes the first successful capture in a container the only full copy. Later starts still run the repair pass but skip the repeated full copy and keep the container's existing capture; a failed capture retries on the next start. Repair-specific backups such as schema migrations and rewritten databases are untouched, and manual doctor --fix and update-time doctor still capture as before.
Until that reaches your image, prune update-captures/ on a schedule the same way you would any other diagnostic dump, and treat slow container startup as capture time rather than repair time. The lesson generalises to any repair or migration tool wired into a boot path - if it snapshots state before it decides whether anything needs fixing, every restart becomes a backup whether or not there is anything to back up. Gate the capture on the repair being necessary, not on the tool being invoked.