fix(OpenAI Responses): disable item id replay for storeless providers by snowzlm · Pull Request #90706 · openclaw/openclaw

snowzlm · 2026-06-05T15:38:20Z

Summary

Fixes #89728.
Supersedes duplicate PR #89729.
Refs #90657 as the narrow storeless Responses replay lane from the Actions-backed tracking matrix.

Custom OpenAI Responses-compatible providers can have effective Responses store support stripped (compat.supportsStore=false). In that storeless mode, replaying prior Responses item ids is unsafe because the provider cannot resolve server-stored items from prior turns.

This PR was refreshed from latest openclaw/openclaw:main and now consolidates the useful coverage from both open duplicate PRs:

fix(OpenAI Responses): disable item id replay for storeless providers #90706 direct Responses builder fix/test.
fix（OpenAI Responses/provider）: skip Responses item id replay when store support is stripped #89729 OpenAI Responses context-management wrapper fix/test.

Latest main check

Latest main checked: 66b91d78feb3.

Current main is still incomplete for this bug class:

Direct builder still computes replay eligibility with only payloadPolicy.explicitStore !== false.
Context-management wrapper still passes through an undefined replayResponsesItemIds value when policy.shouldStripStore === true.
For custom openai-responses models with compat.supportsStore=false, payload policy resolves to:

explicitStore === undefined
shouldStripStore === true

That means current main can still replay prior Responses item ids on a route where store support was stripped.

Root cause

The previous guard only checked whether store had been explicitly disabled:

payloadPolicy.explicitStore !== false

For custom providers that strip store support via compatibility policy, explicitStore remains undefined, so the old guard treats replay as safe even though the effective payload is storeless.

The same issue existed in the provider-owned context-management wrapper: it preserved an undefined replay option instead of forcing replay off when policy.shouldStripStore was true.

Changes

Disable Responses item-id replay when the resolved payload policy strips store.
Apply the same storeless replay gate in the OpenAI Responses context-management wrapper.
Add a stream-level regression test for a custom openai-responses model with compat.supportsStore=false.
Add a wrapper regression test proving custom store-stripped Responses routes pass replayResponsesItemIds: false to the underlying stream.
Preserve existing store-enabled OpenAI Responses replay behavior.

Compatibility contract

This PR treats compat.supportsStore=false as a storeless Responses route. For that route OpenClaw must not replay server-side Responses item ids (reasoning.id, assistant message.id, or function_call.id) because the backend cannot resolve prior stored response items. Stateless tool linking remains valid through call_id and function_call_output.call_id.

Store-enabled direct OpenAI Responses behavior is unchanged. Provider-owned wrappers can still explicitly opt back in for known exceptions that support storeless encrypted reasoning replay, such as the existing Microsoft Foundry override.

Rollback: revert the two replay-gate changes in src/agents/openai-transport-stream.ts and src/llm/providers/stream-wrappers/openai.ts; tests added in this PR document the expected storeless contract.

Compatibility regression matrix

This patch now has explicit regression coverage that the storeless fix does not break previously valid official or third-party routes:

Official OpenAI Responses store-enabled route: context wrapper still sets replayResponsesItemIds: true.
Azure OpenAI Responses store-enabled route: context wrapper still sets replayResponsesItemIds: true.
Store-capable third-party Responses route with explicit opt-in: replay item ids are preserved.
Storeless custom Responses route with compat.supportsStore=false: replay item ids are disabled.
Microsoft Foundry provider-owned override: existing extension test still confirms Foundry encrypted reasoning continuations keep replayResponsesItemIds: true despite supportsStore=false.

Focused validation added after the compatibility matrix:

node scripts/run-vitest.mjs run src/agents/embedded-agent-runner-extraparams.test.ts
# 139 tests passed

node scripts/run-vitest.mjs run src/agents/openai-transport-stream.test.ts
# 243 tests passed

node scripts/run-vitest.mjs run extensions/microsoft-foundry/index.test.ts
# 43 tests passed

