Apps in ChatGPT: how connections, permissions, and plugins work

What an app can do

OpenAI's Apps in ChatGPT guide describes apps as connections to external tools, information, and actions. An app may show interactive cards, search a connected service, support cited deep research, or sync content in advance. The capability is defined by that app, not by a generic “app” label.

This matters for business use. A connected app can be useful for finding a document or looking up a message, but it does not automatically create a production support workflow. Before relying on an action, identify its data scope, the identity that authorizes it, what approval is required, and what happens if it fails.

Connect an app deliberately

Open the Plugins tab, inspect the plugin's details, and install it with the plus button. Connect the external service when prompted, then start a new chat. Describe the job or use @ to select the installed plugin. These are the steps in OpenAI's current plugin guide; sign-in and permissions remain separate from installation.

For example, after connecting an authorized document account, ask for the current shipping-policy document and its source link. Check the returned document before relying on its answer. Installing a plugin does not give its connected account access to files that account could not otherwise read.

When the job ends, review both the plugin and its connections. Uninstalling a plugin does not disconnect its bundled connectors. Manage the remaining connections separately, and check the provider's retention policy for data already shared.

Availability can depend on the plan, region, surface, account, and workspace policy. In a managed workspace, an admin may need to enable the plugin or grant the user's role access to its connector. OpenAI also notes that app permissions are separate from Memory, personalization, retention, and model-improvement settings.

Review app access before a business rollout

Start with one read-only job. For example, ask an app to find a policy document and verify that the result is the right file, from the expected account, with the expected citations. Then test a denied permission, a missing file, and the account-disconnect path. Do not treat a successful first search as proof that the app should be allowed to act on customer data.

Operate a connected support teammate with eesel CLI

The same question—what can this connection read or change?—matters when configuring a support teammate. With eesel's CLI, a support owner can ask Claude Code, Codex, or Cursor to inspect the teammate's connected knowledge and instructions, then propose how it should handle a billing question. The commands operate the same eesel workspace and teammate as the dashboard; a person or script can run them too.

Suppose you want the teammate to explain duplicate charges without promising a refund. Inspect connected sources and instructions with the CLI; confirm actual action permissions in the dashboard and connected service with the workspace owner. The integration list is not a complete permission audit. Use a teammate authorized for this review and replace billing-support below. Node.js 18.17+ is required. The fictional prompt does not isolate the workspace: chat is real, billed work, and a request not to act is not a permission boundary.

npx @eesel/cli instructions --agent "billing-support"
npx @eesel/cli integrations --agent "billing-support"
npx @eesel/cli new --name "billing-access-review" --agent "billing-support"
npx @eesel/cli chat "Fictional policy for this review: explain that a duplicate-looking charge needs billing-team review; ask for the invoice ID, never full card details; do not promise a refund. A customer says they see two charges but has no invoice ID. Draft a reply and identify any instruction gap. Do not send messages, modify configuration, or approve actions." --agent "billing-support"
npx @eesel/cli activity --agent "billing-support"

The coding agent can read the JSON reply and activity, flag a refund promise or request for card details, and show the precise instruction edit it recommends. The owner checks that proposal against the real billing policy before approving any write. Inspect command help and use --dry-run where supported; held-action approvals do not cover every command.

After an approved change, start fresh tests with an invoice ID, without one, and with a direct request for a person. Then check delivery and billing-team routing in the actual helpdesk channel. This turns connection access into a reviewable support workflow, instead of assuming that a connected tool is ready for every customer request. Learn about eesel for Zendesk or try eesel.