openclaw - 💡(How to fix) Fix [Bug]: Codex app-server client closes mid-turn during image/tool requests with large logs_2.sqlite

Summary

Codex/OpenClaw turns can stop mid-flight with the UI showing a stopped/aborted state. In the observed case, an image-generation request from Discord never reached a durable image_generate task and the user saw no attachment or completion message.

Local logs show the Codex app-server/stdin client closing before the turn completed. I cannot prove the root cause yet, but the same install has an unusually large Codex trace database (logs_2.sqlite >800 MB), while disk and memory are not exhausted. This may be either the cause or a strong contributing signal.

Environment

• OpenClaw: 2026.5.22
• Runtime: OpenAI Codex via OpenClaw Discord channel session
• Model: openai-codex/gpt-5.5
• Execution: direct
• Observed current context pressure from session_status: 147k/120k (123%), Compactions: 6
• codeModeOnly / code_mode_only: no matching config entry found under .openclaw config search
• No active image task after the failed attempt: image_generate { action: "status" } returned no active image generation task

Observed failure

During an image-generation request from Discord, the user-visible turn stopped before an image task was created or completed. The important local event observed in OpenClaw/Codex logs was:

turn.client_closed
promptError: codex app-server client closed before turn completed

This happened around 2026-05-24T21:40:52Z. The app-server process was observed restarted around 2026-05-24T21:42:36Z, matching the user-visible stopped turn. Subsequent image_generate status showed no active image task, so the failure appears to occur before or around tool dispatch rather than inside the image provider.

Local evidence

Codex trace DB size/counts:

$ du -h ~/.openclaw/agents/main/agent/codex-home/logs_2.sqlite*
832M logs_2.sqlite
20M  logs_2.sqlite-wal
32K  logs_2.sqlite-shm

$ sqlite3 logs_2.sqlite "select count(*) from logs;"
204489

$ sqlite3 logs_2.sqlite "select datetime(min(ts),'unixepoch'), datetime(max(ts),'unixepoch'), count(*), sum(estimated_bytes) from logs;"
2026-05-16 00:19:18|2026-05-24 22:05:26|204901|642484256

Log level distribution:

TRACE|97645
INFO|96696
WARN|7327
DEBUG|3211
ERROR|22

Top log targets:

codex_otel.log_only|47431
codex_otel.trace_safe|47242
codex_api::endpoint::responses_websocket|46622
log|41794
codex_api::sse::responses|7531
codex_core_skills::loader|5548

State DB is much smaller, so this seems specific to trace/log storage rather than all Codex state:

15M  state_5.sqlite
4.1M state_5.sqlite-wal
832M logs_2.sqlite
20M  logs_2.sqlite-wal

Resource checks do not indicate disk or memory exhaustion:

Filesystem: 42T size, 15T used, 28T available, 35% used
Memory: 19Gi total, 6.8Gi used, 12Gi available; swap 13Gi total, 11Gi available

Recent ERROR rows in logs_2.sqlite were only repeated bubblewrap fallback messages, not OOM/disk errors:

Codex could not find bubblewrap on PATH. ... Codex will use the bundled bubblewrap in the meantime.

Closest related issues

These look related but not identical:

• #83109: hardcoded features.code_mode_only=true causing tool-using turns to stall. This install does not appear to have codeModeOnly configured/enabled.
• #84076: Codex app-server stalls after item/completed, then aborts without recovery/status.
• #84400: app-server crash leaves embedded sessions frozen.
• #86019: large context / compaction timeout path; this session also shows context pressure, so it may be related.

Suspected but unproven root cause

The leading suspect is unbounded or overly verbose Codex trace logging causing logs_2.sqlite to grow large enough that app-server/session operations stall or close under load. The failure surfaced during a tool/image turn, but the image provider itself does not appear to be the first failing component because no active image task remained afterward.

A second possible contributing factor is large context/compaction pressure (147k/120k, 6 compactions), but the local symptom was the app-server client closing mid-turn, not a clean compaction failure message.

Reproduction path / diagnostic recipe

I do not have a minimal clean-room repro yet, but this is the closest actionable path from the affected install:

1. Run OpenClaw 2026.5.22 with a Codex Discord channel session using OpenAI Codex runtime.
2. Let the Codex app-server trace DB grow substantially, or artificially exercise verbose tool/image turns until ~/.openclaw/agents/main/agent/codex-home/logs_2.sqlite is hundreds of MB.
3. In a Discord-backed Codex session, request an image generation or another tool-using turn.
4. Watch for the turn to stop/abort before the tool task is durably created or completed.
5. Check:

openclaw --version
openclaw session/status equivalent for context size + compaction count
image_generate status

du -h ~/.openclaw/agents/main/agent/codex-home/logs_2.sqlite*
sqlite3 ~/.openclaw/agents/main/agent/codex-home/logs_2.sqlite 'select count(*) from logs;'
sqlite3 ~/.openclaw/agents/main/agent/codex-home/logs_2.sqlite 'select level, count(*) from logs group by level order by count(*) desc;'
sqlite3 ~/.openclaw/agents/main/agent/codex-home/logs_2.sqlite 'select target, count(*) from logs group by target order by count(*) desc limit 20;'

1. Look in gateway/app-server logs for:

turn.client_closed
codex app-server client closed before turn completed

What would help

• Confirm whether logs_2.sqlite growth is expected to reach hundreds of MB in normal use.
• Confirm whether app-server reads/writes this DB synchronously on hot paths that could stall/kill turns.
• Add log rotation / pruning / vacuuming or size caps if this DB is not meant to grow indefinitely.
• Improve failure surfacing so Discord/image tool users see a clear app-server failure instead of only a stopped turn and no image task.
• If this is actually context/compaction pressure rather than DB size, surface that explicitly in the failed turn and document the recommended recovery.