Skip to content

fix(provider-codex): sanitize Responses message ids before dispatch#97

Draft
M1k0t0 wants to merge 2 commits into
Menci:mainfrom
M1k0t0:floway/codex-message-id-sanitize
Draft

fix(provider-codex): sanitize Responses message ids before dispatch#97
M1k0t0 wants to merge 2 commits into
Menci:mainfrom
M1k0t0:floway/codex-message-id-sanitize

Conversation

@M1k0t0

@M1k0t0 M1k0t0 commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

Summary

  • strip non-OpenAI message ids from Codex Responses input before upstream dispatch
  • preserve valid msg* message ids and leave non-message item ids untouched
  • handle both typed message items and typeless easy input messages when they reach the Codex provider boundary

Why

Codex can echo local/review rollout message ids that the upstream Responses API rejects. Those ids are client-local, not upstream-owned, so Floway should remove them before sending the request to Codex upstream while preserving the message content.
This PR is scoped to the Codex provider wire boundary. A separate gateway-side normalization fix is still needed for stored native Responses requests where typeless { role, content } messages are staged before provider interceptors run.

Reproduction

  1. Run /review and wait for the review to complete.
  2. Send another message in the same Codex conversation.

@Menci

Menci commented Jun 23, 2026

Copy link
Copy Markdown
Owner

But, how does it work on Codex official client+server?

@M1k0t0 M1k0t0 force-pushed the floway/codex-message-id-sanitize branch from 7b421ae to 3eb01f3 Compare June 24, 2026 06:43
@M1k0t0

M1k0t0 commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

I dug into this more. The relevant official Codex behavior has two paths.

For normal Codex Responses requests, the client strips item ids when the item_ids feature is off, and that feature is disabled by default. Therefore the official Codex client does not normally send local rollout ids such as review_rollout_user.

However, when Codex thinks it is connected to an Azure Responses endpoint, for example because the base URL contains azure-api., it sets store: true, and the id-stripping path is skipped when store is true. After that, the official Codex CLI really does send the local /review rollout ids to Floway even though features.item_ids is not enabled.

Floway then forwards to the Codex upstream, where those local ids are not valid Codex message ids. This patch handles that compatibility boundary: preserve upstream-shaped message ids (msg...) but drop client-local message ids like review_rollout_user before forwarding to Codex.

This PR is still draft for a separate reason: for stored native Responses requests, Floway’s gateway can currently fail while staging typeless { role, content } message inputs before the request reaches the Codex provider boundary. I'd like to fix that upper gateway normalization path first, then come back and finalize this provider-level sanitizer change.

Refs:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants