Summary

In an OpenClaw workspace, a codex/gpt-5.4 session can enter a dirty path where context / usage shows anomalous unbounded inflation across otherwise trivial follow-up turns.

The trigger is not just “many turns”. A clean control stays stable. The problem shows up after a workspace/bootstrap-heavy turn, and it becomes even more user-visible when approval / interruption is involved.

I am intentionally not reporting a specific large UI number here. The core problem is that context / usage accounting does not appear to converge back down after the dirty bootstrap turn, and the session can also feel pseudo-hung.

Environment

• OpenClaw 2026.4.11
• Linux host
• OpenClaw workspace with standard bootstrap/reference files (SOUL.md, USER.md, MEMORY.md, daily memory note, SHARED_GOVERNANCE.md)
• codex/gpt-5.4

Reproduction

Clean control

1. Start a Codex session from the OpenClaw workspace.
2. Send 15 tiny turns of the form Reply exactly: ....
3. Observe that per-turn usage stays roughly stable.

Dirty path

1. Start a fresh Codex session from the same OpenClaw workspace.
2. First turn: ask it to read the standard workspace/bootstrap files:
   • SOUL.md
   • USER.md
   • MEMORY.md
   • memory/2026-04-12.md
   • /home/bruce/.openclaw/SHARED_GOVERNANCE.md
3. Then send many tiny follow-up turns of the form Reply exactly: ....
4. Observe that the session does not settle back near the clean control. Instead, usage remains much heavier turn after turn and the cumulative session total keeps growing monotonically.

Approval / interruption variant

Using a workspace-write / approval-on-request style path makes the same area worse:

• deny or interrupt one of the file-read approvals
• continue the session with trivial follow-up turns

This can additionally produce:

• Conversation interrupted
• retry / elevate loops
• pasted-input concatenation / scrambled follow-up input
• a strong user-facing “it froze / hung” feeling even when the session is not technically dead

Expected behavior

• A bootstrap-heavy first turn may be more expensive once, but subsequent tiny turns should settle back near the clean baseline, or at least remain bounded by the effective live context.
• Approval denial / interruption should not leave the session in a pseudo-hung or input-corrupted state.

Actual behavior

• Clean path stays stable.
• Dirty path roughly doubles the per-turn weight and then keeps that higher weight across trivial follow-up turns instead of converging.
• Context / usage exhibits anomalous unbounded inflation from the user side instead of settling back toward the clean baseline.
• Approval/interruption can make the session feel hung and can leave the TUI in a messy continuation state.

Notes / comparative evidence

• In the same general workspace, a clean micro-turn control stayed around a much smaller steady baseline.
• A dirty-path Codex run stayed on a much heavier steady state across many trivial turns.
• A parallel openai-codex/gpt-5.4 session in OpenClaw showed a much more bounded effective context, which suggests this may be specific to the Codex path and/or to how OpenClaw workspace bootstrap + approval/interruption interacts with it.

Why I think this is worth filing here

This may involve upstream Codex behavior, but OpenClaw seems like the right first triage point because the effect is easy to trigger around:

• OpenClaw workspace bootstrap conventions
• OpenClaw Codex integration / app-server boundary
• approval bridge / interruption handling
• usage / context observability

If useful, I can provide the exact local transcripts and turn-by-turn usage samples from the control vs dirty-path runs.