OpenAI’s documentation gives MCP apps more places to meet ChatGPT users, including a sidebar and supported file workflows. The meaningful shift is the interface option—not proof that users can reach it or will return to it.
Summary
OpenAI’s plugin documentation describes extensions that can appear in sidebars and conversation panels, offer settings and file viewers or editors, and add composer mentions. It also outlines deep links, context sharing, forms and onboarding. These options let developers design beyond chat-invoked tools, but the documentation does not establish broad availability, adoption or sustained use.
What happened
The documented model lets developers declare extension metadata for MCP apps and use the linked SDKs and protocol specification to define entry points and interface behavior. A concrete workflow change: instead of asking ChatGPT to invoke a tool in a message, a user could open an app from a sidebar while working in ChatGPT. OpenAI also lists file viewers and editors, which could place an app alongside supported file work. But composer mentions are limited to the ChatGPT desktop app, and web extensions for Free and Go users are described as coming soon, without a dated commitment. OpenAI says existing plugin functionality is unaffected. These are documented options, not evidence that each surface is live for every user.
What the archive adds
The archive contains an earlier OpenAI plugin-extension reference but adds no independent evidence about reach or use. The dossier says OpenAI frames embedded apps as a response to the limits of tool-only chat (d3), a rationale that supports the interface shift but does not show that users adopt it. According to OpenAI’s enterprise report, weekly Enterprise messages and use of Custom GPTs and Projects have increased; those figures concern broader workflow activity, not these extensions specifically (d4).
Trend signal
Assistant integrations are gaining interface choices beyond a tool call in a chat transcript. That creates a distinction builders should keep clear: a documented surface is a design capability; availability, eligibility and repeat use determine whether it is a channel. A sidebar may make an app easier to reach during a task, but it cannot by itself guarantee discovery or adoption. The source provides no extension-specific usage evidence.
Why now
OpenAI’s primary documentation describes sidebar, panel and file-related extension options, making interface-led MCP workflows a concrete design possibility. According to the dossier, OpenAI presents embedded apps as addressing limits of tool-only chat (d3), providing a product rationale rather than proof of demand. According to OpenAI’s enterprise report, repeatable workflow use is growing broadly, but those figures do not establish demand for these specific extensions (d4).
Connections to other events
The second-order effect, if users adopt these surfaces, is that an MCP app could become part of a recurring workflow rather than a tool summoned for a single answer. A sidebar entry could let a user open the app directly instead of composing an invocation each time. That possibility depends on the surface being available to the user and the app’s actions being usable under the relevant permissions. The documentation establishes neither broad reach nor sustained attention, so builders should not treat the sidebar as distribution already secured.
Why it matters
For builders, the useful question is whether a persistent entry point removes a real step from an existing workflow. For buyers, the existence of an extension does not mean every employee can access it: verify the supported surface and eligibility before planning around it. Keep the underlying MCP workflow useful without the new interface, so a constrained rollout does not strand the product.
What happens next
- OpenAI will publish a dated availability update for web extensions for Free and Go users. (3 months, 60%). Watch for: An official dated release note or documentation update specifies availability for those plans.
- OpenAI will publish at least one additional official example of an extension workflow using a documented surface, without reporting extension-specific adoption metrics. (6 months, 55%). Watch for: An official example or documentation update illustrates a surface workflow but provides no extension-level usage or retention data.
Limits and uncertainty
The primary evidence is documentation, not a rollout report or usage study. It gives no adoption, retention or performance figures, and “coming soon” is not a dated availability commitment. The source also does not establish that the sidebar or file surfaces will be available across plans or hosts. This take would be too cautious if OpenAI quickly expands access and users demonstrate repeated use.
Skill to build now
Practice workflow mapping against a confirmed surface: sketch one recurring task as a sidebar entry, the action it enables, and the context it requires. Then check whether that sidebar extension is available in the ChatGPT environment your intended users actually use before implementing around it.
Reader takeaway
This week, map one recurring MCP task to the documented sidebar entry point: write down what the user must do to open the app, what action they take there, and what context it needs. Before promising the workflow, check whether the sidebar extension is available in your target ChatGPT environment; keep chat invocation as a fallback.
Open question
Will a sidebar or file surface earn repeat use because it removes friction, or will eligibility and availability limits keep these interfaces from becoming meaningful distribution?