Summary

Compaction timeouts are still occurring in 2026.3.2 with openai-codex/gpt-5.3-codex, and this affects both:

1. manual /compact, and
2. automatic compaction during normal runs.

When this happens, the active session lane can stall for a long time and the user experiences the chat as frozen/unresponsive mid-stream.

Environment

• OpenClaw: 2026.3.2 (stable)
• OS: macOS arm64
• Channel: webchat/direct
• Model: openai-codex/gpt-5.3-codex
• Compaction config:
  • mode: default
  • reserveTokensFloor: 80000
  • maxHistoryShare: 0.65

Expected behavior

• Manual and automatic compaction should complete reliably.
• If compaction fails/times out, the session lane should recover quickly and not appear frozen.
• Timeout handling should not leave users blocked from continuing work.

Actual behavior

• Manual compaction repeatedly fails at roughly 300s.
• Automatic compaction path also times out in real runs (snapshot fallback log).
• After failures, lane wait diagnostics spike and chat can feel blocked/frozen.

Evidence (local logs)

Manual compaction timeout (~300s, repeated)

From ~/.openclaw/logs/gateway.err.log:

2026-03-06T17:32:42.621Z [agent/embedded] [compaction-diag] end runId=eb2e04a1-bbb9-48fd-a2c5-9cf9d2e10ac6 sessionKey=agent:main:main diagId=cmp-mmf63nnu-d3j_cQ trigger=manual provider=openai-codex/gpt-5.3-codex attempt=1 maxAttempts=1 outcome=failed reason=timeout durationMs=300137

2026-03-05T17:24:27.938Z [agent/embedded] [compaction-diag] end runId=agent:main:main sessionKey=agent:main:main diagId=cmp-mmdqd74r-6PXaew trigger=manual provider=openai-codex/gpt-5.3-codex attempt=1 maxAttempts=1 outcome=failed reason=timeout durationMs=300351

2026-03-05T17:36:14.915Z [agent/embedded] [compaction-diag] end runId=agent:main:main sessionKey=agent:main:main diagId=cmp-mmdqscmj-waa2Ig trigger=manual provider=openai-codex/gpt-5.3-codex attempt=1 maxAttempts=1 outcome=failed reason=timeout durationMs=300370

Automatic compaction timeout path (non-manual)

2026-02-25T18:40:57.463Z [agent/embedded] embedded run timeout: runId=b9d12834-cd72-4174-bc1f-6eeed38649a0 sessionId=9145b958-0602-44fa-a2fd-0873066c166e timeoutMs=600000
2026-02-25T18:40:57.470Z [agent/embedded] using current snapshot: timed out during compaction runId=b9d12834-cd72-4174-bc1f-6eeed38649a0 sessionId=9145b958-0602-44fa-a2fd-0873066c166e

Lane stall symptoms around failures

2026-03-05T17:24:27.950Z [diagnostic] lane wait exceeded: lane=session:agent:main:main waitedMs=300315 queueAhead=1
2026-03-05T17:36:14.925Z [diagnostic] lane wait exceeded: lane=session:agent:main:main waitedMs=470918 queueAhead=2
2026-03-06T17:32:42.633Z [diagnostic] lane wait exceeded: lane=session:agent:main:main waitedMs=104743 queueAhead=0

Impact

High user impact. If compaction fails mid-session, conversation can effectively freeze and block ongoing work.

Related issues

Likely related (same failure family):

• fix(pi-embedded): compaction retry blocks session lane + restart collision #17444
• [Bug]: Compaction does not auto-trigger reliably and fails under 5min JS timeout with slow local models #27595
• Compaction timeout races against channel timeout, causing stale-response loop #25272
• [Bug]: /compact intermittently does nothing in TUI; logs show compaction wait aborted #30116

This report adds fresh evidence on 2026.3.2 + codex provider and confirms both manual and automatic compaction paths are affected.

Suggested direction

• Make compaction timeout configurable (and/or increase default).
• Ensure timeout/abort path releases session lane quickly.
• Add stronger circuit-breaker behavior after repeated compaction timeout failures to avoid user-facing freeze loops.