Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Gateway reset can rotate the OpenClaw session while preserving enough native Codex app-server state to resume the old Codex thread after reset.

For the Codex harness, reset needs to clear the native app-server sidecar binding and avoid carrying old native resume handles into the new session.

Parent tracker: #66251

Steps to reproduce

1. Configure an agent to use the native Codex harness.
2. Run a Codex-backed turn so the app-server creates a native thread binding.
3. Reset the session through the gateway reset path.
4. Send another Codex-backed turn after reset.
5. Observe whether Codex resumes the old app-server thread instead of starting a fresh one.

Expected behavior

After gateway reset:

• the old Codex app-server binding is cleared
• the new OpenClaw session does not reuse stale native Codex resume state
• the next Codex turn starts a fresh native Codex thread unless the user explicitly requested resume behavior

Actual behavior

The gateway reset path can preserve or reuse the session file/native binding state that the Codex app-server uses to decide whether to resume a thread.

That can cause the post-reset session to continue with old Codex native context, even though the OpenClaw session has been reset.

OpenClaw version

2026.4.10 / 2026.4.11 reports, plus current main investigation

Operating system

macOS and Linux reports

Install method

npm/global CLI and local source investigation

Model

codex/gpt-5.4

Provider / routing chain

OpenClaw -> bundled codex plugin -> Codex app-server

Additional provider/model setup details

NOT_ENOUGH_INFO

Logs, screenshots, and evidence

Scope boundary

This issue is specifically about the gateway reset path and native Codex app-server bindings.

It should not track unrelated transcript replay, generic session reset behavior, or non-Codex CLI resume behavior unless it directly affects Codex app-server reset correctness.

Acceptance criteria

• Gateway reset invokes registered agent harness reset hooks for the old session.
• Codex reset clears the app-server binding associated with the old session file.
• Generated session reset gets a fresh generated transcript/session file where appropriate.
• Native Codex resume handles are not carried into the post-reset session accidentally.
• The next Codex turn after reset starts a new app-server thread rather than resuming the old one.
• Behavior is covered for gateway reset entrypoints, not only chat-command reset paths.

Suggested test coverage

• Gateway reset calls the registered Codex harness reset hook.
• Gateway reset removes or ignores the old Codex app-server sidecar binding.
• A post-reset Codex run calls native thread/start instead of native thread/resume.
• Existing behavior for explicit resume/custom session file cases remains intentional.

Related

• Parent: [Bug]: Track Codex harness stability work #66251

Impact and severity

Affected: Users running OpenClaw with the bundled Codex harness.

Severity: High for reset/new-session isolation in Codex-backed gateway sessions.

Frequency: Observed during Codex harness stabilization investigation.

Consequence: A reset session can accidentally retain old native Codex context, making reset behavior misleading and potentially carrying stale state forward.

Additional information

The local investigation has in-progress changes in this area. This issue is intended to capture the observed failure mode and the acceptance criteria for a focused fix.