[Gi99lin]

Problem

When proxy clients like OpenClaw send Responses API format requests through OmniRoute to the Codex /codex/responses endpoint, requests after the 2nd turn fail with 404 errors:

[404]: Item with id 'rs_02c78f217bfad9f70169e3944f330c8191ae8fc8956583ccdd' not found.
Items are not persisted when `store` is set to false.
Try again with `store` set to true, or remove this item from your input.

Root cause: OpenClaw includes full response items from previous turns in the input array, carrying server-assigned id fields (prefixed with rs_, fc_). The Codex backend validates these IDs against its persistence store but the /codex/responses endpoint does not actually persist response items — so the lookup always fails.

Evidence

Verified by inspecting the request payload on the 3rd turn:

{
  "id": "rs_02c78f217bfad...",    // ← server tries to find this in store → 404
  "type": "reasoning",
  "summary": []
},
{
  "type": "function_call",
  "id": "fc_02c78f217bfad...",    // ← same problem
  "call_id": "call_5NF4nZx...",  // ← client-side ID, not affected
  "name": "read",
  "arguments": "..."
}

First 2 turns succeed because only the 3rd+ turn includes response items from previous turns.

What this PR changes

stripStoredItemReferences() — comprehensive ID sanitization

The function now handles three cases:

Input format	Action
Bare string refs ("rs_abc123")	Remove from array
Object refs ({ type: "item_reference" })	Remove from array
Items with server IDs ({ id: "rs_...", type: "reasoning" })	Strip id field, keep item content

This preserves the full conversation context (reasoning blocks, function calls, outputs) while removing only the server-generated identifiers that the backend cannot validate.

Always delete previous_response_id

The /codex/responses endpoint does not persist responses, so any previous_response_id reference will cause a 404. This matches the behavior of both:

• Official Codex CLI (Rust): Sets previous_response_id: None (codex-api/src/common.rs:187)
• CLIProxyAPI (Go): sjson.DeleteBytes(body, "previous_response_id") (codex_executor.go:115)

Prompt cache support

Also includes cache affinity improvements:

• Injects stable prompt_cache_key derived from workspace ID
• Sets session_id header for backend cache routing
• Sets originator: "codex_cli_rs" header

Testing

Verified on a production-like deployment (homelab) with OpenClaw → spawn-sanitizer → OmniRoute → Codex:

• ✅ 5+ turn conversations without 404 errors
• ✅ Cache hits visible from 2nd turn onwards (cached_tokens > 0)
• ✅ Function calls and reasoning blocks preserved in context
• ✅ No regression on translated (Chat Completions) path

[gemini-code-assist]

Code Review

This pull request enhances the Codex executor by improving backend compatibility and adding support for prompt caching. Key updates include the addition of stripStoredItemReferences to remove server-generated IDs and previous_response_id from requests to prevent 404 errors, defaulting the store parameter to true, and injecting cache-related headers and keys (originator, session_id, prompt_cache_key). Additionally, unsupported token limit parameters are now removed before passthrough. A critical typo was identified in the getResponsesSubpath regular expression that would cause standard endpoint matching to fail.

[gemini-code-assist]

The regular expression contains a typo: ? (two spaces and a question mark) has been added at the end. This will cause the match to fail for standard endpoint paths like /responses or /responses/compact because it will expect trailing spaces in the URL. It should be reverted to the original ? to correctly match the optional subpath.

Suggested change

	const match = normalizedEndpoint.match(/(?:^|\/)responses(?:(\/.*)) ?$/i);
	const match = normalizedEndpoint.match(/(?:^|\/)responses(?:(\/.*))?$/i);

[diegosouzapw]

Thanks @Gi99lin for this great contribution! 🎉 The fix has been integrated into the release branch and will be part of the next release. We appreciate your effort!