Repository-scoped marketplace and plugin configuration in project config

This + now with the skills warnings, we should be able to configure plugins on repo level overall, not just user level?

Hi, it's really important for my team to be able to disable plugins for specific projects. If you work on multiple projects at the same time and have a plugin dedicated to a specific project, it's installed globally and interferes with work on another project.

+1

Often plugins will be completely unrelated across projects, wasting tokens and increasing the chance of errors.

Example: one project might be using a database-related plugin, another might be using a second (or none at all). Giving codex access to such a plugin just creates pure noise in all but the project it's related to.

different auth for repo-scoped plugins is vital for this, too. Personal/professional projects may both use Vercel for example. Being able to scope plugins to a repo would be a huge QOL increase

Reproduced this gap on CLI 0.138.0, on both macOS and Windows.

Setup:

• ~/.codex/config.toml (user level): [plugins."x@market"] enabled = false
• <repo>/.codex/config.toml (project level, trusted repo): [plugins."x@market"] enabled = true

Result: codex plugin list --json still reports the plugin as disabled. The project-level [plugins.*] enablement section is not merged at all — user-level enabled is the only effective knob today.

This is a hard blocker for us, not a nice-to-have. We need certain plugins enabled only in the repos that use them, and right now there is no supported way to do that: it's either globally visible in every project (the cross-project noise problem described above), or unusable everywhere. We've had to fall back to global enablement against our will, which pollutes every other project on the machine.

Project-scoped config already exists for other settings — extending it to [plugins.*] enabled would unblock this entire class of use cases. This issue has been open since April with steady +1s; really hoping it gets picked up soon.

+1 on this. I'm building AI enablement tools at a company that uses a blend of coding agents. Repo/project-scoped plugins would be a nice capability to simplify how we support role/task-specific Codex workflows. The alternatives are not great: modifying a user's global plugins or managing repo/project skills, MCPs, hooks.

I’m seeing the same issue in Codex Desktop, and it has real consequences for team and multi-repo use.

In a trusted repo at /Users/tsingh/repos/codex/tbridge, .codex/config.toml contains plugin toggles like these:

[plugins."github@openai-curated"]
enabled = false

[plugins."browser@openai-bundled"]
enabled = false

[plugins."codex-git-workflow@plugins"]
enabled = false

My user config at ~/.codex/config.toml enables several of the same plugins. In the active thread, Codex still exposes skills and tools from plugins disabled by the repo config. In practice, [plugins.*].enabled appears to come only from user/global config.

That is a big deal for repo-scoped Codex workflows. Plugin availability changes the agent’s skills, tools, and instructions. If a trusted repo cannot control that surface, two users can open the same repo and get different agent behavior based only on their global plugin config.

This breaks a few important workflows:

• A repo cannot disable broad plugins that do not belong in that codebase.
• A repo cannot opt into the exact plugin set its workflows expect.
• Teams cannot make Codex behavior reproducible from checked-in config.
• Least-privilege setup becomes global and manual instead of repo-scoped.

I’d expect one of these behaviors:

• Trusted project .codex/config.toml can enable or disable installed plugins, following normal config layering.
• Codex treats plugin enablement as global-only, documents that explicitly, and warns when project config contains [plugins.*] entries.

Right now project .codex/config.toml accepts these entries silently, but they do not appear to affect the thread.

I want to add a concrete case where repo-scoped plugin enablement matters a lot.

Small globally enabled plugins are annoying but usually manageable. Large workflow/governance plugins are different. A private workflow plugin may bring backlog management, requirements, design, implementation, verification, release planning, project state conventions, rules, hooks, and many command-style entry points into Codex.

If such a plugin must be enabled globally, every unrelated repository on the same machine is exposed to that workflow surface. That creates context pollution, behavioral drift, non-reproducible team behavior, and a larger least-privilege / operational-risk surface.

The current workaround is to avoid global enablement and use separate CODEX_HOMEs, wrapper scripts, or manual enable/disable flows. That works, but it is fragile and makes team workflows hard to adopt.

For large workflow plugins, repo-scoped enablement is the difference between “safe to use in this repo” and “too risky to enable at all”.

Trusted project config should be able to declare something like:

[marketplaces.workflow-tools]
source_type = "git"
source = "https://example.com/org/workflow-tools.git"

[plugins."delivery-workflow@workflow-tools"]
enabled = true

and have it apply only inside that trusted repository.

If plugin enablement is intentionally global-only for now, it would help to document that and warn when [plugins.*] appears in project .codex/config.toml, because today it looks accepted but is silently ignored.

Adding a small technical note based on the current code path.

From what I can see, plugin enablement appears to be intentionally or accidentally user-config-only today because the plugin state path goes through:

• configured_plugins_from_stack(...)
• project_effective_user_config(...)
• config_layer_stack.effective_user_config()

That means project .codex/config.toml is loaded for other settings, but project-level [plugins.*] entries never enter the plugin enablement map used by codex plugin list or plugin loading.

A narrow MVP might be to support only trusted-project overrides for already-installed plugins first, without solving repo-scoped marketplace installation yet:

• user config defines/installs the marketplace and plugin as it does today;
• trusted project config can override [plugins."name@marketplace"].enabled;
• session flags still have highest precedence;
• untrusted project config cannot enable plugins;
• codex plugin list and runtime loading use the same merged state;
• if project-level plugin config is intentionally unsupported, Codex warns instead of silently ignoring it.

That would not solve the full repo-scoped marketplace story, but it would address the most painful part: letting a trusted repository reduce or opt into the active plugin surface without forcing global enablement across every repo on the machine.

Reproduced on Codex CLI 0.144.1 on macOS arm64 with a concrete repo-local plugin bundle.

The repository contains:

$REPO_ROOT/.agents/plugins/marketplace.json
$REPO_ROOT/.oncall/plugins/starrocks-assistant/.codex-plugin/plugin.json
$REPO_ROOT/.oncall/plugins/starrocks-wiki/.codex-plugin/plugin.json

Both marketplace entries use:

"policy": {
  "installation": "INSTALLED_BY_DEFAULT",
  "authentication": "ON_INSTALL"
}

Codex successfully discovers the repo marketplace. /plugins shows a StarRocks Oncall marketplace with both plugins, but reports Installed 0 of 2; each plugin is labeled Admin assigned and still requires Enter to install. This is consistent with #28924, but the important additional constraint here is installation scope: manually installing writes plugin state/cache under the active CODEX_HOME (normally ~/.codex), while this repository must not modify developer-global Codex configuration.

The gap is particularly surprising because every component bundled by these plugins already has a project-scoped native loading path:

• instructions: repo AGENTS.override.md
• skills: repo .codex/skills/
• MCP servers: repo .codex/config.toml
• hooks: repo .codex/hooks.json plus existing hook trust

Packaging the same components into a plugin removes the ability to load them at project scope. The current workarounds are either global installation, a separate CODEX_HOME plus launcher wrapper, or expanding the plugin back into four separate repo registrations.

Requested behavior: support one of these equivalent project-scoped flows:

codex plugin add starrocks-assistant@starrocks-oncall --scope project

or automatically materialize local repo plugins marked INSTALLED_BY_DEFAULT into project-scoped capabilities, storing any state/cache under the repo rather than ~/.codex. Existing project and hook trust checks can remain in place.

Acceptance criterion for our use case:

fresh user plugin state
→ clone repository
→ run the repository setup
→ launch plain `codex` from the repo
→ repo plugins are loaded only in that repo
→ no plugin marketplace/install/enable state is written to ~/.codex