The pitch is clean: users can discover apps inside ChatGPT, connect them, and let the assistant do more than talk. OpenAI says developers can build chat-native experiences with the Apps SDK, and its help material now describes apps, custom apps, and MCP-backed tools as part of the ChatGPT ecosystem. The product direction is obvious. ChatGPT is not trying to be an answer box. It is trying to become the interface layer for work, shopping, planning, media, files, and actions.
That may be useful. It is also a new failure surface. A chatbot answer is already difficult for many users to audit. A chatbot answer that can call an outside app, read connected data, recommend an action, and steer a user through a transaction is not just an answer. It is an operating path.
The Permission Problem
App directories train users to click connect. Chat interfaces train users to trust the flow. Put those together and you get permission creep with a friendly voice. The risk is not only that a malicious app slips through review. The more ordinary risk is that a legitimate app asks for broad access, the user grants it once, and then forgets that a conversation now has pipes running into external systems.
The disaster pattern to watch
- Blurred boundaries: users may not know when ChatGPT is answering from the model versus acting through a connected app.
- Overbroad access: useful apps often want files, calendars, messages, commerce data, or account context.
- Recommendation pressure: if ChatGPT recommends apps or actions, the assistant becomes a ranking surface.
- Audit burden: users have to track which app saw which data and why.
- Commercial incentives: app discovery and featured placement can turn neutral advice into a marketplace funnel.
Review Is Not A Magic Shield
OpenAI says apps are reviewed against quality and safety standards before publication. That matters, but review does not eliminate the structural problem. App review can reject obvious abuse. It cannot make every user understand the consequences of connecting a tool, and it cannot remove the incentive for developers to request the maximum access they can justify.
This is the same lesson mobile platforms learned years ago. The permission dialog is necessary and insufficient. Most users do not read it carefully. Many cannot evaluate whether the permission is proportionate to the task. In a chat interface, the social pressure is even stronger because the assistant is actively guiding the workflow.
Why This Is Different From Old Plugins
The old plugin era felt experimental. The new app directory is more formal, more discoverable, and more tightly bound to ChatGPT's identity as a daily-use product. OpenAI's own materials describe a directory, Apps SDK, custom apps, and MCP-backed tools. That is not a side feature. It is platform architecture.
Platform architecture changes the trust model. If users treat ChatGPT as the front door, then every app behind that door inherits some of ChatGPT's trust glow whether it deserves it or not. That is the quiet danger. The user does not think "I am authorizing a third-party tool with its own incentives." The user thinks "ChatGPT is helping me do the thing."
The Safer Version
The safer version is boring and explicit. Every app action should show the app name, the data being used, the reason it is needed, and the consequence of approving it. App recommendations should be labeled as recommendations, featured placements, or paid relationships where applicable. Users should have a clean dashboard showing which apps are connected, what they can access, and when they last acted.
Without that kind of visibility, the App Directory risks turning ChatGPT into a polished permissions maze. The more useful the assistant becomes, the more important it is to know exactly when it stops being only an assistant.
Sources: OpenAI app submission announcement, OpenAI Help: Apps in ChatGPT, OpenAI Apps SDK announcement.