Add --plugin-dir for direct local plugin development

What feature would you like to see?

Please add a session-scoped development flag that loads a plugin directly from its working directory, without installing or copying it through a marketplace. For example:

codex --plugin-dir /absolute/path/to/plugin

The directory should be the plugin root for that Codex process. Skills, hooks, agents, MCP configuration, scripts, and runtime dependencies should resolve from the live working tree. Multiple flags could allow testing more than one local plugin.

This should be a development path distinct from marketplace installation. Marketplace caching is appropriate for installed, versioned distributions; it is counterproductive in the edit-test-debug loop.

Why is this important?

The current local-plugin workflow requires developers to route every change through marketplace installation and a versioned cache. OpenAI's own plugin-creator instructions recommend adding a timestamp cache-buster to plugin.json, reinstalling the plugin, and starting a new thread for each iteration.

That introduces state and failure modes which are unrelated to the plugin being developed:

• source and active cache can diverge;
• every edit may require a synthetic version change and reinstall;
• copied plugin trees can differ from their source trees;
• workspace and package-manager symlinks can be lost during copying;
• developers must inspect or delete internal cache directories to diagnose stale behavior;
• wrappers and cache-manipulation workarounds become tempting but remain timing-sensitive;
• the iteration loop becomes substantially slower and harder to reason about.

These are not hypothetical concerns. Existing reports document stale local-plugin contents, refresh inconsistencies, and incomplete cache copies:

• #21138 — local plugin contents remain stale without a version bump
• #23902 — local marketplace refresh and discovery paths disagree
• #18863 / #24770 — plugin cache installation silently drops symlinks
• #17066 — local marketplace source-path limitations force additional layout workarounds

A cache should not sit between a plugin developer and the code they are actively editing.

Existing design to adopt

Claude Code already separates these workflows cleanly:

claude --plugin-dir /path/to/plugin

That form loads a plugin for the duration of the session, while marketplace installation remains available for durable distribution. Claude Code also provides /reload-plugins for components that require reloading.

Please adopt the same basic contract in Codex. Cross-agent plugin authors would gain a familiar workflow, and Codex would avoid inventing additional cache invalidation and synchronization machinery for a problem that direct loading removes entirely.

Suggested acceptance criteria

• codex --plugin-dir <path> accepts an absolute or relative plugin directory.
• The plugin is loaded directly from that directory for the lifetime of the process.
• No marketplace registration, installation, cache copy, or manifest version change is required.
• Plugin-relative paths and runtime dependency resolution use the supplied working tree.
• The option is repeatable for multiple development plugins.
• A newly started Codex process sees all current files from the working tree.
• Ideally, /reload-plugins reloads supported plugin components without restarting the process.
• Normal marketplace-installed plugins continue using the existing installation and caching behavior.