Codex app-server stores (codex-home) grow unbounded — no retention, 97% image payloads

Summary

Codex app-server stores under agents/<id>/agent/codex-home/ grow without bound and have no retention mechanism. On this install they reached 13 GB across 14 agents in roughly two weeks, growing ~400 MB/day. About 97% of the volume is image payloads (browser-automation screenshots and generated images) embedded in thread history and logs.

session.maintenance — including coldStorage, pruneAfter and maxDiskBytes — does not cover these files. Per the docs it manages "SQLite session rows, SQLite transcript rows, archive artifacts, and trajectory sidecars" for OpenClaw's own session store, which on this install is only 0.6 GB. The 13 GB sits entirely outside its reach.

Environment

• OpenClaw 2026.9.4, Node 26.8.1, macOS 27.0 (Mac mini M4)
• 14 agents, Codex runtime via ChatGPT OAuth
• One agent (lyra) runs a daily browser-automation task (Google Flow) and accounts for 5.2 GB alone

Measurements

agents/lyra/agent/codex-home/thread_history_1.sqlite — 711 MB:

item_type	count	size
userMessage	889	594 MB
imageGeneration	31	88 MB
commandExecution	1567	12 MB
dynamicToolCall	1682	5 MB
reasoning	3589	~0 MB

512 of the 889 userMessage items contain image data. Average item is 685 KB, largest is 4 MB. For contrast, 3589 reasoning blocks take almost no space — text is negligible.

agents/lyra/agent/codex-home/logs_2.sqlite — 778 MB, 175,424 rows:

target	rows	size
codex_core::session::handlers	1,914	603 MB
everything else	173,510	~61 MB

751 of those 1,914 rows contain image, 220 contain base64. Largest single log row is 5 MB.

Why age-based pruning does not help

No row in logs_2 is older than 14 days — the oldest is 10 days old. The database is large because of payload size, not history depth. Pruning by age would reclaim little and the size returns within a week.

What appears to be missing

1. No retention policy for codex-home stores. session.maintenance does not reach them, and no separate setting was found in the docs or in the runtime.
2. Image payloads are stored inline and kept indefinitely. OpenClaw's own compaction already treats images as droppable — it substitutes [image data omitted from summary input] when summarizing. The same idea does not seem to apply to what is persisted on disk.
3. Logging persists full payloads. A single log row reaching 5 MB suggests image data is written into codex_core::session::handlers records, not just referenced.

Suggestions

• A retention/size policy for codex-home equivalent to session.maintenance (age, disk budget, or both).
• Strip or externalize image payloads from inactive thread items once the session is no longer live, keeping a marker — the same treatment compaction already applies.
• Cap or elide large binary payloads in log records.

Happy to provide additional measurements from this install, or to test a fix.