I am filing this as a separate report because it is blocking the core interaction model for an MCP / ChatGPT app, and it looks distinct from tool-result size/truncation.
App shape:
- A ChatGPT Apps SDK / MCP widget renders an interactive reader.
- The user selects an ayah, word, or phrase inside the iframe.
- The iframe calls `ui/update-model-context` with a tiny selection-first context payload.
- The next user message is often deictic/natural: “what does this mean?”, “explain this”, “is this thunder or lightning?”, etc.
- Expected behavior: the model should answer against the latest active in-app selection.
What I can verify from the app/browser side:
- The widget sends `ui/update-model-context`.
- The payload contains the current selected phrase/reference.
- ChatGPT ACKs the update with `{}`.
- Network activity follows the update.
- App-side instrumentation shows the last published context matches the user’s latest selection.
- The payload is small; this is not a large tool result.
- We removed common app-side confounders: passive viewport context does not overwrite explicit selection, adjacent rendered pages publish their actual page data, and model context is now selection-first plain text.
Observed failure pattern:
- After a full ChatGPT page reload, the first selection-dependent question usually works.
- Sometimes the second one works too.
- After that, repeated selection changes become flaky.
- The model may say it cannot see the current selection, answer from stale context, or answer as if an older page/selection is still active.
- Opening a fresh conversation or refreshing can temporarily improve it.
Cross-surface behavior:
- Claude web works with the same app interaction model.
- ChatGPT Android works much more reliably in my testing.
- ChatGPT web, macOS desktop, and Windows desktop are the unreliable surfaces.
- In short: Claude works, Android works, everything else I have tested does not reliably work.
That cross-surface split makes this look much more like a ChatGPT host/runtime bridge or context-attachment issue than an app payload issue.
Why this is hard to debug:
- The app can observe the outbound JSON-RPC update and the host ACK.
- The app does not appear to have a supported way to inspect the model context ChatGPT actually stored or attached to the next model turn.
- A successful ACK is therefore not enough evidence that the next model request received the context.
What would help:
- A way to inspect the current stored/attached model context for a widget after `ui/update-model-context`.
- A clear error/warning if an update is ACKed but not attached to the next model turn.
- Guidance on whether repeated live iframe context updates have ordering/race constraints.
- Confirmation whether ChatGPT web/desktop and Android use different model-context bridge paths.
This feels very close to the “works after page refresh” reports others have made, except in my case the first ask after reload usually works and the degradation begins after one or two subsequent context asks.
Timing note: this appears to be a recent regression. I have observed it over roughly the last two weeks; before that, this same interaction model was working reliably for this app.