Picture a ChatGPT conversation that has outgrown the chat box. You asked an assistant to pull parts from a product library, and now you want to look at the results, pick one and keep talking about it, without scrolling through text. That is the gap OpenAI says plugin extensions are meant to close.
What plugin extensions are, and where they show up
A plugin, in ChatGPT, is a package that connects an outside product to the assistant through an MCP server. MCP (Model Context Protocol) is the open standard that lets an assistant call tools in another system. Until now, a plugin mostly worked behind the conversation. Plugin extensions let developers hook the plugin into visible parts of ChatGPT itself. According to OpenAI’s developer documentation, those parts are the sidebar, conversation side panels and file viewers, plus composer mentions, plugin onboarding and plugin settings. TechCrunch’s report on the DevDay announcement describes the same core: a dedicated home in the sidebar, interactive panels you can use while chatting, and viewers for the file formats a product works with.
In practice that means three different ways to meet a plugin. A sidebar app opens full screen from the global sidebar, like a small app inside ChatGPT. A side panel opens next to a conversation, so the tool and the chat stay visible together. A file viewer opens a supported file type in the plugin’s own interface, with reading, live updates and saving. Composer mentions let you search a plugin’s content from the message box and attach what you find, onboarding walks a new user through setup, and plugin settings let you configure product-specific options without leaving ChatGPT.
How a developer adds a sidebar, a panel or a file viewer
The interface part rests on MCP Apps, the open standard for user interfaces returned by an MCP server. Extensions reuse that. The developer registers a UI resource, points a tool at it through ui.resourceUri, and then lists entry points in the tool’s metadata. A global entry point creates the sidebar item, a thread entry point opens the app beside a conversation, and a file entry point declares which file extensions the app can open, for example stl for 3D model files. OpenAI provides a TypeScript SDK for the server and the app interface and a Python SDK for the server-side parts, with typed metadata available from @openai/mcp-extensions/server.
The detail worth noticing is how small the change is. Teams that already have an MCP App do not start over; they add configuration that says where the existing interface may appear. The documentation does not describe the work needed for composer mentions, onboarding or settings on the page we reviewed, so treat those as separate pieces to read up on.
Who can use them today, and the limits
OpenAI’s documentation says plugin extensions on the web are coming soon to ChatGPT Free and Go users, while existing plugin functionality is unaffected. Composer mentions work only in the ChatGPT desktop app. Extended message sending, which lets a plugin start a message in a new conversation, is available on desktop and in Work on the web. TechCrunch’s account does not say which plans or regions get the features or what usage limits apply, so anyone planning around a specific plan should check their own account rather than assume.
What it changes for people who use ChatGPT
Facts first: OpenAI is giving outside tools permanent places in the ChatGPT interface instead of only text replies. My reading of that, which is an inference and not something the sources state, is that it shifts where work happens. A text answer is finished the moment it scrolls away. A panel next to the chat stays put, so you can inspect a result, change it and ask a follow-up about the same thing. There’s a simpler handoff here: the assistant does the fetching and drafting, and you keep the visible decision in front of you.
There is a trade-off I would weigh before building on it. Every surface above is specific to ChatGPT, and the limits already differ by platform: composer mentions only on desktop, web access still rolling out to free plans. A developer who builds the panel as the only way to use a plugin risks leaving some users with a worse experience. A sensible order is to keep the plugin useful as plain tools first and treat the sidebar, panel and viewer as additions. The question to ask for each feature is the practical one: which step in your product really needs a screen, and which can stay a sentence?
