Internal tools as ChatGPT plugin extensions: who approves what

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

ChatGPT plugin extensions let a team put an internal tool inside ChatGPT and Codex as a sidebar app, a panel beside the conversation, or a viewer for a file type. OpenAI launched them at DevDay on 29 September 2026 for all plans. Sam Altman described the aim as letting builders put an editor, a dashboard or a whole workspace directly into both products. The extensions documentation covers the build side; this guide covers the approval, access and ownership side.

The decision for a leader is not whether the technology works. It is whether your organisation is ready to run an internal tool that an AI model can open, read from and act through.

When is an internal tool a good plugin candidate?

A tool is a good candidate when people already copy information between it and ChatGPT or Codex. Examples are a release dashboard, a runbook viewer, a design review board, or an editor for a file format your engineers use.

It is a poor candidate when its main value is write access to a system of record and nobody owns the review of those writes. Extensions make the tool easier to reach. They do not make its actions safer.

OpenAI's own architecture guide gives a useful filter. Add UI when people need to inspect, compare, edit, confirm or move through information. A background status lookup usually does not need a panel. Start with the smallest plugin shape that supports the use case.

What ChatGPT plugin extensions change for access

Extensions sit on top of an MCP server that your team runs. A sidebar app or conversation panel opens your MCP App fullscreen. A file viewer opens when a user opens a matching file. Plugins with UI may also embed pages from the MCP server's own registrable domain, which OpenAI's security guide says can include existing editors and admin interfaces.

That last point deserves a security review. The widget's content security policy limits which iframe origins can load. OpenAI notes that it does not restrict network requests made inside the embedded page. If you embed an admin interface, your normal access controls for that interface still carry the load.

Platform reach also varies. File viewers and composer mentions work only in the ChatGPT desktop app at launch. Web extensions for Free and Go users are listed as coming soon. Plan pilots on the surfaces your team actually uses.

The capability chain your admins control

OpenAI's plugin controls guide splits access into layers. Each layer has its own switch:

The guide is explicit that making a plugin available does not grant access to files, records or actions in the connected service. Installing a plugin for everyone does not provide a shared account either. Approve each layer separately and write down who did.

How internal plugins reach your people

There are four distribution paths, and they carry different risks.

1. Developer mode: a builder connects an MCP server for personal testing. OpenAI notes that developer mode enables full MCP access, including write tools.
2. Repo or personal marketplace: a JSON catalog in the repository or home directory lists plugins for local clients such as Codex.
3. Workspace publishing: a workspace admin publishes a plugin to selected roles. It stays inside your workspace and does not reach the public directory.
4. GitHub marketplace import: an admin imports a marketplace from GitHub under Admin, then Plugins, and it syncs daily.

The GitHub path needs a review habit. OpenAI's plugin management guide says future syncs automatically add any new plugins in the repository. Review repository changes before merging them. Deleting the marketplace in ChatGPT deletes every plugin imported from it. Imported plugins that declare MCP servers in mcp.json are marked desktop only.

Admins who do not want workspace publishing yet can switch it off with features.plugin_sharing = false in requirements.toml.

An ownership record for every internal plugin

OpenAI's guide recommends recording five things for each connected service. Use them as your minimum record:

• The business owner.
• The data the plugin may access.
• The approved read and write actions.
• The authentication method.
• A support or removal contact.

Add two of your own: the engineer who owns the MCP server code, and the date of the next access review. A plugin without a named owner becomes shadow tooling the moment its builder changes teams.

A rollout checklist

1. Pick one internal tool and one team that asked for it.
2. Build the plugin with read actions only, and keep the tools useful without the UI.
3. Fill in the ownership record before anyone outside the build team installs it.
4. Publish to one workspace role, not the whole workspace.
5. Test with an account that has only the intended permissions in the connected service.
6. Review after a fixed period, then decide on write actions with a documented recovery path.

What should you measure?

Measure whether the tool shortens real work, not how often people open the panel. Compare time from request to accepted result before and after, and track active review time. Count actions a person had to undo. Our guide to measuring an AI workflow before scaling sets out the method.

If teams build these plugins with coding agents, the review step matters twice: once for the plugin code, once for what the plugin does in use. Our AI training for teams practises both on your own tools, and the free Delegate, Review, Own guide explains the approach.

Next step: list the internal tools your people already paste into ChatGPT or Codex, and pick the one with the clearest owner.

Further reading

• OpenAI docs: Plugin extensions
• OpenAI docs: Plugin controls
• OpenAI docs: Plugin management and GitHub sync
• OpenAI docs: Plugin security and privacy