pnpm exec oxlint src/agents/openai-transport-stream.test.ts src/agents/embedded-agent-runner-extraparams.test.ts extensions/microsoft-foundry/index.test.ts
# 0 warnings, 0 errors

Real behavior proof

Behavior addressed: Storeless custom openai-responses providers must not receive replayed prior Responses item ids. The user-visible failure class is provider-side continuation/tool-turn failure when a custom-compatible provider cannot resolve prior item ids that were never stored server-side.

Real environment tested: Latest local OpenClaw checkout on Linux, reset to openclaw/openclaw:main at 66b91d78feb3, then patched from new branch head bfea37e66676. The before/after proof uses the production createOpenAIResponsesTransportStreamFn() path against a local HTTP Responses-compatible endpoint that rejects replayed server item ids but accepts stateless call_id pairing.

Exact steps or command run after this patch: reverse only the two production replay-gate hunks, run node --import tsx ../live-storeless-before-after-proof.mjs BEFORE, restore the patch, then run node --import tsx ../live-storeless-before-after-proof.mjs AFTER. Supplemental checks: node scripts/run-vitest.mjs run src/agents/openai-responses.reasoning-replay.test.ts src/agents/embedded-agent-runner-extraparams.test.ts and pnpm exec oxlint src/agents/openai-transport-stream.ts src/llm/providers/stream-wrappers/openai.ts src/agents/openai-responses.reasoning-replay.test.ts src/agents/embedded-agent-runner-extraparams.test.ts.

Evidence after fix: The real before/after stream invocation captured the following outbound requests/results from the production transport path:

=== BEFORE current-main-equivalent without storeless replay gate ===
BEFORE_CAPTURE request_path=/responses
BEFORE_CAPTURE store_present=false
BEFORE_CAPTURE replay_items=[{"type":"message","role":"system"},{"type":"message","role":"user"},{"type":"reasoning","id":"rs_prior"},{"type":"message","id":"msg_prior","role":"assistant"},{"type":"function_call","id":"fc_prior","call_id":"call_live"},{"type":"message","role":"user"}]
BEFORE_CAPTURE tool_output_call_id="call_live"
BEFORE_RESULT unsafe_replayed_ids=3
BEFORE_RESULT call_id_preserved=true
BEFORE_BACKEND accepts_payload=false
[openai-transport] [responses] error provider=openai api=openai-responses model=gpt-5.5 name=Error status=400 code=undefined type=undefined causeName=undefined causeCode=undefined message=400 storeless backend rejected replayed Responses item ids
BEFORE_STREAM stop_reason=error
BEFORE_STREAM text=""
BEFORE_SUMMARY rejected_before_or_accepted_after=true
=== AFTER patched head bfea37e66676 with storeless replay gate ===
AFTER_CAPTURE request_path=/responses
AFTER_CAPTURE store_present=false
AFTER_CAPTURE replay_items=[{"type":"message","role":"system"},{"type":"message","role":"user"},{"type":"reasoning"},{"type":"message","role":"assistant"},{"type":"function_call","call_id":"call_live"},{"type":"message","role":"user"}]
AFTER_CAPTURE tool_output_call_id="call_live"
AFTER_RESULT unsafe_replayed_ids=0
AFTER_RESULT call_id_preserved=true
AFTER_BACKEND accepts_payload=true
AFTER_STREAM stop_reason=stop
AFTER_STREAM text="ok"
AFTER_SUMMARY rejected_before_or_accepted_after=true

Supplemental focused Vitest passed 2 shards: openai-responses.reasoning-replay.test.ts passed 10 tests, including the storeless custom provider replay regression; embedded-agent-runner-extraparams.test.ts passed 137 tests, including the context-management wrapper regression. oxlint reported 0 warnings and 0 errors on touched source/test files.

