›_ Codex Issues
Codex Issues / #24237

Project-level config should support disabling global/user skills while preserving repo skills

Open 💬 4 comments Opened May 23, 2026 by arksou
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.133.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.4.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

iTerm2

Codex doctor report

What issue are you seeing?

Use case:

  • I have many global/user skills installed under ~/.agents/skills, such as Lark/Feishu-related skills.
  • In one specific repository, those global skills are not relevant and consume the skills context budget.
  • The repository also has its own project skills under .codex/skills and .agents/skills, and those should still be injected.

Current behavior in Codex 0.133.0:

  • Project .codex/config.toml is loaded.
  • Project-level [skills] include_instructions = false works, but it disables all skills, including repo/project skills.
  • Project-level [[skills.config]] does not filter global/user skills.
  • Session-level -c 'skills.config=[...]' can filter skills, so the selector itself is not the issue.
  • Source code appears to only apply skills.config from User and SessionFlags layers, not Project layers.

Expected behavior:

  • A trusted project should be able to filter user/global skills for that project only.
  • Repo/project skills should remain injected.
  • Global config should remain unchanged for other projects.

This would solve the common case where global skills are useful generally, but too noisy or irrelevant for specific repositories.

What steps can reproduce the bug?

  1. Install a user/global skill, for example:

~/.agents/skills/lark-doc/SKILL.md

  1. In a trusted repository, create a project-local Codex config:

.codex/config.toml

```toml
[[skills.config]]
name = "lark-doc"
enabled = false

I also tested path selectors, for example:

[[skills.config]]
path = "/Users/<user>/.agents/skills/lark-doc/SKILL.md"
enabled = false

  1. From that repository, run:

codex debug prompt-input probe

  1. Check the generated <skills_instructions> block.

Expected:
The lark-doc skill should be removed from the model-visible skills list for this project only.

Actual:
The project-local .codex/config.toml is loaded, but lark-doc is still present in <skills_instructions>.

Control checks:

  • Project config loading works. For example, setting model = "project-config-probe" in .codex/config.toml is reflected by codex doctor --json.
  • Project-level [skills] include_instructions = false works, but it disables all skills, including repo/project skills.
  • Session-level override works:

codex debug prompt-input \
-c 'skills.config=[{name="lark-doc", enabled=false}]' \
probe

In that case, lark-doc is removed, so the selector itself is not the issue.

This makes it impossible to disable user/global skills for one repository while preserving repo/project skills.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23987

Powered by Codex Action

SylvainWinning · 3 months ago

I looked at the current config-rule path and this does look like a layer-selection issue rather than a selector issue.

In codex-rs/core-skills/src/config_rules.rs, skill_config_rules_from_stack() currently iterates the config layer stack but only accepts ConfigLayerSource::User and ConfigLayerSource::SessionFlags. That matches the reported behavior:

  • session-level -c 'skills.config=[...]' works;
  • user/global config can apply skill rules;
  • project .codex/config.toml is loaded for other settings;
  • but project-level [[skills.config]] is ignored for skill filtering.

A small MVP could be to allow trusted project layers to contribute skills.config rules, while preserving current precedence order. That would let a repository opt out of noisy user/global skills without using [skills] include_instructions = false, which is too broad because it disables repo/project skills as well.

Suggested acceptance criteria:

  • A trusted project config can disable a user/global skill by name.
  • A trusted project config can disable a user/global skill by canonical path.
  • Repo/project skills remain visible unless explicitly disabled.
  • Session flags still win over project config.
  • Untrusted project config does not silently gain new skill-filtering power.
  • Existing include_instructions = false behavior remains unchanged.

This also seems related to #24299 and #21425: users with large global/plugin skill sets need a project-scoped way to reduce prompt noise without changing their global setup.

Artein · 1 month ago

I am on Pro x20 subscription, and when you work with a bunch of projects and subprojects — the feature to selectively enable/disable Personal/Team skills is essential. Right now, it clatters the skills view with copies of the same skill just from another level.

Here is how it looks for me:
<img width="753" height="443" alt="Image" src="https://github.com/user-attachments/assets/cc7cd0fb-fcff-4e07-80ca-ea476140ba54" />

So, just filtering out by name is not enough. Perhaps, we should also be able to filter out by path or level (Global/Personal/Team/Project)

Fixing/imroving this will make my workflow more error-prone (especially in cases when top-level skill has different functionality under the same name).

@etraut-openai, fyi

ewgenij87snwork · 1 day ago

I ran into the same problem and ended up building CLROOM, an open-source launcher for this workflow.

For a Codex launch it keeps repo/project skills available, blocks global AGENTS.md and unselected global skills, and leaves your normal global setup untouched.

You can then bring back only the global skills you want for that run:

clroom codex --skill-set=my-skill,@my-skills

So: project skills stay, unrelated global skills stay out, and nothing has to be removed or rewritten globally.

CLROOM started as a tool for isolated skill testing, so a plain launch uses Clean Room defaults: apps, hooks and plugins are off, developer instructions and notifications are cleared, and shell environment inheritance is reduced.

For normal day-to-day work, I’d start with:

clroom codex --skill-set=@my-skills --enable apps --enable hooks --enable plugins

This keeps the skill filtering while bringing apps, hooks and plugins back for your Codex launch.

Or enable only the ones you need.

Current alpha: macOS / Apple Silicon

https://github.com/ewgenij87snwork/clean-room-launcher

I’m the author — I’d really like to know whether this covers the workflow described here, or what’s still missing.