ChatGPT Apps SDK: Developers Flag Security and DX Friction

A platform launch meets its first users

OpenAI's pitch at DevDay 2025 was ambitious: ChatGPT would stop being just a chatbot and become a platform, with a new Apps SDK and Agent Kit letting developers build interactive apps and autonomous agents inside the conversation window 5. Coverage at the time framed it as ChatGPT becoming "the new app store" 5. A month earlier, OpenAI had already added support for the Model Context Protocol (MCP) in ChatGPT's developer mode, a capability VentureBeat characterized as "powerful but dangerous" 5.

Now that developers have actually started building, a more textured picture is emerging. The early feedback is not hostile. But it is pointed, and it clusters around two themes: who sees what data, and how painful it is to ship a working app.

The security question

OpenAI's own documentation is candid about the stakes. It notes that the SDK gives developer code access to user data, third-party APIs, and write actions, and it urges builders to treat every connector as production software 1. The guidance leans on familiar principles: least privilege, explicit user consent for account linking and write access, and defense in depth that assumes prompt injection and malicious inputs will reach the server 1. It also warns that developer mode enables full MCP access, including write tools 1. On data handling, it advises keeping secrets out of component props, publishing retention policies, and redacting personally identifiable information before logging 1.

That is sensible advice, but it places much of the burden on developers. Community discussion shows users and builders probing exactly where that burden lands. On r/OpenAI, one commenter asked whether using an app means sharing conversation data with third-party developers. Another replied that app guidelines limit developers to basic data such as clicks 2. Others were less reassured. One participant said that routing data from many apps through OpenAI's servers made them uneasy. They also suggested that established companies with their own chatbots might hesitate to join 2.

The sharpest warning compared the ecosystem to mobile app stores, where questionable apps regularly slip through. That commenter argued personal users will need to police their own "context hygiene," while business accounts at least have admins who can restrict integrations 2. Their key point was that models reason while ingesting input. A malicious app's output might not just run but subtly shape the model's conclusions 2. That is a different threat model from a rogue mobile app, and arguably a harder one to audit.

The developer-experience question

The second set of complaints is more practical. A developer who documented building a to-do app with React and Vite described the auth model as an inversion. You aren't logging users into ChatGPT. You are authorizing ChatGPT into your system on the user's behalf 3. They called the iteration loop frustrating. Either every tweak requires a rebuild, upload, and refresh, or relative asset paths break because the SDK prefers absolute, versioned URLs 3. Their conclusion was that OpenAI's hosting requirements make sense for security but create real friction. Even so, they called the SDK a promising first attempt with docs that are clearly a work in progress 3.

Gadget's write-up is blunter. It says ChatGPT accepts only a plain HTML document for widgets, with no built-in support for TypeScript, Tailwind, or asset bundling. Developers must bundle and serve client-side apps into a cross-origin iframe, a process Gadget calls finicky and hard to debug 4. More consequential is its claim that the OAuth token ChatGPT obtains does not appear to be available inside the widget iframe. That leaves developers unable to identify which user is viewing a widget. Gadget considers this a missing SDK function and has filed a GitHub issue about it 4. The company does credit the official MCP TypeScript SDK and OpenAI's examples repo as reasonable starting points 4.

Reading the tension

The two strands are connected. Many of the developer-experience pain points, such as strict headers, absolute URLs, sandboxed iframes, and tokens kept out of the client, look like deliberate security choices. That interpretation is consistent with OpenAI's documented emphasis on keeping secrets out of component props 1. In effect, OpenAI appears to have prioritized containment over convenience.

That is probably the right call for a platform that can take write actions on users' behalf. But it doesn't remove the deeper risk community members raised: prompt injection that shapes model reasoning, which no iframe can fully sandbox 2. The likely path forward is better tooling to close the DX gaps, alongside sustained scrutiny of how OpenAI reviews and polices apps. Whether ChatGPT becomes a trusted app store or a messy one will depend more on the second than the first.