You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
Loading
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
Create a session file.
Write a Codex app-server binding at time T0.
Append a user or assistant message at T1 > T0 that is not a Codex mirrored transcript echo.
Run the next Codex app-server attempt with no active context engine.
Make thread/resume succeed.
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"]
Loading
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".
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
attempt-context.tsat basef52355c,hasUserVisibleHistoryAfterCodexBindingattempt-context.tsat basef52355c,shouldProjectMirroredHistoryForCodexStart[]:run-attempt.ts#L767-L777run-attempt.test.ts#L1750-L1787Diagram
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 contextExpected 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:
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 resumemakes this behavior explicit.Minimal reproduction shape
T0.T1 > T0that is not a Codex mirrored transcript echo.thread/resumesucceed.turn/startinput.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:
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:
Evidence checked
530351e394a19b1dd2943cb08259657a13f90572f52355ce5f8c636fb6e0ef9ef73dfe97a3e82ddb04a4427d0c0b8f2e7bb666bbbcda5c557d033972