Make Codex App plugin install/auth local-only by default, and separate "plugins" (local) from "connectors/apps" (account-level)

What variant of Codex are you using?

App (the underlying plugin/connector model is shared with the CLI/IDE)

What feature would you like to see?

Installing a curated/remote plugin (e.g. the Notion plugin) through the App's "add plugin" → OAuth flow does not create a local, per-machine credential. It creates an account-level connector/app grant that is stored server-side and bound to the ChatGPT account — not to the machine or the project.

Observable behavior (from the open-source code + local artifacts):

• The plugin bundle's .mcp.json points to a remote server (e.g. https://mcp.notion.com/mcp) and .app.json registers an account-side app id (asdk_app_…). Installing it is a server-side mutation — a POST {chatgpt_base_url}/ps/plugins/{plugin_id}/install authenticated with the ChatGPT account token (core-plugins/src/remote.rs).
• The connector's tools are served by the remote codex_apps server (…/backend-api/wham/apps) via McpServerAuth::ChatGpt, and accessibility is keyed by account_id / chatgpt_user_id (codex-mcp/src/mcp/mod.rs, core/src/connectors.rs). No per-connector token is written locally — only metadata/cache.
• The grant is therefore live on every device signed into the same account and can only be revoked from ChatGPT account settings. Disabling the plugin locally does not revoke it (see #28941: [plugins."…@openai-curated"] enabled = false still triggers the OAuth/connector).

The problem: a local action ("make this tool available in this Codex install") silently mutates account-level state ("my whole account is now connected to this service, on every device"). For a coding tool, most users expect per-project / per-machine setup to stay isolated from the account itself. The current design conflates the two.

Requested change — keep the two concepts strictly separate, and default to local:

1. Default plugin install/auth to local, per-machine, reusing the credential storage the CLI already has (codex mcp login → OS keychain / CODEX_HOME/.credentials.json). Adding a plugin should not create an account-wide connector by default.
2. Keep account-level connectors/apps as a distinct, explicitly opt-in path, clearly labeled in the UI as "authorizes your ChatGPT account / available on all your devices," so it's always obvious whether you're granting account-level or local access.
3. Make local disable/remove actually revoke — or at minimum clearly surface that a connector grant lives on the account and link to where to revoke it (#28941).

The local model already exists for CLI MCP servers, so this is mainly about making the App's "add plugin" flow use/offer it and separating the labeling — not building something new.

Additional information

Related: #28941 (local enabled=false doesn't revoke the connector) and #20500 (multiple named accounts / "hard privacy boundaries" for connectors). This is the broader design ask behind both — cleanly split plugin = local, per-machine, per-project from connector/app = account-level, server-side, cross-device, with local as the default.