Allow repo-committed skills to be opt-in per contributor (default-off, like Claude Code's @skills-dir + enabledPlugins)

What variant of Codex are you using?

CLI

What feature would you like to see?

A way to commit skills into a repository so they are discoverable but disabled by default, with each contributor opting in to the specific skills relevant to their work — without standing up a repo marketplace/plugin.

Context / who this is for

I maintain the agentic-coding setup for an iOS app monorepo with 20+ contributors. People own different areas, so a repo-wide skill set that force-activates for everyone is noisy and eats the ~2% skills context budget on every session.

On Claude Code this is a first-class, named feature. Two pieces combine:

1. Skills-directory plugins — a skill folder committed under the repo's .claude/skills/<name>/ with a .claude-plugin/plugin.json loads in place as <name>@skills-dir on the next session, with no marketplace and no install step. Docs: https://code.claude.com/docs/en/plugins-reference#skills-directory-plugins

1. defaultEnabled: false (Claude Code v2.1.154+) — a plugin can ship so that it "installs disabled. The user turns it on with claude plugin enable <plugin> or the /plugin interface. Use this for plugins that add cost or scope a user should opt into." The user's own enabledPlugins entry then takes precedence and persists across updates/reinstalls. Docs: https://code.claude.com/docs/en/plugins-reference#default-enablement

Net result: the repo distributes the skills, but they are off by default and each contributor opts in to the ones they need — controlled per-contributor via enabledPlugins in their settings, while the folder itself is checked into the repo.

That combination — repo-committed and default-off and per-contributor opt-in, with no marketplace — is exactly what's blocking our Claude Code → Codex migration.

Why current Codex mechanisms don't cover this

• Committing to .agents/skills (or .codex/skills) force-activates for everyone — there is no default-off.
• [[skills.config]] is only honored from User and SessionFlags config layers, not the Project layer, so a repo cannot ship a default-off state. (This is the root cause behind #24237 and #20210.)
• [skills] include_instructions = false is all-or-nothing — it drops repo/project skills too.
• agents/openai.yaml allow_implicit_invocation: false is a repo-level authoring choice, not a per-contributor setting, and the skill still occupies the initial skills list / metadata budget.

Proposed directions (any one solves it)

1. Per-skill default state (mirrors Claude Code's defaultEnabled: false). Support a default_enabled = false field (in agents/openai.yaml or SKILL.toml) so a repo-committed skill ships opt-in. Contributors flip it on with [[skills.config]] enabled = true in their own ~/.codex/config.toml, and that user setting persists across updates.

1. **Honor [[skills.config]] from the Project layer for trusted projects.** This lets a repo commit enabled = false defaults that contributors override in user config. (This would also resolve #24237.)

Either direction keeps the global default unchanged and adds no forced activation. Direction 1 is the closest analog to what Claude Code already ships.

Relationship to existing issues

• Distinct from #20210 (selective filtering of already-global skills, closed not-planned). This request is about repo-distributed, default-off, per-contributor opt-in skills — a different capability.
• Adjacent to #24237 (project layer can't filter user/global skills) and #21425 (decoupling install/enable from per-session injection). This is the authoring/distribution side of the same gap.
• Related framing precedent: #18193 asks for repo-level opt-in without changing the global default.

Additional information

_No response_