Implement Codex Plugins same as Claude Plugins

[styler-ai]

What feature would you like to see?

I would like to see Codex plugins. This way one could share complete Codex setups including all skills, rules, agents.md within a team that work on the same project.

See
https://code.claude.com/docs/en/plugins

Additional information

No response

[SteveBronder]

+1 to this. I have been using claude plugins + hooks recently and they are so nice.

[styler-ai]

Any update?

[nicce17]

Is this thing on? Shaun Tyler ***@***.***> schrieb am Mi. 14. Jan. 2026 um 22:09:

…

*styler-ai* left a comment (openai/codex#8512) <#8512 (comment)> Any update? — Reply to this email directly, view it on GitHub <#8512 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJWMI4GW4UKLIZDBMM6WGP34G2WAHAVCNFSM6AAAAACP5TT42GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJRG4ZDGMRUG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[etraut-openai]

If you'd like to see this feature, please upvote it (add a thumbs-up reaction). We generally prioritize feature work based on upvotes.

[styler-ai]

If you'd like to see this feature, please upvote it (add a thumbs-up reaction). We generally prioritize feature work based on upvotes.

I think that Plugins are essential no matter the up vote. They are trending on every reddit chat and tiktok video currently

[yu-iskw]

Codex Plugin System v1 Plan

Summary

Build a Claude-like plugin feature in Codex using a new plugin.json package format, while reusing existing Codex skill and MCP infrastructure for fast delivery and low risk.
v1 will support discovery, install, enable/disable, updates, dependency checks, and invocation through MCP-backed capabilities only (no arbitrary plugin runtime).

Scope

• In scope:
  • New plugin packaging format and lifecycle.
  • Plugin install/update/remove commands and app-server APIs.
  • Plugin metadata in TUI/app-server for discoverability and invocation.
  • MCP dependency registration and policy-gated execution.
  • Backward-compatible bridge from existing skills.
• Out of scope (v1):
  • Arbitrary plugin code execution/runtime.
  • Revenue/paid marketplace.
  • Cross-plugin direct IPC.

Architecture (Target)

flowchart LR
U[User / IDE / TUI] --> AS[app-server]
AS --> PM[Plugin Manager]
PM --> PR[(Plugin Registry Cache)]
PM --> PI[(Installed Plugins Store)]
PM --> SM[Skills Loader/Injector]
PM --> MM[MCP Server Manager]
MM --> MCP[MCP Servers]
SM --> AG[Agent Turn Builder]
AG --> MODEL[Model]

Loading

sequenceDiagram
participant C as Client (TUI/IDE)
participant AS as app-server
participant PM as Plugin Manager
participant REG as Remote Registry
participant FS as Plugin Store
participant MCP as MCP Manager

C->>AS: plugin/install {id,version?}
AS->>PM: resolve + download + verify
PM->>REG: fetch manifest + bundle
PM->>PM: signature/hash/policy checks
PM->>FS: write plugin files
PM->>MCP: register declared MCP deps
AS-->>C: plugin/install response
C->>AS: plugin/enable {id}
AS->>PM: set enabled=true
AS-->>C: plugins/update event

Loading

flowchart TD
A[User prompt includes @plugin or plugin command] --> B[Plugin resolver]
B --> C[Enabled?]
C -- no --> X[Return actionable error]
C -- yes --> D[Dependency checker]
D --> E[MCP dep available/authenticated?]
E -- no --> F[Emit request_user_input/setup guidance]
E -- yes --> G[Inject plugin skill instructions]
G --> H[Model tool planning]
H --> I[MCP tool calls under existing policy]

Loading

Public Interfaces and Type Changes

1) New plugin manifest format

Add plugin.json at plugin root:

{
  "schemaVersion": "1",
  "id": "org.example.repo-assist",
  "name": "Repo Assist",
  "version": "1.2.0",
  "description": "Repository workflows and code search helpers",
  "authors": ["Example Org"],
  "homepage": "https://example.org/repo-assist",
  "license": "MIT",
  "capabilities": {
    "skills": [
      {
        "name": "repo-triage",
        "entry": "skills/repo-triage/SKILL.md",
        "allowImplicitInvocation": true
      }
    ],
    "commands": [
      {
        "name": "repo.sync",
        "description": "Sync repository metadata",
        "defaultPrompt": "Use repo.sync to refresh repository context."
      }
    ],
    "mcpDependencies": [
      {
        "name": "github",
        "transport": "streamable_http",
        "url": "https://api.githubcopilot.com/mcp/",
        "requiredTools": ["search_repos", "get_pr"]
      }
    ]
  },
  "policy": {
    "requiresApprovalOnInstall": true,
    "allowNetwork": false
  },
  "integrity": {
    "sha256": "<bundle-hash>",
    "signature": "<optional-sig>"
  }
}

2) App-server protocol (v2)

Add RPC methods in codex-rs/app-server-protocol/src/protocol/v2.rs:

• plugin/list
• plugin/discover
• plugin/install
• plugin/update
• plugin/remove
• plugin/enable
• plugin/disable
• plugin/readme (optional but useful UX)

Add notifications:

• pluginInstalled
• pluginUpdated
• pluginRemoved
• pluginStateChanged
• pluginUpdateAvailable

Add new types:

• PluginMetadata
• PluginInstallParams, PluginInstallResponse
• PluginState (enabled|disabled|error)
• PluginDependencyStatus

3) CLI/TUI surface

• CLI commands:
  • codex plugin list
  • codex plugin discover
  • codex plugin install <id>
  • codex plugin update [id]
  • codex plugin remove <id>
  • codex plugin enable|disable <id>
• TUI:
  • Plugin manager pane similar to skills toggle.
  • Plugin dependency/auth status badges.
  • “Fix dependency” shortcuts for MCP login/setup.

4) Config additions

Extend config with:

• plugins.enabled = true|false
• plugins.auto_update = false (default)
• plugins.registry_url
• plugins.allow_unsigned = false (default)
• plugins.install_roots (user/repo scopes)
• plugins.disabled_ids = []

Implementation Plan (Decision-Complete)

Phase 1: Core plugin domain model and storage

1. Create core/src/plugins/ module with manifest model, validation, state, and storage layout.
2. Storage layout:
   • User plugins: $CODEX_HOME/plugins/installed/<plugin-id>/<version>/...
   • Active symlink/marker: $CODEX_HOME/plugins/active/<plugin-id>
   • State file: $CODEX_HOME/plugins/state.json
3. Add strict validation:
   • ID format, semver, schema version, path traversal checks, manifest size limits.
4. Add integrity verification:
   • Required SHA-256 match.
   • Signature verification hook (enabled when key source configured).

Phase 2: Skills bridge (Skills++ compatibility)

1. Implement plugin-to-skill bridge:
   • For each manifest capabilities.skills[*].entry, map into existing SkillMetadata.
2. Preserve existing skill loading pipeline:
   • Extend loader composition, do not rewrite skills subsystem.
3. Backward compatibility:
   • Existing standalone skills remain valid.
   • Plugin skills appear in skills/list with source=plugin:<id> tag.

Phase 3: MCP-first dependency lifecycle

1. Extend dependency resolver to read plugin mcpDependencies.
2. On install/enable:
   • Register or validate MCP server entries.
   • Mark dependency status (ready, auth_required, missing_tools, error).
3. On invocation:
   • Block plugin action if required MCP dependency is not ready.
   • Emit user-recoverable action prompts through existing request/input mechanisms.

Phase 4: App-server and CLI APIs

1. Add v2 RPC methods/types and JSON/TS schema exports.
2. Implement app-server handlers and events in codex_message_processor.
3. Add CLI subcommands and wire into app-server RPC.
4. Return deterministic error codes:
   • PLUGIN_NOT_FOUND
   • PLUGIN_INVALID_MANIFEST
   • PLUGIN_INTEGRITY_FAILED
   • PLUGIN_DEPENDENCY_UNREADY
   • PLUGIN_ALREADY_INSTALLED

Phase 5: Discovery and distribution

