Summary

What problem does this PR solve?

• Prevents OpenClaw from replaying prior OpenAI Responses item ids when the effective request is non-persistent (store=false or store is stripped because the custom provider declares compat.supportsStore=false).
• Fixes the embedded-reply failure mode where custom OpenAI-compatible Responses backends reject reused item ids with errors like 404 Item with id ... not found and Items are not persisted when store is set to false.
• Keeps existing replay behavior for store-enabled OpenAI Responses requests so the change stays scoped to non-persistent routes.

Why does this matter now?

• Custom Responses-compatible providers are already used in real OpenClaw deployments, and this bug turns follow-up/tool-turn replies into Something went wrong while processing your request failures.

What is the intended outcome?

• Non-persistent Responses routes stop sending stale replay item ids.
• Persistent/store-enabled Responses routes continue replaying item ids as before.

What is intentionally out of scope?

• This PR does not change the UI-side startup: false assertion failure currently red in upstream CI.
• This PR does not attempt to fix the unrelated long-running Vitest shard timeouts in infra-file-safety and startup-health-runtime.

What does success look like?

• OpenClaw omits replay item ids for store=false / supportsStore=false Responses requests.
• Focused transport and wrapper regression coverage passes.
• Typecheck/lint/build checks directly touched by this change stay green.

What should reviewers focus on?

• The replayResponsesItemIds gating in src/llm/providers/stream-wrappers/openai.ts.
• The transport-side guard in src/agents/openai-transport-stream.ts.
• The new regression tests covering both store-disabled and store-enabled behavior.

Linked context

Which issue does this close?

Closes #

Which issues, PRs, or discussions are related?

Related #

Was this requested by a maintainer or owner?

• Requested by the repo owner's downstream fork workflow while preparing an upstream fix.

Real behavior proof (required for external PRs)

• Behavior or issue addressed:
  • A custom OpenAI-compatible Responses route reused prior response item ids even though the effective request was non-persistent, causing backend errors (404 Item with id ... not found, Items are not persisted when store is set to false) and embedded reply failure.
• Real environment tested:
  • Real custom Responses-compatible backend: aitokenapi/gpt-5.5 at catcats.net.
  • Real branch runtime payload generation from this PR via buildOpenAIResponsesParams(...) in the patched source tree.
• Exact steps or command run after this patch:
  • pnpm exec tsx projects/openclaw-upstream-fix/reports/pr-89128-real-proof/capture-real-backend-proof.ts
• Evidence after fix (redacted):
  • Request summary:
    • store field present: false
    • reasoning item id present: false
    • assistant message id present: false
    • function_call id present: false
    • function_call call_id: call_abc
    • reasoning encrypted_content present: false
  • Response summary:
    • HTTP status: 200
    • response status: completed
    • previous_response_id: null
    • output_count: 1
  • Redacted response preview:
    • {"status":"completed","previous_response_id":null,...}
• Terminal output after fix (redacted):

provider=aitokenapi
model=gpt-5.5
http_status=200
response_status=completed
store_field_present=false
reasoning_id_present=false
assistant_message_id_present=false
function_call_id_present=false
function_call_call_id=call_abc
reasoning_encrypted_content_present=false
previous_response_id=null
output_count=1

• Observed result after fix:
  • The real backend accepted the non-persistent follow-up payload and completed successfully without replaying stale Responses item ids.
• What was not tested:
  • I did not attach raw credential-bearing upstream transport logs or run the same proof against every custom Responses-compatible provider configured locally.
  • I also did not run a separately installed long-running OpenClaw gateway outside this source checkout as part of this PR branch.
• Local proof artifacts retained for audit:
  • projects/openclaw-upstream-fix/reports/pr-89128-real-proof/real-backend-proof.md
  • projects/openclaw-upstream-fix/reports/pr-89128-real-proof/real-backend-proof.json
  • projects/openclaw-upstream-fix/reports/pr-89128-real-proof/real-backend-proof-terminal.txt
• Proof limitations or environment constraints:
  • This proof uses a redacted local audit artifact rather than attaching raw credential-bearing transport logs.
  • It exercises the real backend with the patched request builder/path and confirms the no-stale-id request shape plus successful completion.

Tests and validation

Which commands did you run?

• pnpm test src/agents/openai-transport-stream.test.ts src/agents/embedded-agent-runner-extraparams.test.ts
• gh workflow run ci.yml --repo snowzlm/openclaw --ref fix/responses-store-false-replay -f target_ref=fix/responses-store-false-replay -f include_android=false

What regression coverage was added or updated?

• Added wrapper-level coverage proving replayResponsesItemIds=false when a custom Responses provider strips store support.
• Added transport-level coverage proving reasoning/message/function_call item ids are omitted for non-persistent custom Responses routes.
• Preserved existing store-enabled replay coverage to avoid regressing native OpenAI Responses behavior.

What failed before this fix, if known?

• Custom Responses backends that do not persist items rejected replayed item ids on follow-up turns, breaking embedded replies.

If no test was added, why not?

• Tests were added.

Risk checklist

Did user-visible behavior change? (Yes/No)

• Yes

Did config, environment, or migration behavior change? (Yes/No)

• No

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

• No

What is the highest-risk area?

• Accidentally disabling replay item ids for store-enabled OpenAI Responses requests that still rely on persisted item history.

How is that risk mitigated?

• The guard only disables replay when explicitStore === false or shouldStripStore === true.
• Existing store-enabled behavior is preserved and explicitly covered by regression tests.

Current review state

What is the next action?

• Review the replay gating logic and confirm the unrelated red CI jobs can be ignored or handled separately.

What is still waiting on author, maintainer, CI, or external proof?

• No author changes are pending for the Responses replay fix itself.
• Maintainer review is needed on whether to merge with the three unrelated red CI jobs still present in upstream/fork runs.

Which bot or reviewer comments were addressed?

• Addressed the initial check-test-types regression from this branch by relaxing the test model typing in follow-up commit 84a9cce5c7.

Issue

Fixes #89330