openclaw - 💡(How to fix) Fix [Bug]: Large session JSONL can crash gateway during embedded context rebuild; SessionManager.open() loads file twice [1 participants]

Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

A Discord-backed agent:main session with a large JSONL transcript (~80 MB, 9522 lines) can crash the OpenClaw gateway during agent/embedded context rebuilding; code inspection shows SessionManager.open() fully reads and parses the session file twice before buildSessionContext() runs.

Steps to reproduce

1. Run OpenClaw 2026.4.21 on macOS 15.6 with model openai-codex/gpt-5.4.
2. Let a Discord-backed session accumulate a large transcript with many tool results until the session JSONL reaches roughly 80,678,033 bytes, 9522 lines, and max_line_len=662194.
3. Send another message on that session so the embedded agent rebuilds prompt/context for the next run.
4. Observe the gateway log line below from agent/embedded for the large session file.
5. Shortly after the process exits, the next gateway startup logs removed stale session lock: ... (dead-pid) for the same session file.

Expected behavior

The embedded run should complete or return an error without the gateway process exiting. In the observed failure, the session was still being processed when the process died and left a stale session lock for the same session file.

Actual behavior

The gateway process exited during processing of a large session transcript. On the next startup, OpenClaw removed a stale lock for the same session JSONL, which indicates the previous process died while holding that session lock.

OpenClaw version

2026.4.21

Operating system

macOS 15.6 (24G84)

Install method

global npm install at /opt/homebrew/lib/node_modules/openclaw

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw -> openai-codex

Additional provider/model setup details

Observed on a Discord-backed agent:main session. No additional provider routing details were needed to reproduce the crash signature from the available evidence.

Logs, screenshots, and evidence

Observed session file stats:
- size_bytes: 80678033
- lines: 9522
- max_line_len: 662194

Gateway log before the crash path:
- [agent/embedded] [tool-result-truncation] Truncated 2117 tool result(s) in session ... sessionKey=agent:main:discord:channel:<redacted>
- [agent/embedded] [context-overflow-precheck] early tool-result truncation succeeded for openai-codex/gpt-5.4 route=truncate_tool_results_only truncatedCount=2117 estimatedPromptTokens=123814 promptBudgetBeforeReserve=122000 overflowTokens=1814 toolResultReducibleChars=173317 effectiveReserveTokens=150000 sessionFile=~/.openclaw/agents/main/sessions/<redacted>.jsonl

Gateway log after restart:
- [gateway] removed stale session lock: ~/.openclaw/agents/main/sessions/<redacted>.jsonl.lock (dead-pid)

Code inspection of /opt/homebrew/lib/node_modules/openclaw/node_modules/@mariozechner/pi-coding-agent/dist/core/session-manager.js:
- loadEntriesFromFile(filePath):
  - const content = readFileSync(filePath, "utf8");
  - const lines = content.trim().split("\n");
  - JSON.parse(line) for each line
- SessionManager.open(path, ...):
  - const entries = loadEntriesFromFile(path);
  - return new SessionManager(cwd, dir, path, true);
- SessionManager.setSessionFile(sessionFile):
  - this.fileEntries = loadEntriesFromFile(this.sessionFile);
- SessionManager.buildSessionContext():
  - return buildSessionContext(this.getEntries(), this.leafId, this.byId);

This means SessionManager.open(path) performs one full-file load to inspect the header/cwd and then constructs SessionManager, which loads the same file again via setSessionFile().

OpenClaw call sites observed in dist:
- openclaw/dist/pi-embedded-runner-BBok3J7Q.js
- openclaw/dist/attempt-execution.runtime-BFklk5cT.js
- openclaw/dist/compact-DQRv1vx6.js

Impact and severity

Affected: large session transcripts handled through embedded agent runs, observed on a Discord-backed agent:main session Severity: High (gateway process crash interrupts in-flight work) Frequency: observed repeatedly on the same session file on 2026-04-25; the same session file produced multiple removed stale session lock ... (dead-pid) recoveries after restarts Consequence: in-flight agent work is interrupted and the gateway must be restarted automatically before processing can continue

Additional information

This report is grounded in observed logs plus code inspection. I do not have a captured native heap stack or a minimal synthetic repro outside the affected real session yet. The main code-level concern is the whole-file readFileSync(...).split("\n") load path, and SessionManager.open() appears to trigger that load twice before buildSessionContext() reconstructs messages.