[UX] ChatGPT should not expose unsupported or broken feature combinations to end users

[enpasos]

Hi OpenAI team,

I would like to raise a platform-level UX issue that appears across several otherwise separate reports:

ChatGPT exposes end users to feature combinations that are unsupported, incompatible, or currently broken—without automatically blocking those combinations and without giving GPT/App developers a reliable way to block them.

This is worse than simply not supporting a feature.

The UI presents an apparently valid path, but the incompatibility becomes visible only after the user enters it. The result may be silently missing backend behavior, a broken multi-turn workflow, or an indefinite loading state.

End users cannot distinguish a ChatGPT compatibility problem from a defect in the GPT/App. The resulting loss of trust therefore affects both ChatGPT and the developer’s product.

Current examples

1. Custom GPT Actions × multi-turn interaction/runtime

A successful Action response can be used in the assistant turn in which it is returned, but is not reliably available after the next user message.

Ordinary multi-turn workflows can therefore break even though the GPT and its Actions appear normally available. The builder cannot declare reliable cross-turn Action-result availability as a hard requirement or restrict the GPT to a runtime for which that behavior has been verified.

Detailed reproducer:

Custom GPT does not reuse an Action response on the next user turn — reproducible after GPT-5.6 rollout

After the GPT-5.6 rollout, our production Custom GPT workflow stopped working across user turns. We built a minimal public reproducer that excludes authentication, databases, learner data, RAG and production-specific logic. Reproduce Open RegressionGPT: ChatGPT - RegressionGPT In a new chat, send RUN_RETAIN. The GPT successfully calls the Action and replies RETAIN_READY. Immediately send RECALL_RETAIN in the same chat. Expected: The GPT returns the exact token received from the previous Acti…

2. MCP App UI × native mobile × decoupled tool calls

A non-UI data tool followed by a UI-linked render tool can complete successfully on the MCP server while the native ChatGPT mobile app leaves an unresolved widget loading skeleton indefinitely.

The same local MCP plugin and visualization work correctly in ChatGPT Web, including in a mobile browser.

This is not an exotic or undocumented call sequence. OpenAI’s current Apps documentation explicitly recommends separating data-processing tools from render tools and describes the following call flow:

data tool → structuredContent → render tool → widget

Bug report:

[BUG] ChatGPT mobile app fails to render MCP App widget when the widget-linked tool is called after another tool in the same assistant turn (regression, ~July 10)

We can independently confirm the same regression using our locally installed, unpublished MCP plugin, SkillPilot Coach v1. Our flow performs two stateless MCP tool calls within a single assistant turn: get_skillpilot_context — no UI metadata render_skillpilot_goal_visualization — includes _meta.ui.resourceUri On August 3, 2026, our server recorded both calls completing successfully: 08:57:59 UTC get_skillpilot_context success 08:58:07 UTC render_skillpilot_goal_vis…

Relevant documentation:

Add UI to your MCP server – Plugins | OpenAI Developers

3. Voice Mode × Custom GPT Actions / Apps

OpenAI’s current documentation states that custom Actions are not available in Voice conversations with GPTs. It also states that Voice Mode currently does not support Apps.

Nevertheless, users may still be offered Voice Mode inside GPTs whose core purpose depends on these capabilities. The user enters what appears to be the same GPT experience, but its essential backend integration is unavailable.

There is no documented per-GPT builder control that allows the creator to disable this incompatible entry point.

Feature request:

Allow GPT builders to disable Voice Mode when Custom GPT Actions are not supported

Hi OpenAI team, I would like to file a feature request regarding Voice Mode / Advanced Voice Mode in Custom GPTs that depend on Actions / function calls. There are already several community reports about this issue. Earlier discussions first asked for Advanced Voice Mode support in Custom GPTs; later comments reported that Advanced Voice Mode became available, but Actions are skipped or not executed, while the same Custom GPT works correctly in text mode. There is also a newer thread specifica…

Relevant documentation:

https://help.openai.com/en/articles/20001274

https://help.openai.com/en/articles/11487775-connectors-in-chatgpt

The shared UX anti-pattern

In all three cases:

• ChatGPT presents an apparently valid feature, client, model, or interaction mode.
• A capability required by the GPT/App is unavailable or unreliable in that combination.
• The incompatibility is discovered only after the user enters the flow.
• The developer has no reliable compatibility contract or preventive control.
• The resulting failure looks like a defect in the GPT/App.

The general product rule should be:

Known, declared, or detectable incompatibilities should be blocked before the user enters the workflow.