1. Add registry client:
   • discover endpoint returns summaries + versions + compatibility metadata.
2. Add download/install transaction:
   • Download to temp dir, validate, atomically move into installed store.
3. Support pinned install:
   • id@version and default “latest compatible”.
4. Cache registry metadata with TTL and offline fallback.

Phase 6: TUI UX and snapshots

1. Add plugin manager view with search/filter/status.
2. Add install/update progress events in history cells.
3. Add snapshot coverage for:
   • list states,
   • dependency warnings,
   • install success/failure banners.

Phase 7: Rollout and migration

1. Feature flag:
   • features.plugins_v1.
2. Dogfood:
   • internal/system plugin pack first.
3. Migration tool:
   • optional command to wrap existing skills into plugin skeleton.
4. Gradual enable:
   • alpha → beta → default-on.

File/Module Ownership Plan

• codex-rs/core/src/plugins/*: new plugin domain, validation, storage, registry client.
• codex-rs/core/src/skills/*: bridge hooks only (minimal invasive changes).
• codex-rs/app-server-protocol/src/protocol/v2.rs: new plugin RPC types.
• codex-rs/app-server/src/codex_message_processor.rs: plugin RPC handlers/events.
• codex-rs/tui/src/*: plugin manager UI and snapshots.
• docs/: plugin docs, config docs, protocol docs.

Security and Trust Model (v1)

• Default deny:
  • Unsigned bundles disallowed unless explicitly configured.
  • No arbitrary plugin runtime execution.
• Integrity gates:
  • Mandatory hash check.
  • Optional signature check with trust store.
• Filesystem safety:
  • Reject absolute paths and traversal in manifests/bundles.
• Dependency safety:
  • MCP-only capabilities use existing sandbox/approval controls.
• Auditability:
  • Emit plugin lifecycle events and log manifest fingerprint.

Testing and Acceptance Criteria

Unit tests

• Manifest parsing/validation edge cases.
• Integrity verification pass/fail.
• Storage transaction atomicity and rollback on failure.
• Plugin-to-skill mapping correctness.

Integration tests

• Install/enable/disable/remove lifecycle through app-server RPC.
• Dependency-not-ready path and recovery flow.
• Registry cache behavior offline/online.
• Backward compatibility with existing skills.

TUI snapshot tests

• Plugin list empty/loading/error/success.
• Dependency badge states.
• Install/update prompts and completion states.

End-to-end acceptance

• User can discover and install plugin by ID.
• Installed plugin contributes skills visible in UI and invocable in turns.
• Missing MCP auth produces actionable remediation.
• Disable removes plugin effects immediately without restart.
• Update preserves state and is rollback-safe on failure.

Milestones and Exit Gates

1. M1 (Core model + storage): validated manifests can be installed locally.
2. M2 (Bridge + MCP deps): plugin skills usable in turn planning.
3. M3 (RPC + CLI): full lifecycle available programmatically and via CLI.
4. M4 (TUI + snapshots): user-manageable plugin UX.
5. M5 (Registry + rollout): staged rollout with telemetry and kill switch.

Operational Considerations

• Telemetry:
  • install success rate,
  • dependency readiness failure rate,
  • invocation success rate per plugin,
  • update rollback count.
• Kill switch:
  • global disable flag in config.
• Supportability:
  • deterministic error codes and remediation hints.

Assumptions and Defaults Chosen

• Chosen by user:
  • Packaging model: plugin.json v1.
  • Execution model: policy-gated MCP only.
• Defaults:
  • auto_update = false.
  • Unsigned plugins disabled by default.
  • User-scope install root as primary.
  • Existing standalone skills remain first-class and compatible.
• Compatibility:
  • No breaking changes to existing skills/list; plugin-origin metadata is additive.

[dcieslak19973]

FWIW - the way claude has done marketplace reduces a lot of frictions

[timurkhakhalev]

@yu-iskw
Hi, will you add agents to the plugins system?

[yu-iskw]

@timurkhakhalev I think it would be awesome to pack sub agents into a plugin as well.

https://developers.openai.com/codex/subagents#custom-agents