Observed result after fix: The current-main-equivalent path sent three unsafe replayed item ids (rs_prior, msg_prior, fc_prior) and the storeless backend rejected the payload with HTTP 400. The patched head sent zero unsafe replayed ids, preserved call_id pairing, and the same backend accepted the payload and completed the stream with text ok.

What was not tested: No external third-party custom Responses provider was called; the live proof used a local Responses-compatible endpoint to capture the actual OpenClaw outbound request without exposing credentials or relying on a vendor account. Repository-wide GitHub Actions CI is green for the refreshed branch, and the latest Real behavior proof check is passing.

Duplicate PR handling

PR #89729 covers the same issue but was based on an older branch and is now superseded. This PR is the canonical refreshed branch from latest main and includes both the direct builder and wrapper fixes.

clawsweeper · 2026-06-05T15:41:47Z

Codex review: needs maintainer review before merge. Reviewed June 13, 2026, 9:42 AM ET / 13:42 UTC.

Summary
The PR disables prior OpenAI Responses item-id replay when the resolved payload policy strips store, applies the same gate in the OpenAI Responses wrapper, and adds direct/wrapper regression coverage.

PR surface: Source +1, Tests +266. Total +267 across 5 files.

Reproducibility: yes. Source inspection on current main shows compat.supportsStore=false sets shouldStripStore=true while the direct builder still gates replay only on explicitStore !== false, and the wrapper leaves replay undefined in that path.

Review metrics: 1 noteworthy metric.

Replay Default Narrowed: 1 default gate changed. The PR changes the default replay behavior for compat.supportsStore=false Responses routes, so maintainers should consciously accept the compatibility contract before merge.

Stored data model
Persistent data-model change detected: serialized state: src/agents/openai-transport-stream.test.ts. Confirm migration or upgrade compatibility proof before merge.

Merge readiness
Overall: 🦞 diamond lobster
Proof: 🦞 diamond lobster
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Risk before merge

[P1] Merging intentionally changes default outbound payloads for custom openai-responses models with compat.supportsStore=false: prior Responses item ids are omitted unless a provider wrapper explicitly opts back in.
[P1] The real behavior proof validates the generic OpenClaw payload contract against a local Responses-compatible endpoint, but it does not prove every third-party custom backend.
[P1] The PR body's before/after proof was captured before the final maintainer refactor commits; source inspection shows the final head is behavior-equivalent, but landing still depends on maintainer acceptance and current-head checks.

Maintainer options:

Accept The Storeless Contract (recommended)
Land the PR if maintainers agree that stripped-store Responses routes must omit server item ids and any exceptions belong in provider-owned wrappers.
Add A Provider Opt-In First
If another known storeless backend still requires item-id replay, add a documented provider wrapper opt-in with focused regression coverage before merge.
Pause For Vendor Proof
Pause if maintainers need proof from a real third-party custom provider rather than the generic local Responses-compatible endpoint before accepting the compatibility change.

Next step before merge

No automated repair is recommended because there is no concrete patch defect; the remaining action is maintainer compatibility acceptance plus normal current-head checks.

Security
Cleared: The diff changes TypeScript payload gating and tests only; it adds no dependency, workflow, secret, package-resolution, download, or code-execution surface.

Review details

Best possible solution:

Land the focused fix if maintainers accept that compat.supportsStore=false means no server item-id replay by default, with provider-owned opt-ins for known exceptions such as Microsoft Foundry.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection on current main shows compat.supportsStore=false sets shouldStripStore=true while the direct builder still gates replay only on explicitStore !== false, and the wrapper leaves replay undefined in that path.

Is this the best way to solve the issue?

Yes. The PR uses the existing payload policy at both replay handoff points; stripping ids later inside message conversion would be a weaker layer because it lacks the resolved store policy and provider-wrapper override boundary.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 68e234f9e24a.

Label changes

Label changes:

add proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes before/after live output from the production OpenClaw Responses transport path against a local Responses-compatible endpoint, showing current-main-equivalent rejection and patched success while preserving call_id.

Label justifications:

