openclaw - 💡(How to fix) Fix Codex runtime allows >2M-token turns with compactionCount=0, then contextEngine maintenance fails [1 comments, 2 participants]

Summary

On OpenClaw 2026.5.18, the Codex/OpenAI runtime accepted and completed multiple turns whose reported usage was well above the configured/model context window (1.0m), while compactionCount remained 0. After the session was reset with /new, a later turn again reported 2.36m total tokens and was followed by a user-visible gateway notice: ⚠️ 🔌 Gateway: contextEngine failed.

This looks like a runtime/context accounting + preflight guard failure first, with lossless-claw context-engine maintenance failing downstream after the session state is already poisoned/oversized.

Environment

• OpenClaw: 2026.5.18 (50a2481 shown in /status; trajectory metadata gitSha 6490b12)
• Host: macOS 26.3.1 arm64, Node v25.8.0
• Runtime/model: openai-codex/gpt-5.5, API openai-codex-responses
• Session key: agent:main:main
• Context window reported by status/session store: 1,000,000
• Context engine: lossless-claw via plugins.slots.contextEngine
• lossless-claw package: @martian-engineering/lossless-claw 0.11.1
• Relevant lossless config:
  • contextThreshold: 0.7
  • maxAssemblyTokenBudget: 600000
  • proactiveThresholdCompactionMode: inline
  • freshTailCount: 32
  • freshTailMaxTokens: 16000

What happened

1. Session appeared safe, then crossed into over-window state

At ~13:54 EDT, /status showed:

Tokens: 219k in / 9 out
Context: 262k/1.0m (26%)
Compactions: 0

At ~13:56 EDT, the next replies failed repeatedly with:

Your input exceeds the context window of this model. Please adjust your input and try again.

A subsequent /status showed:

Tokens: 2.6m in / 2.1k out
Context: 2.6m/1.0m (256%)
Compactions: 0
Tasks: recently finished · acp · Context engine turn maintenance · No transcript changes were needed.

/compact/maintenance did not rescue the session; the user had to start a new session (/new).

2. Trajectory evidence before the reset

Old session id:

6b131bf3-07b2-476d-8495-8eb6f2420b39

Relevant trajectory file:

~/.openclaw/agents/main/sessions/6b131bf3-07b2-476d-8495-8eb6f2420b39.trajectory.jsonl

The problematic user-visible turn completed at 2026-05-19T17:55:54Z (13:55:54 EDT):

{
  "type": "model.completed",
  "ts": "2026-05-19T17:55:54.215Z",
  "runId": "8c38b28a-78a7-440b-9fa0-44ee6de3ec7d",
  "usage": {
    "input": 2553826,
    "output": 2102,
    "cacheRead": 816000,
    "total": 3371928
  },
  "compactionCount": 0
}

The trace artifact for the same run reports success:

{
  "type": "trace.artifacts",
  "ts": "2026-05-19T17:55:54.226Z",
  "runId": "8c38b28a-78a7-440b-9fa0-44ee6de3ec7d",
  "finalStatus": "success",
  "usage": {
    "input": 2553826,
    "output": 2102,
    "cacheRead": 816000,
    "total": 3371928
  },
  "compactionCount": 0
}

Immediately afterward, small follow-up messages entered error state. Example:

{
  "type": "trace.artifacts",
  "ts": "2026-05-19T17:56:21.716Z",
  "runId": "9686786e-9cb9-4da5-aa08-8da4d2961ab1",
  "finalStatus": "error",
  "compactionCount": 0,
  "assistantTexts": []
}

OpenClaw then created a manual checkpoint/reset:

{
  "checkpointId": "fb3a6a9d-b13c-4f8d-a358-690abf95f593",
  "sessionKey": "agent:main:main",
  "sessionId": "6b131bf3-07b2-476d-8495-8eb6f2420b39",
  "reason": "manual",
  "tokensBefore": 353263,
  "tokensAfter": 21620
}

Notably, the active session entry later still had:

{
  "compactionCount": 0,
  "compactionCheckpoints": ["...manual checkpoint above..."]
}

3. New session still produced multi-million-token turns

New active session id:

64897db5-2b83-4669-8b47-5c35fdaa618c

Relevant trajectory file:

~/.openclaw/agents/main/sessions/64897db5-2b83-4669-8b47-5c35fdaa618c.trajectory.jsonl

At 2026-05-19T18:30:48Z (14:30:48 EDT), another turn completed successfully with over-window usage:

{
  "type": "model.completed",
  "ts": "2026-05-19T18:30:48.849Z",
  "runId": "f28368bc-b57c-4635-a413-268028caf8ee",
  "usage": {
    "input": 1034030,
    "output": 4812,
    "cacheRead": 1324672,
    "total": 2363514
  },
  "compactionCount": 0
}

The corresponding artifact also reports success:

{
  "type": "trace.artifacts",
  "ts": "2026-05-19T18:30:48.862Z",
  "runId": "f28368bc-b57c-4635-a413-268028caf8ee",
  "finalStatus": "success",
  "usage": {
    "input": 1034030,
    "output": 4812,
    "cacheRead": 1324672,
    "total": 2363514
  },
  "compactionCount": 0
}

Around this time the Telegram user saw:

⚠️ 🔌 Gateway: contextEngine failed

Gateway log also shows context engine maintenance being queued immediately after the turn:

2026-05-19T14:30:48.847-04:00 [agent/embedded] [context-engine] deferred turn maintenance queued taskId=a2e0c6f0-3aaf-4426-a8ea-5e6dde9ddd09 sessionKey=agent:main:main lane=context-engine-turn-maintenance:agent:main:main

Why this seems OpenClaw-side first

The context engine may be the component that visibly failed at 14:30, but the more dangerous invariant failure happened before that:

1. Runtime/status/model usage reported totals far above the model window (2.36m and 3.37m vs 1.0m).
2. These runs were accepted/completed as successful instead of being preflight-blocked, compacted, or hard-reset.
3. compactionCount remained 0 throughout.
4. Manual checkpoint accounting exists (compactionCheckpoints) but compactionCount still remained 0 on the active session entry.
5. The later contextEngine failed appears to be downstream maintenance reacting to an already oversized/poisoned session state.

Expected behavior

OpenClaw should enforce at least one of these before model dispatch / immediately after usage accounting detects the issue:

• If projected prompt or observed usage exceeds the model context window, do not continue normal dispatch loop.
• Trigger compaction/preflight if possible.
• If compaction cannot reduce context, hard reset/rotate the session with a clear local diagnostic instead of repeatedly sending over-window prompts.
• Ensure compactionCount/checkpoint accounting is coherent: a session entry should not show checkpoints while compactionCount remains 0 if that field gates future compaction behavior.
• If context-engine maintenance fails after an over-window turn, surface the actual context-engine error/stack somewhere accessible, not only Gateway: contextEngine failed.

Actual behavior

• Multiple successful turns reported total usage from 1.3m to 3.37m tokens on a 1.0m model/session.
• compactionCount stayed 0.
• Follow-up turns began failing with Your input exceeds the context window of this model.
• /status reached 2.6m/1.0m (256%) with Compactions: 0.
• User-visible gateway notice later said Gateway: contextEngine failed after a successful 2.36m token turn.

Related issues / possible overlap

This appears related to, but not fully covered by:

• #63892 / #65600 / #66716 — preflight compaction and fresh token totals
• #80765 — Codex context-engine projection lacks exact pre-turn accounting
• #84218 — context-engine replay/overflow loops

This report adds a concrete production trace where openai-codex/gpt-5.5 turns report >2M usage on a 1M context session, compactionCount remains 0, and the lossless context engine fails downstream.