**EDIT (May 25, 2026): Resolved — see update below.**
We’re debugging a published ChatGPT app (“Priority Guardian”) and are trying to understand whether other developers are seeing similar behavior, especially for apps approved before the April 28 snapshot/cache changes.
What we’re seeing:
_meta.ui.csp.connectDomains and legacy openai/widgetCSP.connect_domains appear ignored in the published runtime
iframe fetches to our declared backend domain are still CSP-blocked
after full disconnect/reconnect, our MCP logs show fresh ReadResourceRequest calls returning the newly deployed bundle (~364 KB)
BUT the iframe still appears to load the same main-*.js asset from web-sandbox.oaiusercontent.com
difficult to verify which bundle is actually executing
repeated ChatGPT internal runtime errors:
/backend-api/ecosystem/call_mcp 404
QuotaExceededError ... system-connectors exceeded the quota
We also noticed:
fullscreen/displayMode behavior became unstable recently (fullscreen flashes briefly then collapses)
onboarding becomes hard/impossible in condensed mode for new users
Questions for other Apps SDK developers:
Are connectDomains / connect_domains currently working for published apps?
Have you seen stale widget/runtime behavior after redeploys?
Did apps approved before April 28 behave differently after the snapshot/cache loosening?
Has anyone found a reliable way to force widget propagation/cache invalidation without resubmission?
Has anyone seen the system-connectors exceeded the quota error correlated with widget/runtime instability?
We already opened a formal support ticket with OpenAI. Mainly trying to determine whether this is isolated to our app or a broader published-runtime issue.
Thanks everyone who looked at this. Updating to save people time:
Resolved:
The fullscreen flash-revert was a bug in my own widget code, not a platform issue. My desktop “fullscreen” was implemented as local React state only (no requestDisplayMode call), while my openai:set_globals handler unconditionally synced local displayMode from window.openai.displayMode. On desktop the host’s displayMode stays 'inline', and a set_globals(inline) burst fires ~5ms after the Expand click — the sync handler ran and reverted local fullscreen. Fix: persistent desktop-only intent flag that causes the sync handler to ignore hostMode === 'inline' while the user is in local fullscreen. Verified in production.
Bundle propagation actually works. My “stale runtime” symptoms were ChatGPT-side iframe caching that didn’t clear via disconnect/reconnect alone. Fully deleting and re-adding the app in dev mode invalidated the cache and the new bundle loaded immediately. After that, every server deploy propagated within minutes without resubmission. So the freeze model I was assuming (URI frozen → bytes frozen → resubmission required) was wrong — only the URI string is frozen at approval, the bytes behind it serve fresh on every deploy.
Still open / unconfirmed:
Whether _meta.ui.csp.connectDomains and openai/widgetCSP.connect_domains are honored by the published runtime. I’ve worked around it by routing widget->backend through callTool instead of direct fetch, so I no longer need the declarations to work for my own app — but I haven’t confirmed they actually function for anyone.
The /backend-api/ecosystem/call_mcp 404 and system-connectors exceeded the quota errors. Still showing in console. No correlation found with my widget behavior after the fullscreen fix shipped. Possibly host-internal, not app-side.
If anyone has data on #1 or #2, still interested. Otherwise no further help needed on the original post.
I used Deep Research to explore a related idea, and it surfaced several relevant documents—some I had not seen before, and others I had seen but should have reviewed more closely.