[codex] Add user input client ids

[alexi-openai]

Summary

Adds an optional clientId field to app-server v2 UserInput and carries it through the core UserInput model so clients can correlate echoed user input items without relying on payload equality.

Details

• Adds client_id: Option<String> to core UserInput variants.
• Exposes the v2 app-server field as clientId on the wire and in generated TypeScript.
• Preserves the id when converting between app-server v2 and core protocol types.
• Regenerates app-server schema fixtures.

Validation

• just fmt
• just write-app-server-schema
• cargo test -p codex-app-server-protocol
• cargo test -p codex-protocol
• just fix -p codex-app-server-protocol
• just fix -p codex-protocol
• git diff --check

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[owenlin0]

let's remove the skip_serializing_if = "Option::is_none" part for types exposed over app-server

[owenlin0]

everything else about the annotations look good though

[owenlin0]

this looks good in core protocol 👍

[alexi-openai]

I have read the CLA Document and I hereby sign the CLA

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3e25979d31

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Restore build compatibility for UserInput literals

Adding client_id as a required Rust field on the UserInput variants breaks existing call sites that this commit does not update; for example, codex-rs/cli/src/main.rs:1701 still constructs UserInput::LocalImage { path, detail: None } and :1704 constructs UserInput::Text without client_id, so crates using those literals will fail to compile. Either update all constructors or introduce a constructor/defaulted API that keeps call sites source-compatible.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Preserve client IDs when replaying user messages

When a v2 turn includes clientId, the live ItemCompleted(UserMessage) carries it, but persisted history replay still ignores user-message item-completed events and rebuilds the user message from the legacy UserMessageEvent; hard-coding None here means thread/read, resume, or refresh drops every client ID after replay. Clients relying on these IDs to reconcile their submitted input items will only see them on the live notification path, so replay should use the structured item or persist the IDs in the legacy event.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Keep v2 clientId fields nullable on the wire

The app-server v2 guidance in AGENTS.md says not to use skip_serializing_if = "Option::is_none" for v2 payload fields; with this annotation, any UserInput returned in ItemStarted/ItemCompleted or thread responses will omit clientId when it is absent instead of serializing the stable nullable field shape used by the rest of the v2 API. Please model this as a nullable field on the wire (and align the TS annotation for request typing) rather than making it disappear.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Preserve client IDs in live turn snapshots

For live app-server threads, ThreadState::track_current_turn_event also rebuilds the active turn through ThreadHistoryBuilder: the structured ItemCompleted(UserMessage) now has the client_ids, but the builder ignores that item type and later records the legacy UserMessageEvent, which lands here with None. As a result TurnCompletedNotification and other active-turn snapshots drop the client IDs even before any persisted replay, so clients that reconcile from the turn snapshot will lose the IDs despite receiving them on the individual item notification.

Useful? React with 👍 / 👎.

[owenlin0]

sorry, i realized this approach got quite invasive. can we try something like this instead?

// input
TurnStartParams { client_user_message_id: Option<String>, input: Vec<UserInput>, ... }
TurnSteerParams { client_user_message_id: Option<String>, input: Vec<UserInput>, ... }

// output
ThreadItem::UserMessage {
    id: String,
    client_id: Option<String>,
    content: Vec<UserInput>,
}

[owenlin0]

I think the message-level ID is the right one, but there's some funky merging logic going on - we can improve with the fix below:

The cleanest version is to persist the same message-level id on the already-persisted UserMessageEvent, then rebuild ThreadItem::UserMessage.clientId directly from that event during thread/read / thread/resume:

• keep turn/start.clientUserMessageId and turn/steer.clientUserMessageId
• keep UserMessageItem.client_id for live item/* notifications
• add optional client_id to UserMessageEvent
• copy UserMessageItem.client_id into UserMessageEvent in as_legacy_event()
• have ThreadHistoryBuilder::handle_user_message() set client_id: payload.client_id.clone()
• remove merge_user_message_client_id / set_user_message_client_id and ignore user-message ItemStarted / ItemCompleted again

That would fix both problems with the current patch: persisted thread/read / thread/resume would retain the id because UserMessageEvent is already persisted, and running-thread history would not risk duplicating a user message when ItemStarted(UserMessage) arrives before the legacy UserMessage event.

pub struct UserMessageEvent {
    #[serde(default, skip_serializing_if = "Option::is_none")]
    pub client_id: Option<String>,
    ...
}

[owenlin0]

nit: this kind of test is low value IMO, we can remove

[owenlin0]

nit: let's remove the serde(default) annotation here, not needed