Allow skills to be marked required and fail closed when unavailable

Open 💬 2 comments Opened Aug 10, 2026 by PaulRBerg

What variant of Codex are you using?

Codex CLI 0.147.0

What feature would you like to see?

Summary

Add a per-skill required setting (or equivalent always-injected mode) in config.toml so a small user-selected set of skills is guaranteed to remain available and loaded, independent of initial skill-catalog truncation.

Current behavior

[[skills.config]] can select a skill by name or path and set enabled, but enabling only makes the skill eligible. Codex caps the initial model-visible skills list, and enabled skills can be omitted when the catalog exceeds that budget.

On Codex CLI 0.147.0, a user-level skill existed on disk and global AGENTS.md explicitly required it for every task, but the skill was absent from the injected Available skills catalog. The agent therefore reported the required skill as unavailable. A mandatory workflow declared in global instructions is consequently nondeterministic when the catalog is large.

Requested behavior

Support a configuration such as:

[[skills.config]]
name = "agents-brain"
enabled = true
required = true

Suggested semantics:

  1. Resolve and validate required skills before applying the general catalog budget.
  2. Always include their metadata and load their full SKILL.md instructions into the model context.
  3. Preserve or reload required skills after compaction.
  4. Fail visibly at session startup if a required skill is missing, invalid, disabled by policy, or cannot fit within a bounded required-skills budget.
  5. Support path selection for duplicate skill names.

The required set should be intentionally small. If a separate mode is clearer, equivalent semantics could be expressed as injection = "required" | "catalog" | "on_demand" | "off".

Expected result

Users can enforce cross-repository workflow, safety, or synchronization skills without copying their full contents into AGENTS.md, disabling unrelated skills, or relying on catalog ordering. A required skill is either loaded or produces an explicit startup error; it is never silently omitted.

Additional information

Environment: macOS, Codex CLI 0.147.0.

Related but distinct requests:

  • #19090 tracks skills silently dropped from the model-visible catalog.
  • #19679 requests a configurable overall metadata budget.
  • #21425 requests separating installed skill availability from default injection.
  • #33945 requests automatic skill routing and mentions always-visible pinned skills as one broader control.

This request is narrower: a declarative, fail-closed contract for a small required subset. Increasing the overall budget or improving routing would not provide that guarantee.

View original on GitHub ↗

2 Comments

jdcodes1 · 9 days ago

Confirming the mechanism and mapping the fix surface: the injected catalog is rendered under a SkillMetadataBudget (token- or character-denominated, derived from the model's context window — https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/ext/skills/src/render.rs#L76-L150), and render_available_skills drops entries once the budget is spent, with only render-observability metrics recording what fell off. [[skills.config]] enabled = true feeds eligibility, not priority — nothing today marks a skill as must-survive-truncation, so a large catalog makes any given skill's presence nondeterministic exactly as you describe.

Given that structure, required = true has a natural implementation: render required skills first against the budget (fail loudly if even those don't fit — that's a real configuration error, not something to silently drop), then fill the remainder with the ordinary catalog. Two adjacent behaviors worth including in the same change: (1) a user-visible warning when truncation drops any enabled skill (today it's metrics-only, so your AGENTS.md-mandated skill vanished without a trace — same silent-truncation pattern as the AGENTS.md byte budget in #37956); (2) letting the dynamic skill selector (dynamic_skill_selector.rs) treat required skills as always-candidates, since it has its own candidate_set_truncated path with the same failure mode.

PaulRBerg · 9 days ago

hey @jdcodes1, thanks for your input, if you'd like to see this feature implemented and prioritized by the Codex team, please thumbs up 👍 the original issue!