App-Server SDK: allow caller-provided ID on TurnStartParams for steer correlation

Resolved 💬 1 comment Opened Apr 5, 2026 by 0xTinker Closed May 10, 2026

Variant: App-Server SDK (codex-rs/app-server-protocol)

What feature would you like to see?

Add an optional id field to TurnStartParams that is preserved on the UserMessageItem returned in item/started and item/completed events.

When using turn/start to inject mid-turn steered messages via the app-server protocol, there's no way to correlate the ItemCompleted(UserMessage) event back to the original request. UserMessageItem.id is always a fresh Uuid::new_v4() generated internally — the caller has no control over it.

The TUI works around this with content-based matching (PendingSteerCompareKey), but this is fragile for SDK consumers — identical message content produces identical keys, and there's no way to reliably distinguish two steers with the same text.

If TurnStartParams accepted an optional id: String, and that ID was carried through to the UserMessageItem in the emitted events, SDK consumers could:

  1. Correlate injected steers to their confirmation events by UUID
  2. Know exactly when/where a steer was consumed in the conversation timeline
  3. Build reliable UIs without content-matching heuristics

The change is small — threading an optional ID from TurnStartParams through inject_inputpending_inputUserMessageItem instead of generating a random UUID when one is provided. When omitted, the current Uuid::new_v4() behavior is preserved.

Additional information

For context, Claude Code's Agent SDK solves this by letting callers set a uuid on user messages which survives the full injection pipeline and appears on the replayed event. A similar pattern for Codex would be valuable for app-server SDK consumers building on top of mid-turn steering.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