Conversation-Scoped State in OpenAI Apps SDK

[lukaszkostrzewa]

Summary

The current Apps SDK provides per-widget state, and allows developers to maintain cross-session and cross-conversation state on their own backend. However, there is no clean way to persist state for the duration of a single conversation.

This makes it difficult to build multi-step workflows that depend on conversational context across several tool invocations and multiple widgets.

🚧 Problem

Today, developers can store:

1. Widget state – limited to a widget instance
2. Backend state – long-lived, but not tied to a specific conversation, only to user/session identifiers we manage ourselves

What’s missing is a mechanism for conversation-scoped application state.

Why this matters

Many multi-step tool interactions (booking flows, guided editors, multi-stage forms, staged data collection, etc.) require carrying state from one tool invocation/widget to the next, but only within the same conversation.
At the moment, there is no conversation ID or equivalent passed to tool handlers, which prevents us from reliably associating backend state with the conversation in progress.

🧩 Possible solutions

Pass a conversation ID in metadata for each tool invocation

For example:

"_meta": {
    "openai/conversationId": "123",
}

This would let us store and retrieve conversation-specific state on our backend.

Introduce native "conversation state" in the SDK

Something analogous to widget state, but scoped to the conversation:

window.openai.conversationState

This would give widgets direct access to the persistent state for the life of the conversation.

🙏 Question

Is the OpenAI team considering introducing conversation-scoped state support in the Apps SDK?

Thanks for your great work! 🙌

[Georg7]

I think this is critical btw! We're working around this atm by generating a session ID that is passed back and forth across the different message turns and widget renders - it's an unreliable workaround. The idea of a conversation state and or a conversation id would be a great solution!