openclaw - 💡(How to fix) Fix Context overflow during tool loop resets session instead of triggering compaction rescue [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When a long-lived OpenClaw session overflows context during a tool loop, the runtime resets the session and remaps the conversation to a new session instead of attempting a compaction rescue. The preflight compaction path exists, but this overflow path appears to bypass it entirely.

Steps to reproduce

1. Start a long-lived tool-enabled OpenClaw chat session.
2. Let the session grow large enough that it is near the model context limit.
3. Trigger a multi-step tool flow so the run enters a tool loop.
4. Observe an overflow in the middle of the run rather than before the run starts.
5. Send the next user message in the same conversation.

This has been observed across multiple chat channels, so it appears to live in shared embedded agent/session runner logic rather than a single channel integration.

Expected behavior

If the session is too large, OpenClaw should either:

• trigger a compaction rescue before resetting the session, or
• gracefully compact and continue/retry the run, instead of silently replacing the active chat mapping with a fresh session.

At minimum, compaction should be attempted on this overflow path when safe to do so, or the user-facing continuity break should be made explicit.

Actual behavior

The session overflowed during a tool loop and was reset immediately. The next inbound message in the same conversation started a brand new session, which lost the prior conversational context from the active transcript.

Evidence from local runtime/log inspection:

• Runtime log reported: Context overflow: estimated context size exceeds safe threshold during tool loop.
• Same log line reported compactionAttempts=0.
• The old session transcript was archived as a .jsonl.reset.<timestamp> file.
• A new session was created for the same conversation a few seconds later.

From inspecting the built runtime code, runPreflightCompactionIfNeeded(...) is called before the embedded run starts, but the overflow path later calls resetSessionAfterCompactionFailure(...) on context overflow instead of attempting a rescue compaction in that branch.

OpenClaw version

2026.4.23

Operating system

Linux 6.6.87.2-microsoft-standard-WSL2 (x64) under WSL2

Install method

npm global install

Model

gpt-5.4

Provider / routing chain

openai-codex / openai-codex-responses

Additional provider/model setup details

Embedded agent runtime, tool-enabled session, local gateway service running. This behavior has been observed on multiple chat channels (including Zalo and Discord), which suggests the implicated code path is shared embedded-agent runtime/session logic rather than transport-specific logic.

Logs, screenshots, and evidence

Local evidence:
- `openclaw logs` showed: `Context overflow: estimated context size exceeds safe threshold during tool loop.`
- The same diagnostic included `compactionAttempts=0`.
- The overflowing session transcript was archived as a `.jsonl.reset.<timestamp>` file.
- A replacement session began seconds later for the same conversation/session key.

Relevant built runtime observations from local install (`dist/agent-runner.runtime-*.js`):
- `runPreflightCompactionIfNeeded(...)` is invoked before `runEmbeddedPiAgent(...)`.
- On overflow, code reaches a branch that calls `resetSessionAfterCompactionFailure(...)` and returns a reset/fresh-start message.
- I did not find an equivalent rescue-compaction attempt in the `during tool loop` overflow branch.

If helpful, I can provide fuller log excerpts and exact local code line references.

Impact and severity

High impact for long-lived chat sessions. It causes an unexpected continuity break, makes the user think a new session started by itself, and can discard immediately relevant conversational context right when the agent is in the middle of a complex task.

Additional information

This may be either:

1. a bug where overflow during tool loop should still trigger a compaction rescue path, or
2. a design limitation where only preflight compaction exists today.

Either way, the current behavior is surprising because users reasonably expect the advertised compaction mechanism to protect them from exactly this kind of large-session failure.

I intentionally describe this as a shared runtime/session behavior rather than a channel-specific bug, because it has been observed outside a single transport integration.