core: Consolidate Responses API Codex metadata#27122
Merged
Merged
Conversation
owenlin0
changed the title
owenlin0
changed the title
owenlin0
force-pushed
the
owen/consolidate_responsesapi_request_metadata
branch
from
0cfe73b to
fb11500
Compare
owenlin0
changed the title
owenlin0
added a commit
that referenced
this pull request
Jun 9, 2026
pakrym-oai
reviewed
Jun 9, 2026
owenlin0
added a commit
that referenced
this pull request
Jun 10, 2026
owenlin0
added a commit
that referenced
this pull request
Jun 10, 2026
owenlin0
added a commit
that referenced
this pull request
Jun 10, 2026
pakrym-oai
reviewed
Jun 10, 2026
| - "thread_id": "<UUID>", | ||
| - "turn_id": "<UUID>", | ||
| - "x-codex-installation-id": "<UUID>", | ||
| - "x-codex-turn-metadata": "{\"installation_id\":\"<UUID>\",\"session_id\":\"<UUID>\",\"thread_id\":\"<UUID>\",\"turn_id\":\"<UUID>\",\"window_id\":\"<UUID>:0\",\"request_kind\":\"turn\",\"sandbox\":\"<SANDBOX>\",\"turn_started_at_unix_ms\":<UNIX_MS>}", |
Collaborator
There was a problem hiding this comment.
the fact that we are repeating same values this many times.
I assume they are also repeated in request headers
Collaborator
Author
There was a problem hiding this comment.
@pakrym-oai yeah, I am planning to delete the top-level ones once i make sure codex-backend and responsesapi don't rely on them. my goal is x-codex-turn-metadata is the source of truth
Collaborator
Author
There was a problem hiding this comment.
unfortunately it looks like i'm adding these fields here for compaction requests, but that's just because I'm trying to make the metadata consistent for all the requests we make to responsesapi and we currently send these on responses generate calls too
pakrym-oai
reviewed
Jun 10, 2026
owenlin0
force-pushed
the
owen/consolidate_responsesapi_request_metadata
branch
5 times, most recently
from
14dfdbb to
a5a6129
Compare
owenlin0
added a commit
that referenced
this pull request
Jun 10, 2026
pakrym-oai
approved these changes
Jun 11, 2026
owenlin0
force-pushed
the
owen/consolidate_responsesapi_request_metadata
branch
from
3d0ac57 to
2637659
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Introduce a
CodexResponsesMetadatastruct that defines all the core metadata we send to Responses API. Example fields arethread_id,turn_id,window_id, etc.Going forward,
client_metadata["x-codex-turn-metadata"]will be the canonical way Codex sends metadata to Responses API across both HTTP and websocket transports.For now, we continue to emit the existing top-level HTTP headers and top-level
client_metadatafields from the sameCodexResponsesMetadatastruct for compatibility reasons.Also, app-server clients who specify additional
responsesapi_client_metadataviaturn/startandturn/steerwill have those fields merged intoclient_metadata["x-codex-turn-metadata"], but cannot override the reserved fields that core uses (i.e. the fields inCodexResponsesMetadata).Why
Responses API request instrumentation is the source of truth for downstream Codex analytics that join requests by Codex IDs such as session, thread, turn, and context window. Before this change, those values were assembled through several request-specific paths: HTTP request bodies, websocket handshake headers, websocket
response.createpayloads, compaction requests, and the richx-codex-turn-metadataenvelope all had their own wiring.That made metadata propagation easy to drift across API-key/direct Responses API requests, ChatGPT-auth/proxied requests, websocket requests, and compaction requests. It also made additions like
window_iderror-prone because a field could be added to one transport projection but missed in another.What changed
CodexResponsesMetadataas the core-owned snapshot for Codex metadata sent to ResponsesAPI.client_metadata["x-codex-turn-metadata"], flatclient_metadataprojections, and direct compatibility headers from that same snapshot.responsesapi_client_metadataas enrichment for the Codex turn metadata blob while preventing those extras from overriding Codex-owned fields.Verification
cargo check -p codex-corejust fix -p codex-core