---
type: analysis
slug: a-plugin-surface-is-not-a-distribution-channel
title: "A plugin surface is not a distribution channel"
description: "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."
published_at: 2026-10-08T08:00:00.000Z
topics: ["workflow","design","mcp"]
source_urls: ["https://developers.openai.com/plugins/build/extensions","https://help.openai.com/en/articles/10128477-chatgpt-enterprise-and-edu-release-notes"]
author: "Andrey Reshetnikov"
author_profile: https://newruntime.com/owner-profile.md
---
# A plugin surface is not a distribution channel

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?

## Sources

- [Build richer, more interactive plugins for ChatGPT.](https://developers.openai.com/plugins/build/extensions)

- [ChatGPT Enterprise and Edu release notes | OpenAI Help Center](https://help.openai.com/en/articles/10128477-chatgpt-enterprise-and-edu-release-notes)

- [Introducing apps in ChatGPT and the new Apps SDK | OpenAI](https://openai.com/index/introducing-apps-in-chatgpt/)

- [The State of Enterprise AI | OpenAI](https://cdn.openai.com/pdf/7ef17d82-96bf-4dd1-9df2-228f7f377a29/the-state-of-enterprise-ai_2025-report.pdf)

- [Build with the Apps SDK](https://help.openai.com/en/articles/12515353-build-with-the-apps-sdk)

- [Getting Started with Custom Connectors Using Remote MCP](https://support.anthropic.com/en/articles/11175166-getting-started-with-custom-connectors-using-remote-mcp)

- [Add MCP apps to declarative agents in Microsoft 365 Copilot](https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/plugin-mcp-apps)

- [Plugin UI changelog – Plugins | OpenAI Developers](https://developers.openai.com/plugins/changelog)

- [OpenAI MCP Extensions – GitHub](https://github.com/openai/mcp-extensions)

Author: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json