Implicit skill routing ignores explicit negative trigger boundaries and invokes unrelated skills

[scubashack808]

What version of Codex CLI is running?

codex-cli 0.145.0 (the latest stable release at the time of filing)

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Darwin 25.3.0 arm64 arm (macOS 26.3.1)

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

Warp v0.2026.07.01.09.21.stable_01, with no tmux/zellij/screen multiplexer.

Codex doctor report

Privacy-redacted summary (the full report contains local paths and a rollout identifier):

{
  "overallStatus": "warning",
  "codexVersion": "0.145.0",
  "runtime": {
    "platform": "macos-aarch64",
    "installMethod": "npm"
  },
  "config": {
    "model": "gpt-5.6-sol",
    "modelProvider": "openai",
    "relevantEnabledFeatures": [
      "skill_search",
      "plugins",
      "mentions_v2"
    ]
  },
  "updates": {
    "installed": "0.145.0",
    "latest": "0.145.0"
  }
}

The doctor warning concerns one rollout-file/state-DB parity mismatch and appears unrelated to skill selection.

What issue are you seeing?

Implicit skill routing repeatedly invokes skills whose own descriptions explicitly exclude the current task. This is not merely the skill catalog being present in context: the agent announces the skill, reads SKILL.md, consumes context with the unrelated workflow, and often starts following it before understanding the request.

The user estimates that Codex invokes a skill in almost every fresh session and that roughly 80% of those automatic selections are wrong. This has happened across multiple Codex versions and many different tasks.

The especially clear failure pattern is:

1. A skill description contains a narrow positive trigger plus explicit negative conditions or “only when all of these are true” gates.
2. The user request contains a noun or phrase that overlaps lexically with the skill.
3. Codex loads the skill even though the full request does not satisfy the trigger conditions.
4. When asked why it used the skill, the agent rereads the same description and acknowledges that the description says it should not have used it.

One sanitized real example involves a forensic session-recovery skill whose description says, in substance:

Invoke only when all required conditions are true: the user explicitly asks to reconstruct exact execution state from one uniquely identified saved session. Do not use it for ordinary continuation or loosely finding prior work.

The user asked an agent to continue normal work associated with a prior thread. There was no request for forensic reconstruction of exact execution state and the trigger's required conditions were not met. Codex selected and read the recovery skill based on the thread/session language anyway. When challenged, the agent agreed that the skill description excluded the task.

Other repeated incidents have involved skills selected merely because the prompt mentioned a term such as “grilling,” “Tesla,” “NodeTerm,” “tmux,” “memory,” or “browser,” even though the requested workflow was discussion, transcript inspection, or unrelated project work, not the workflow defined by the selected skill. In several cases the prompt explicitly said not to use a skill, but the implicit selection still happened.

This makes narrowly scoped skills unsafe to keep installed: adding more precise negative trigger language does not reliably reduce false positives, and every false selection pollutes the context before the user can stop it.

What steps can reproduce the bug?

1. Install several personal skills with narrow descriptions. Include at least one description with both:
   • a term likely to occur in ordinary prompts; and
   • an explicit hard boundary such as “invoke only when all conditions are true” or “do not use for normal continuation/discussion.”
2. Start a fresh Codex CLI session.
3. Give a request that mentions the overlapping term but asks for a different action and does not satisfy the skill's required conditions.
4. Do not explicitly invoke the skill with $skill-name.
5. Observe that Codex announces and reads the skill before fully resolving applicability.
6. Ask why the skill was selected. The agent can often identify, from the already-visible description, that its own selection violated the trigger boundary.

The exact selection is model-dependent, but this reproduces frequently in a large installed skill catalog. A minimal test shape is a skill described as “forensic reconstruction only; never normal continuation” plus a prompt asking to continue ordinary work in another thread.

What is the expected behavior?

• Applicability should be decided from the complete skill description, including negative clauses and required preconditions, before SKILL.md is loaded.
• “Only when all conditions are true” must behave as an AND gate, not as weak prose outweighed by one keyword match.
• An explicit user instruction not to use optional skills should veto implicit invocation unless a higher-priority product policy truly requires it.
• A matching noun or skill name in a discussion should not be sufficient to invoke the workflow.
• If applicability is uncertain, Codex should continue without the skill or ask a narrowly scoped question before loading it.
• Skill-selection diagnostics should expose which description fields matched and why exclusions did not veto the candidate, so false positives can be reported and tested.

Additional information

This is related to but distinct from existing reports:

• Visualize skill over-triggers on standalone HTML requests and leaks inline layout constraints #33164 is a concrete over-trigger for the bundled Visualize skill and standalone HTML.
• Ability to disable / select a narrow set of specific skills for session #9799 requests a way to disable or manually narrow skills for a session.
• Add project- and task-aware lazy skill routing before prompt injection #33945 requests project/task-aware lazy routing before skill metadata injection.

This report is about the general applicability contract: even when the correct skill description is present and contains explicit exclusion criteria, automatic selection disregards those criteria. The fix should not require users to disable all skills or manually enumerate the allowed subset for every session.

Version 0.145.0 has skill_search enabled. Recent lexical skill-selection work may be diagnostically relevant, but the behavior predates this release, so this report does not assume that the newest selector introduced the problem.