With the switch to the MCP App bridge, the implementation of the follow Up Message has changed on chatGPT (compared to the previous window.openai.sendFollowUpMessage).
The message is now visible in the chat where it wasn’t before.
This might be by design but is a UX regression, if the app tries to pass some hard to digest content to the model for summarization.
Exemple here:
(follows up a long list of questions/answers)
We have designed a lot of apps with this invisible followUpMessage in mind.
Is this intended ? If so we are losing a nice UX feature for MCP apps.
If this is intentional, I would document it as a change in privacy/UX semantics rather than only an implementation detail.
A practical workaround is to split the payload into two paths: keep the visible follow-up short and user-readable, then pass the bulky state through a tool/resource reference that the model can fetch by id. That avoids putting a long internal questionnaire or serialized app state into the transcript while still making the next model turn deterministic.
For debugging the regression, I would also test three cases separately: a tiny follow-up string, a long but human-readable follow-up, and a compact id that points to server-side state. If only the long payload creates the bad UX, the app can degrade locally; if all follow-ups are now transcript-visible, developers probably need a documented replacement for the old invisible control-message pattern.