P2: This is a scoped provider/runtime bug fix for custom OpenAI Responses-compatible storeless routes with limited but real follow-up/tool-turn impact.
merge-risk: 🚨 compatibility: The PR changes existing custom-provider payload behavior by omitting prior Responses item ids for compat.supportsStore=false routes unless a provider wrapper opts back in.
rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes before/after live output from the production OpenClaw Responses transport path against a local Responses-compatible endpoint, showing current-main-equivalent rejection and patched success while preserving call_id.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes before/after live output from the production OpenClaw Responses transport path against a local Responses-compatible endpoint, showing current-main-equivalent rejection and patched success while preserving call_id.

Evidence reviewed

PR surface:

Source +1, Tests +266. Total +267 across 5 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	2	5	4	+1
Tests	3	290	24	+266
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	5	295	28	+267

What I checked:

Root policy read: The root review policy was read fully and applied; it requires whole-surface review, dependency/Codex contract checks when relevant, and compatibility-risk surfacing for provider/default changes. (AGENTS.md:1, 68e234f9e24a)
Scoped agent policy read: The scoped agents guide was read fully; it affected the test-surface review but did not change the runtime compatibility verdict. (src/agents/AGENTS.md:1, 68e234f9e24a)
Current main direct-builder gap: Current main still allows replay whenever payloadPolicy.explicitStore !== false; this misses the case where explicitStore is undefined and shouldStripStore is true. (src/agents/openai-transport-stream.ts:2211, 68e234f9e24a)
Storeless policy signal: Current main sets shouldStripStore when a Responses API model declares compat.supportsStore=false, then removes store from the outgoing payload. (src/agents/openai-responses-payload-policy.ts:359, 68e234f9e24a)
Current main wrapper gap: The current wrapper derives replayResponsesItemIds from explicitStore only, so stripped-store routes can leave replay undefined and fall through to the builder default. (src/llm/providers/stream-wrappers/openai.ts:401, 68e234f9e24a)
Serializer behavior: When replay is disabled, reasoning/message/function-call item ids are removed while function_call.call_id and function_call_output.call_id remain available for stateless tool pairing. (src/agents/openai-transport-stream.ts:1185, 68e234f9e24a)

Likely related people:

waterblue: Authored the earlier replay-id gating commit that this PR extends from explicit store=false to stripped-store policy. (role: prior repair author; confidence: high; commits: 03dec8bb3a00; files: src/agents/openai-transport-stream.ts, src/llm/providers/stream-wrappers/openai.ts, src/agents/openai-transport-stream.test.ts)
Vincent Koc: Recent history shows repeated provider compatibility and OpenAI Responses transport work around the central files affected by this PR. (role: recent area contributor; confidence: high; commits: cc1881a83846, 7836c9a6c24d, 8c802aa68351; files: src/agents/openai-transport-stream.ts, src/llm/providers/stream-wrappers/openai.ts, src/agents/openai-responses-payload-policy.ts)
Peter Steinberger: Recent commits touched OpenAI transport defaults, native streaming compat helpers, and related provider policy boundaries. (role: adjacent owner; confidence: medium; commits: 3207c5326a94, 628c71103eb7, a9125ec0b07b; files: src/agents/openai-transport-stream.ts, src/llm/providers/stream-wrappers/openai.ts, src/agents/openai-responses-payload-policy.ts)
obviyus: Authored prior Responses API capability detection work and the current PR head refactor that simplified the wrapper replay gate. (role: adjacent capability contributor; confidence: medium; commits: 685f9903ec38, ab92238c2de0, bfc4546bb5fc; files: src/agents/openai-responses-payload-policy.ts, src/llm/providers/stream-wrappers/openai.ts, src/agents/embedded-agent-runner-extraparams.test.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

snowzlm · 2026-06-07T14:50:37Z

Updated the PR body with latest-main verification and consolidated the duplicate #89729 wrapper fix. @clawsweeper re-review

clawsweeper · 2026-06-07T14:50:39Z