
Image: METAL
Summary
- OpenAI opened multi-account connections across most ChatGPT plugins on September 18.
- Every connected account is exposed to the model, and each tool call runs on the selected account's credentials and permissions.
- Existing plugins work unchanged, but account labels and duplicate detection need a declared profile tool.
OpenAI has opened up connecting several accounts to most plugins in ChatGPT. A work account and a personal account can sit in the same conversation, and the model picks the account that fits the request before calling a tool.
Max Stoiber, who works on plugins, MCP and Skills at OpenAI, wrote on X on September 18 that starting today you can connect multiple accounts with most plugins in ChatGPT. The screenshot attached to the post shows a single Notion plugin with two addresses side by side, kiki@acme.org and kiki@gmail.com. The post was read more than 610,000 times, and the follow-up from the official OpenAI Developers account passed 250,000.
What users touch is the plugin settings page. In the chatgpt.com/plugins directory, adding one more account to a plugin already connected is the whole flow. According to OpenAI's documentation, all connected accounts are exposed to the model, which reads the request, picks the account or accounts it needs, and then calls the tool. Every single call uses that account's credentials and permissions.
Developers, in principle, have nothing to touch. Stoiber wrote in the same post that this works automatically, with no changes needed. An MCP server already running picks up multi-account as it is.
Getting the name tags right on screen, though, means opening one more tool. It is a read-only tool that returns the profile represented by the authenticated credentials, and the name is free, whether get_profile or whoami. Marking openai/profile as true under _meta in the metadata lets OpenAI discover the tool at runtime, call it, and validate the response before using the profile data.
The contract turns on a single id field. It must be a non-empty string, and it must return the same value across token refresh, reconnection and scope upgrades. Distinct profiles must carry distinct values, and the value must stay the same when a display name or email changes. Reassigning a deleted profile's value to another profile is barred too. The documentation carries a separate line saying not to generate a new value per login, per token, per session or per tool call.
The common habit of using an email as the identifier is blocked as well. The reasoning is that an address which can change or be reassigned cannot serve as a stable profile identifier. With Google OIDC, the documentation says to use sub rather than the email claim. Names and emails belong in display fields such as name, email and nickname, and it also says not to encode names, email addresses or organizational relationships inside the identifier.
The response goes into structuredContent to be validated against outputSchema, and for compatibility the same content is also serialized as JSON in a text content item. The documentation uses a fictional service called Moonwaffle to show one person connecting two profiles separately. A personal profile at prf_42a9c6e0 and a work profile at prf_8d7e4b19 each get a different opaque value assigned once and stored, and the same value comes back across reconnection, token refresh and display-name changes.
Accounts still connect without a profile tool. The documentation notes, though, that account labels, recognition and duplicate detection become less reliable. There is also a warning that declaring one and then returning an invalid identity can block account connection outright.
The authentication section of OpenAI's developer documentation, which METAL read in full, spends a long stretch on client identity right before multi-account. ChatGPT presents an OpenAI-managed client certificate when it connects to an MCP server, and a server can check that the leaf certificate chains to the OpenAI Connectors mTLS intermediate CA and that its SAN dnsName is mtls.prod.connectors.openai.com. CIMD is the recommended client registration path and DCR is still accepted, while ChatGPT does not support machine-to-machine grants such as client credentials, service accounts or JWT bearer assertions.
For an engineer, the weight of this change sits on boundaries rather than convenience. With one account, one token was one set of permissions; now several tokens with different permissions sit in one conversation, and the thing choosing between them is the model. That is why the documentation spends three lines insisting the tool be read-only, that it never require the caller to supply a user ID, email or account selector, and that an authentication failure return an auth error instead of a placeholder ID or another account's profile. One mispaired profile is what pulls a company workspace document into a personal-account conversation.
Where responsibility sits is clear too. OpenAI attaches the access token it received to subsequent MCP requests once the OAuth flow finishes, and from there signature validation, issuer and audience matching, expiry, replay considerations and scope enforcement all belong to the server. Another line notes that passing a schema check does not prove the identifier's uniqueness or stability, nor correct credential scoping.
METAL has reported on ChatGPT driving Runway and Blender straight from the app directory, and the flow confirmed then assumed a single account per connection. Multi-account splits that connection into several strands.
The competitive axis in the plugin ecosystem is shifting from features to identity. As much as which tools a server offers, how precisely it can say whose permissions those tools run under now decides the quality of a connection. Labeling accounts properly has become a product feature.





Comments