openclaw - 💡(How to fix) Fix [Bug]: Codex resumes ignore OpenClaw-visible messages written after native binding [1 pull requests]

Bug type

Regression / behavior bug in Codex app-server resume continuity.

Summary

After PR #88262, Codex app-server resumes can ignore OpenClaw-visible user/assistant messages that were written after the Codex native thread binding was created.

Before the PR, hasUserVisibleHistoryAfterCodexBinding(...) detected this case and forced projection of the newer visible history into the next Codex start. The PR removed that guard and added a test that asserts the newer visible messages are not injected.

That is unsafe for sessions where OpenClaw-visible transcript state can advance outside the native Codex thread, for example imported messages, transcript repair, non-Codex participants, channel handoff, or any multi-agent/source conversation where the native Codex thread is only one consumer of the OpenClaw transcript.

Why this is high confidence

• The removed base-branch helper explicitly handled this case:
  • attempt-context.ts at base f52355c, hasUserVisibleHistoryAfterCodexBinding
• The projection decision used that helper to project when there was newer OpenClaw-visible history after the Codex binding:
  • attempt-context.ts at base f52355c, shouldProjectMirroredHistoryForCodexStart
• The merged code no longer has an equivalent check and hard-codes the Codex model-history list to []:
  • run-attempt.ts#L767-L777
• The current test suite now asserts the problematic behavior:
  • run-attempt.test.ts#L1750-L1787

Diagram

sequenceDiagram
    participant OC as OpenClaw session JSONL
    participant Bind as Codex binding
    participant Native as Native Codex thread
    participant Run as Next Codex run

    OC->>Bind: T0 create binding to native thread
    Bind->>Native: Native thread knows history up to T0
    OC->>OC: T1 append user-visible / assistant-visible message
    Note over OC: Message is visible in OpenClaw transcript but not in native Codex thread
    Run->>Bind: Binding still looks resumable
    Run->>Native: thread/resume succeeds
    Run->>Native: turn/start sends only current prompt
    Native-->>Run: Responds without T1 context

Expected behavior

If OpenClaw-visible messages exist after the Codex binding timestamp, the next Codex run must not assume the native Codex thread already knows them.

It should do one of the following:

• project the newer visible messages once as quoted context,
• rotate/start a new Codex thread with bounded continuity context,
• route through an active context engine that includes those newer messages,
• or reject/fail with a clear "native thread is stale relative to OpenClaw transcript" error.

Silent resume with only the current prompt is the broken case.

Actual behavior

The merged code resumes the native Codex thread and sends only the current prompt. The newer OpenClaw-visible messages are neither in the native thread nor in the turn input.

The current test named does not inject newer OpenClaw-visible history after Codex binding on resume makes this behavior explicit.

Minimal reproduction shape

1. Create a session file.
2. Write a Codex app-server binding at time T0.
3. Append a user or assistant message at T1 > T0 that is not a Codex mirrored transcript echo.
4. Run the next Codex app-server attempt with no active context engine.
5. Make thread/resume succeed.
6. Inspect the turn/start input.

Expected: the newer visible message is represented in the input or an explicit stale-binding recovery path runs.

Actual: the input is only the current prompt.

Impact

This creates a split-brain transcript:

• OpenClaw's canonical session has the newer visible message.
• The native Codex thread does not.
• The next Codex response is persisted back into OpenClaw as if it answered in the full OpenClaw-visible context.

That can produce wrong answers, skipped instructions, repeated work, or unsafe policy drift in any flow where Codex is not the only writer/reader of the visible conversation.

This matters especially for integrations that treat OpenClaw as the source-of-truth transcript and Codex native threads as an execution backend.

Suggested fix direction

Restore the removed stale-binding guard, but keep it separated from normal native Codex model history:

flowchart TD
    A["Existing Codex binding"] --> B["Check binding timestamp / known transcript watermark"]
    B --> C{"Any user/assistant visible messages after binding?"}
    C -->|No| D["Resume native Codex thread with current prompt only"]
    C -->|Yes| E["Project only newer non-Codex-visible messages as quoted context"]
    E --> F["Resume or rotate with explicit stale-binding recovery"]

Important details from the removed helper should be preserved:

• exclude Codex app-server mirrored transcript entries, so Codex does not see its own prior output twice,
• only treat user/assistant visible messages as stale-binding evidence,
• compare against binding creation/update timestamps or a stronger transcript watermark,
• add a regression test that distinguishes "Codex mirrored echo after binding" from "real OpenClaw-visible message after binding".

Evidence checked

• Merged PR: openclaw/openclaw#88262
• Merge commit: 530351e394a19b1dd2943cb08259657a13f90572
• Base commit containing removed helper: f52355ce5f8c636fb6e0ef9ef73dfe97a3e82ddb
• PR head audited locally: 04a4427d0c0b8f2e7bb666bbbcda5c557d033972