›_ Codex Issues
Codex Issues / #23454

$skill explicit invocation ignores local explicit-only skills absent from implicit skill list

Open 💬 8 comments Opened May 19, 2026 by hratio
💡 Likely answer: A maintainer (Alb-O, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.131.0

What subscription do you have?

ChatGPT auth PRO

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 7.0.3-arch1-2 x86_64 unknown

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

Konsole 26.04.1, tmux 3.6a

Codex doctor report

{
    "overallStatus": "ok",
    "codexVersion": "0.131.0",
    "auth": "ChatGPT auth",
    "model": "gpt-5.5",
    "platform": "linux-x86_64",
    "terminal": "Konsole 26.04.1",
    "multiplexer": "tmux 3.6a",
    "installMethod": "npm",
    "note": "Full doctor output contained local absolute paths and was redacted for public issue."
  }

What issue are you seeing?

After the dumbing down of the underlying GPT-5.5 models recently. Stuff like this is preventing the agent from resolving skills marked with:

policy:
  allow_implicit_invocation: false

Tried with different kinds of reasoning. Was not a problem before.

Should we wait for 5.6 or is it worth addressing?

---

Explicit $skill invocation failed for a local explicit-only skill.

The user invoked:

$act-learn-action

The skill existed at:

.codex/skills/act-learn-action/SKILL.md

Codex did not load it because the skill was absent from the model-visible implicit “Available skills” list. The assistant treated that list as exhaustive and said the named skill was unavailable.

That is incorrect. Explicit-only skills are intentionally not advertised for implicit routing, but $skill should still resolve them.

What steps can reproduce the bug?

  1. Install an explicit-only skill under:

.codex/skills/act-learn-action/SKILL.md

  1. Start a Codex session where that skill is not listed in the implicit “Available skills” block.
  1. Ask Codex:

$act-learn-action update the relevant workflow so this correction is learned

  1. Observe that Codex reports the skill unavailable instead of loading the local skill.

What is the expected behavior?

When the user explicitly writes $act-learn-action, Codex should resolve that exact skill name from local configured
skill roots such as .codex/skills.

Explicit-only skills should remain excluded from implicit skill matching, but $skill invocation should be reliable
and should not depend on the implicit “Available skills” list.

Additional information

This appears related to #19695, but this report is specifically about the $skill explicit invocation path.

The key bug is treating the implicit advertised skill list as exhaustive even when the user explicitly invokes a skill
by name.

Chat log:

Me:
$act-learn-action need to update the intake skill or workflows to fix this bullshit

It:
The named $act-learn-action skill is not available in this session, so I’ll use the repo’s create-skill workflow and patch the source skill/workflow files directly. The failure was in approval-artifact selection, so I’m going to find where that workflow is authored and add hard ordering/validation rules there, then rebuild/verify if the repo supports it.

View original on GitHub ↗

8 Comments

Alb-O contributor · 3 months ago

Bumping this, this bug is extremely annoying, codex will refuse to use the skill even though the skill appears valid in the TUI picker

This OP issue doesn't capture the exact condition for the bug, it specifically happens when you invoke an explicit-only skill while codex is currently working (as a "steer")

alexchexes · 2 months ago

This made skills usage fully unreliable. We can no longer be sure that when we invoke a skill essential for the task, it will be used by Codex.

This OP issue doesn't capture the exact condition for the bug, it specifically happens when you invoke an explicit-only skill while codex is currently working (as a "steer")

It happens not only when "steering"; it's just how it works now, for any mode/prompt/workflow.
Explicit-only skills became almost completely unusable as of 2026-06-19.

---

More and more are leaning toward abandoning OpenAI products because they break things that aren't supposed to ever be broken.

Glad I didn't buy a $100 subscription, as no one should pay that amount for a product with such poor QA.

LevyBytes · 2 months ago

@ OpenAI this is why Claude is better for development in many ways, Anthropic and a growing number of community understands about the context sweet spot, keeping a large library of skills user invoke only is the best way to manage that context window along with a ton of other framework efforts to curtail these model/sandbox setup inefficiencies. This should be a priority to fix for Codex to stay competitive.

fohaser · 1 month ago

App 26.715.72359, same problem

Robinfr · 27 days ago

Still happening. Have to close Codex and resume the session for the skills to become available again.

Tomauskasz · 24 days ago

Confirmed independently on macOS arm64 with Codex CLI 0.145.0. The same skill-discovery implementation remains present in 0.146.0.

Reproduction:

  1. Install timebox at $CODEX_HOME/skills/timebox/SKILL.md.
  2. Set policy.allow_implicit_invocation: false in agents/openai.yaml.
  3. Start a new CLI session and enter $timebox You have 2hours to fix this all up! Work faster.
  4. Codex replies that $timebox is “not installed” or “not available in this session.” The refusal repeated later in the same session.

Diagnostics:

  • The affected rollout records cli_version: 0.145.0, originator: codex-tui.
  • A forced skills/list refresh reports timebox, enabled: true, with no discovery errors.
  • The skill is absent only from the model-visible implicit catalog because allow_implicit_invocation is false.
  • The skill name is unique and the file is readable.
  • The raw user input contains the explicit $timebox token.

Expected: explicit invocation resolves and injects the enabled skill even though implicit invocation is disabled. The model must not treat the implicit catalog as exhaustive.

sandipb · 16 days ago

Observed the same. The first invocation gives the error message. Works the second time.

...
› $session-review
• session-review skill unavailable in this session. 

› $session-review
• Using session-review to extract durable repo knowledge
MarlonPassos-git · 14 days ago

Hi folks — I initially thought I was hitting this exact issue too. I asked Codex to inspect the CLI implementation and then tested the behavior on Codex CLI 0.147.0.

In my case, the problem was the skill name. The mention parser only accepts ASCII letters/digits plus _, -, and :. A dot stops the parsed mention.

The behavior appears intentional in the current code: the test for $alpha.skill expects the extracted name to be only alpha, while the plugin namespace in $slack:search is preserved.

For example, a plugin skill named release.deploy, invoked as $acme:release.deploy, is parsed only as acme:release. Skill resolution then fails and it looks like the explicit-only skill is unavailable.

What fixed it for me:

  1. Rename the skill directory and the name in SKILL.md from release.deploy to release-deploy.
  2. Invoke it as $acme:release-deploy.
  3. Keep policy.allow_implicit_invocation: false unchanged.
  4. Bump/reinstall the plugin so its cached copy receives the renamed skill.

I validated both sides with fresh codex exec sessions. Sending only Hi added none of my explicit-only plugin skills to the model-visible available-skills list and injected no SKILL.md. Explicitly invoking the renamed skill resolved it and injected its instructions correctly.

My case involved skills distributed through a plugin. This worked for me, so it may be worth checking whether any affected skill names contain dots.