openclaw - 💡(How to fix) Fix Codex runtime compaction refresh lacks normal user-visible/logged notification parity [1 comments, 2 participants]

Summary

When a Discord session using the native Codex runtime compacts, the session receives the internal post-compaction refresh, but OpenClaw does not appear to emit the normal user-visible/logged compaction notification path that users see with the Pi/embedded runtime.

In our test, compaction definitely happened, but there was no visible alert in Discord and no recent gateway log line like:

[agent/embedded] auto-compaction succeeded ... retrying prompt

Environment

• OpenClaw: 2026.5.18 (50a2481) from /status
• Host: macOS arm64
• Channel: Discord
• Session runtime under test: Codex runtime / native Codex app-server path
• Session model/provider under test: openai-codex/gpt-5.4
• Session key: agent:main:discord:channel:1502053546194108416
• Session id: 1fd724b3-0892-44f7-bf4b-d6b2eee0839a

What happened

We intentionally overloaded a Discord #random session running on Codex runtime to trigger compaction.

The session transcript/trajectory shows an internal post-compaction refresh was injected:

System: [2026-05-18 22:20:02 EDT] [Post-compaction context refresh]
System: Session was just compacted. The conversation summary above is a hint, NOT a substitute for your startup sequence...

So compaction occurred and the session continued.

However, the user did not get the normal compaction alert/notification they are used to seeing, and checking the gateway log did not show the usual recent Pi/embedded log line:

[agent/embedded] auto-compaction succeeded for ...; retrying prompt

Older Pi/embedded compactions do show many lines like that in gateway.log, but this Codex runtime compaction did not seem to hit the same observability/notification path.

Expected behavior

Codex-runtime compaction should have parity with Pi/embedded compaction observability, at least one of:

• user-visible Discord/channel notification that compaction happened, and/or
• /status compaction count update, and/or
• gateway log line indicating compaction succeeded and the prompt/session was refreshed.

Users rely on this signal to know why context changed and to verify that compaction happened cleanly.

Actual behavior

• Compaction happened.
• Session got an internal post-compaction refresh.
• Session continued successfully.
• User-visible compaction notification was missing.
• Normal recent gateway compaction log line was missing.

Related issues / likely area

This looks adjacent to existing ownsCompaction / plugin-context-engine parity issues:

• #49380 — plugin context engines cannot increment /status compaction count
• #77561 — ownsCompaction Codex sessions have different mid-turn compaction protection behavior
• #46641 — user-facing notification before auto-compaction, closed, but related UX/observability concern

This issue is narrower: Codex runtime compaction refresh happened, but did not surface the same user-visible/logged notification/status parity as Pi/embedded compaction.

Impact

Low-to-medium severity. It did not break the session, but it makes Codex runtime compaction feel silent/opaque compared with Pi. For long-running Discord work, the user cannot easily tell that compaction happened unless they inspect session internals.