Implement Codex Plugins same as Claude Plugins

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

Any update?

Is this thing on?

Shaun Tyler @.***> schrieb am Mi. 14. Jan. 2026 um
22:09:

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

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

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

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]

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

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]

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

1. Add strict validation:

• ID format, semver, schema version, path traversal checks, manifest size limits.

1. 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.

1. Preserve existing skill loading pipeline:

• Extend loader composition, do not rewrite skills subsystem.

1. 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).

1. 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.

1. Add download/install transaction:

• Download to temp dir, validate, atomically move into installed store.

1. Support pinned install:

• id@version and default “latest compatible”.

1. 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.

1. Dogfood:

• internal/system plugin pack first.

1. Migration tool:

• optional command to wrap existing skills into plugin skeleton.

1. 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.

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

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

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

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

@timurkhakhalev I think it would be awesome to pack sub agents into a plugin as well. https://developers.openai.com/codex/subagents#custom-agents

copilot plugin (but I think also claude) support agent into plugin, and it is a very gratifying feature to permit to ship in the same bundle both skills and agents

Plugins are now supported!

great, thank you very much!

Thank you @etraut-openai!!

Does the plugin currently support hooks? It seems Claude Code does, but I'm unsure if Codex will also install hooks.