{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigeustlqcsz7e5cji6adip6cwtz5cxpnhosjclzrlrucoiogyyqce",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mkaorm7sayl2"
  },
  "path": "/t/chatgpt-android-skips-resources-read-for-mcp-widgets-text-renders-widget-stays-blank/1379702#post_1",
  "publishedAt": "2026-04-24T13:44:51.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "chatgpt.com"
  ],
  "textContent": "Hi everyone,\n\nWe maintain a published ChatGPT App (approved, live on the store, Apps SDK /MCP protocol). After the recent GPT-5.5 / Android app rollout we’re observing a very specific regression scoped to the native ChatGPT Android app. Sharing server-side evidence in case other developers can confirm.\n\n## ENVIRONMENTS\n\n  * Desktop ChatGPT (macOS/Windows app + web)\nFull flow works, widget renders correctly.\n\n  * Mobile browser (Android Chrome → chatgpt.com)\nFull flow works, widget renders correctly.\n\n  * Native ChatGPT app on Android\nBuild: ChatGPT/1.2026.104\nWidget area stays blank / black.\nText content (structuredContent) of the tool response is displayed\ncorrectly, so the user gets a reply — but no UI card.\n\n\n\n\n## WHAT THE SERVER SEES\n\nOur backend is a standard MCP server (JSON-RPC 2.0 over HTTP) with full\nrequest logging.\n\nWhen a user prompts from the Android app:\n\n  1. POST /mcp → tools/call arrives correctly, with:\n_meta.openai/userAgent = “ChatGPT/1.2026.104 (Android 16; …)”\nTool handler runs. 200 OK returned. Response body contains the full\npayload, including:\n\n     * content (text block, rendered in the chat)\n     * structuredContent\n     * _meta.openai/outputTemplate = ui://widget/.html\n  2. No follow-up resources/read request arrives for the ui://widget/… URI\nreferenced in outputTemplate.\n\nCompared to the same user flow from desktop or mobile browser, which do\nhit resources/read immediately after tools/call, the Android app silently\nskips this step.\n\n\n\n\nThe pattern\n\n\n    tools/call  -> text ok\n    resources/read -> never sent\n\n\nis consistent across every invocation we’ve observed from Android over the\nlast hour.\n\nSame user, same OAuth session, same MCP server, same tool descriptors, same\noutputTemplate URI as what works on desktop — only the Android client refuses\nto fetch the widget resource.\n\n## WHAT RULES OUT SERVER-SIDE CAUSE\n\n  * Desktop client and mobile browser successfully resources/read the same\nui://widget/… URI in the same time window. Widget resource is served\nfine, MIME text/html;profile=“mcp-app”, CSP/CORS headers consistent with\nwhat has been approved and in production for weeks.\n\n  * The Android request for tools/call lands on the exact same backend and\nreturns a valid response. Nothing in CORS, sandbox, or auth would\nselectively block only a follow-up resources/read (it would use the same\nsession/origin).\n\n  * Behavior is present on both our approved production app and our dev build,\non two completely separate backends with different hostnames. The only\ncommon factor is the Android client build.\n\n\n\n\n## QUESTIONS\n\n  1. Is anyone else with a published MCP app observing this on Android\n1.2026.104? Specifically: does your chat text render from tools/call but\nthe widget stay blank?\n\n  2. Is there a known feature flag on the Android client that gates the\nresources/read / widget renderer path? Any early reports of a change in\nhow outputTemplate is consumed on mobile after GPT-5.5?\n\n  3. Any server-side signal the Android client passes that we could correlate\nwith the missing fetch (e.g. a header indicating Apps SDK renderer\nversion)?\n\n  4. A workaround beyond “use chatgpt.com in Chrome” would be very appreciated\nif any dev has found one.\n\n\n\n\nHappy to share anonymized request traces or manifest details privately with an OpenAI Apps SDK engineer for triage.\n\nThanks.",
  "title": "ChatGPT Android skips resources/read for MCP widgets — text renders, widget stays blank"
}