Automatically expose installed plugin bin/ directories on the session PATH

What feature would you like to see?

When Codex installs and enables a plugin, automatically prepend that plugin's top-level bin/ directory to the command environment used by the agent for the session.

No manifest field should be required for the common case. A top-level directory named bin/ is a longstanding convention: its executable files are commands supplied by the package. Installing a plugin that contains bin/forge should make this work immediately:

forge namespace

Optional configuration could be added later for unusual layouts, but bin/ should work by convention.

Why is this important?

An installed plugin should work immediately after a user selects a marketplace, installs the plugin, and starts Codex. The user should not need to understand plugin cache paths, modify their shell profile, create symlinks, install a second global package, or teach every skill how to reconstruct the plugin's absolute installation directory.

Today, a plugin can contain executable helpers, but a skill must locate them using package-relative or model-resolved paths. In practice this creates instructions such as:

python3 <absolute-directory-containing-SKILL.md>/scripts/tool.py

or requires a wrapper outside the plugin. This turns deterministic package information into prompt content and model reasoning. It is fragile across cache versions, operating systems, installation scopes, and plugin layouts. It also means every skill that uses the same CLI must repeat path-resolution machinery.

The resulting experience violates the normal marketplace expectation:

1. Add a marketplace.
2. Install a plugin.
3. Use it.

For command-backed developer plugins, step 3 currently becomes an integration exercise requiring knowledge of Codex internals.

Convention over configuration

bin/ already communicates the package author's intent. Codex should not require another declaration that repeats it. For each enabled plugin with a top-level bin/ directory, Codex can prepend that directory to the agent command environment while preserving the user's existing PATH.

Commands should be scoped to the Codex process/session rather than modifying the user's persistent shell configuration. If multiple plugins provide the same command name, Codex should detect the collision and report it clearly rather than silently choosing one.

Platform-specific binary selection and multi-architecture packaging are related future concerns, but they should not block the basic convention. Executable scripts and already-compatible binaries in bin/ can work now.

Existing precedent

Claude Code already makes a loaded plugin's bin/ commands available during the session. Adopting the same behavior would improve Claude-plugin compatibility and let cross-agent plugin authors keep one natural command contract.

Codex already installs plugins into versioned roots and knows which plugins are enabled for a session, so it has the information needed to construct this process-local command path mechanically.

Related reports

The absence of reliable plugin-relative command resolution already appears in several open reports:

• #9226 — Codex cannot discover scripts in a skill's scripts/ directory.
• #35702 — request for CODEX_SKILL_DIR and CODEX_PLUGIN_ROOT because plugin authors lack a mechanical way to invoke bundled resources.
• #35211 — an OpenAI-bundled skill's relative helper command fails from a normal workspace.
• #30792 — plugin skill audit finding repeated ambiguity around skill and plugin path roots.
• #22842 — the corresponding plugin-root resolution problem for bundled MCP servers.

Environment variables would help authors construct absolute paths, but automatic bin/ exposure solves the ordinary command-backed plugin case without placing that complexity in every skill.

Suggested behavior

• On session startup, identify every enabled plugin's installed root.
• If <plugin-root>/bin/ exists, prepend it to the agent's process-local command PATH.
• Require executable permissions on POSIX; honor normal executable conventions on Windows.
• Apply the same environment consistently to shell/tool execution initiated while using plugin skills.
• Do not modify the user's persistent shell configuration.
• Detect command-name collisions and produce an actionable diagnostic.
• Make installed plugin commands available after the same restart/reload boundary as the plugin's other components.

Acceptance example

Given an installed plugin containing:

forge/
  .codex-plugin/plugin.json
  bin/
    forge
  skills/
    grill/SKILL.md

then, in a Codex session where the plugin is enabled:

command -v forge
forge --help

should resolve and execute <plugin-root>/bin/forge without any user PATH changes or skill-specific path instructions.