New ChatGPT Plugin Capabilities: Sidebar Apps and File Editors

OpenAI is pushing ChatGPT from a conversational interface toward an extensible application platform. In the latest round of plugin capability updates, developers can now add sidebar apps, side panels, file editors, and native forms to ChatGPT through new UI entrypoints. This means plugins are no longer just "question-and-answer" tools—they can have persistent interfaces, operate on files alongside the conversation, and even take over the editing experience for specific file types.

Plugins Move from "Function Calling" to "Interface Integration"

In the past, ChatGPT plugins mainly took the form of defining a set of APIs that the model calls during conversation and returns text results. This pattern works well for checking the weather or searching the web, but struggles to support complex interaction flows. The new openai/ui entrypoints change this: plugins can declare where in the ChatGPT interface their UI should appear and how that UI interacts with the conversation context.

According to official descriptions, the currently available UI entrypoints include sidebar apps, side panels, file editors, and native forms. What they share is that the UI no longer pops up once and disappears—it persists as part of the ChatGPT workspace, letting users interact while they chat.

The plugin mechanism was first introduced by OpenAI in 2023. Its core idea is to let large language models obtain real-time information or perform actions by calling external APIs, thereby overcoming the time and scope limits of training data. Its technical foundation is "function calling": developers use JSON Schema to describe function names, parameters, and return values; the model decides during conversation when to call, generates parameters conforming to the structure, and the host then executes and feeds the results back to the model. This pattern is still essentially text in, text out—the model is only responsible for "deciding to call," not for "presenting an interface." For this reason, early plugins struggled to support multi-step, highly interactive workflows: all intermediate state had to be compressed into text and stuffed back into the conversation. The emergence of UI entrypoints amounts to adding a "rendering layer" on top of function calling, letting plugins store state in their own interface rather than relying entirely on conversation history.

What the Four Types of UI Entrypoints Solve

Sidebar Apps: A Persistent Workspace

Sidebar apps suit tasks that need persistent state, such as project management, to-do lists, or data dashboards. The plugin renders its own interface in the sidebar while being able to read the context of the current conversation. Developers need to declare the entrypoint type in the plugin manifest and use type-checked code to define the message protocol between the UI and the host, avoiding structural mismatches at runtime.

Side Panels: The "Second Screen" for a Conversation

Side panels differ from sidebars in that they are more tightly bound to a single conversation. A typical scenario: the user discusses a document in the conversation while the side panel simultaneously shows a preview or structured information about that document. The panel can update its content as the conversation switches, effectively giving each conversation a context-relevant auxiliary view.

File Editors: Taking Over Specific File Types

File editors are the most imaginative entrypoint in this update. A plugin can declare that it can edit a certain type of file (such as spreadsheets, code, or structured data); when the user opens such a file in ChatGPT, the interface switches to the editor provided by the plugin. This effectively turns ChatGPT into a pluggable file workbench, where third-party developers can build deep editing experiences around specific formats.

Native Forms: A Shortcut for Structured Input

Native forms let plugins present real form controls in the conversation instead of making users describe parameters in natural language. For operations with many parameters and strict format requirements (such as submitting a ticket or configuring a service), forms can significantly reduce error rates and ease the model's burden of parsing user intent.

Native forms correspond to the broader technical trend of "structured output/input." When users describe parameters in natural language, the model must perform intent parsing and slot filling; the more parameters and the stricter the format, the higher the probability of parsing failures and omissions. Form controls shift part of this uncertainty from the model side to the interface side: field types, required-field validation, and enum options are all guaranteed by the UI, so the model only needs to read the final submitted structured result. This and the JSON Schema constraints in function calling are two expressions of the same idea—one constrains the model's output, the other constrains the user's input. Combined, plugins can significantly reduce format errors along the "user fills out form → model understands → calls API" chain, and make debugging clearer: whether a problem lies in interface validation, model decision-making, or the backend API is immediately apparent.

What Type-Checked Code Means

The source material specifically mentions "type-checked code." This points to an engineering detail: the plugin UI and the ChatGPT host communicate via message passing, and the structure of those messages needs explicit type definitions. The UI SDK provided by OpenAI lets developers validate the structure of message payloads at compile time, rather than discovering missing fields or type errors only at runtime.

For developers, this lowers debugging costs and makes plugin UI behavior more predictable. For the platform, type constraints are a prerequisite for opening up UI capabilities—if any plugin could send arbitrarily structured data to the host, security and stability would be hard to guarantee.

Type checking refers to verifying at compile time or during static analysis that the types of variables, parameters, and message payloads conform to their declarations. Typical implementations include TypeScript's compile-time checks and runtime schema validation libraries (such as Zod or JSON Schema validators). In scenarios where the plugin UI communicates with the host, the two sides often run in different contexts or even different rendering processes, with messages passed through mechanisms like postMessage, so structural errors are not naturally exposed at coding time. Type checking brings such errors forward to the development stage: the message type definition becomes a "contract" that the host and plugin each implement, and any field change on either side triggers a compile-time error. This aligns with the isolation-and-contract patterns used by mature systems such as browser extensions, IDE plugins, and micro-frontends—a common engineering approach for open platforms to maintain stability while allowing third parties to inject interfaces.

Impact on the Developer Ecosystem

The signal from this round of updates is clear: ChatGPT is building its own "application layer." Concepts like sidebars, panels, and editors have long been mature in desktop operating systems and IDEs, and are now being ported into the conversational AI interface. For developers, the opportunity lies in turning tasks that "can't be solved by conversation but can be solved alongside it" into plugins—workflows that need visualization, persistent state, or fine-grained operations are exactly where UI entrypoints shine.

Challenges exist as well. UI entrypoints increase plugin complexity, requiring developers to handle both conversation logic and interface state; the interaction boundaries between different entrypoints and the context-synchronization mechanisms also need careful design. In addition, such plugins depend heavily on the host interface, so changes to platform rules directly affect plugin availability.

Conclusion

From function calling to interface integration, the capability boundary of ChatGPT plugins is expanding. The four entrypoints—sidebar apps, side panels, file editors, and native forms—cover different levels of need from persistent tools to deep editing, while type-checked code constraints provide engineering controllability for this open UI system. For developers hoping to build applications on the AI platform, now is a good time to understand and experiment with these entrypoints.