Requested behavior

1. OpenAI-controlled compatibility gating

This is the preferred solution.

ChatGPT knows the actual client, interaction mode, model/runtime, rollout state, and supported tool/UI capabilities. It should automatically hide or disable combinations that cannot satisfy an integration’s requirements.

OpenAI already applies this principle in one area: according to the current documentation, when a GPT contains custom Actions, the model selector shows only models that support Actions.

https://help.openai.com/en/articles/9442513-configuring-actions-in-gpts

The same principle should be applied consistently to Voice Mode, Apps, embedded UI, client-specific capabilities, and required conversation-state semantics.

2. Developer-controlled capability requirements

Where OpenAI cannot infer the application’s requirements, GPT/App developers should be able to declare them explicitly.

Examples of such requirements could include:

• tool calls or Actions are required;
• cross-turn tool-result availability is required;
• embedded UI support is required;
• Voice Mode must be disabled;
• a complete text-only fallback is required.

The exact configuration schema is less important than giving developers a reliable way to prevent unsupported execution paths.

3. Runtime capability negotiation

Apps should receive machine-readable information about the capabilities of the current host, client, and interaction mode before choosing a tool or UI path.

This should be capability-based rather than requiring developers to guess from product names, client versions, or platform-specific behavior.

4. Safe fallback behavior

When compatibility cannot be determined in advance, ChatGPT should fail safely and visibly.

For example:

• preserve the complete textual result;
• remove unresolved widget loading shells;
• display a clear compatibility message;
• do not silently skip required Actions or tools;
• do not let the model continue as though the required backend operation had succeeded.

5. A documented and versioned compatibility contract

The supported combinations between the following dimensions should be publicly documented and testable:

• clients and platforms;
• text and Voice Mode;
• models and runtimes;
• Custom GPT Actions;
• MCP tools and Apps;
• embedded MCP UI;
• same-turn and cross-turn tool-result availability.

This does not require every feature to work in every possible combination.

It requires unsupported combinations to be represented honestly in the product instead of being exposed to end users as though they worked.

Fail closed, not in front of the user.

Please treat this as a shared UX and platform-reliability issue, rather than only as a collection of isolated bugs. Fixing the underlying bugs is ideal. Until then, automatic compatibility gating or developer-controlled constraints would prevent users from being routed into known-broken experiences.

Additional reproducible examples are welcome. Ideally, please include:

• the exact client and platform;
• the selected mode and model/runtime;
• the required GPT/App capability;
• expected versus observed behavior;
• a link to the detailed bug report.

[enpasos]

I would like to add another perspective to this feature request.

Compatibility gating is important as long as certain combinations are unsupported or unreliable. But the longer-term goal should not merely be to prevent users from entering broken combinations. It should be to make movement between interaction modes and devices as seamless as possible.

Our open-source project SkillPilot is a good example of why this matters. A learner benefits enormously when the ChatGPT-based coach can communicate through different modalities:

• Text is often the best medium for formulas, precise explanations, and structured reasoning.

• Images can illustrate mathematical or scientific concepts.

• Learners can solve an exercise traditionally on paper, photograph it with their phone, and upload it for evaluation.

• Voice Mode is excellent when the learner wants to explore a topic more freely in a natural dialogue.

• App-generated visualizations can help make learning goals, relationships, or progress understandable.

There is a second, equally important dimension: devices.

A phone is always available and particularly convenient for Voice Mode, taking photos, and uploading handwritten work. A desktop, notebook, or tablet is often much better for reading longer explanations, working with formulas, and viewing detailed diagrams or visualizations.

The ideal learning experience therefore allows users to move freely across two dimensions:

1. Interaction modes and media: voice, text, photos, uploaded work, and app-generated UI or images.

2. Devices: phone, tablet, notebook, and desktop.

A great deal of this already works, and it is genuinely impressive. ChatGPT’s combination of modalities, devices, and extensibility creates possibilities that would have been difficult to imagine only a few years ago.

The problem is that some of these capabilities still do not work reliably together. That is why the UX issue described in this thread matters so much. In the near term, unsupported combinations should be detected and blocked clearly rather than failing in front of the learner.

But the strategic objective should be broader: users should eventually be able to switch interaction mode or device without losing the App integration, conversation state, available tools, visualizations, or continuity of the learning process.

For applications such as SkillPilot, seamless multimodal and cross-device continuity is not merely a convenience. It is one of the main reasons why ChatGPT can provide a fundamentally better learning experience.