Clean non-config view of Plugins in Settings
Feature Request: Clean Non-Config View of Plugins in Settings
Summary
Codex should provide a clean, user-facing Settings view for installed and enabled plugins, instead of requiring users to inspect ~/.codex/config.toml to understand which plugins are active.
Problem
Right now, plugin state appears to be discoverable only through local configuration, for example:
[plugins."figma@openai-curated"]
enabled = true
That is technically accurate, but it is not a good product surface. Users should not have to open config.toml to answer basic questions like:
- Is the Figma plugin installed?
- Is it enabled?
- Which account or auth connection is it using?
- Is this the same thing as a Connector?
- Is this related to Hooks?
The current terminology also makes the product feel ambiguous. Plugins, Connectors, and Hooks sound similar enough that users can reasonably assume they are overlapping names for the same thing, even though they represent different concepts.
Requested Feature
Add a clear Plugins section in Codex Settings that shows installed and enabled plugins without requiring config-file inspection.
Suggested placement:
- Settings -> Plugins
- Or Settings -> Integrations -> Plugins, if Codex wants Plugins, Connectors, and Hooks grouped under a broader integrations model
Proposed Behavior
For each plugin, show:
- Plugin name, for example
Figma - Plugin id, for example
figma@openai-curated - Enabled/disabled state
- Marketplace/source, for example
openai-curated - Installed/cache status
- Related auth status, when applicable
- A short explanation of whether the plugin uses or depends on a Connector-style account connection
For Figma specifically, the Settings view should make it possible to see both:
- The plugin is enabled
- The Figma account connection is active, including the connected account when available
Clarify Product Vocabulary
Settings should distinguish these concepts directly:
- Plugins: capability bundles that add tools or workflows to Codex
- Connectors: account/data connections used to access external services
- Hooks: lifecycle scripts or automations that run at specific events
The UI does not need a long explanation, but it should make the distinctions visible enough that users do not need to infer the model from config files.
Acceptance Criteria
- A user can confirm whether Figma is installed and enabled from Settings.
- A user can see the plugin id/source without opening
config.toml. - A user can distinguish Plugins from Connectors and Hooks in the Settings UI.
- If a plugin has an external account connection, Settings shows the connection/auth state or links directly to where that state is managed.
config.tomlremains an implementation detail, not the primary discovery surface for ordinary plugin state.
Why This Matters
This is a trust and operability issue. When a user connects a tool like Figma, they need a clear place to verify what was enabled and what account is connected. Requiring config-file inspection makes the feature feel hidden and makes product vocabulary harder to understand.