Explicit 'do not use this skill' instruction triggers and loads the prohibited skill

Start by tracing automatic skill discovery and plain-text skill-name trigger handling, then inspect how negation is processed before a skill's SKILL.md is loaded. Add regression coverage for negated mentions, quoted examples, bug reports, comparisons, and discussion about a skill, and verify that the prohibited skill is not read.

What version of Codex CLI is running?

codex-cli 0.145.0

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)?

Codex TUI. The behavior is instruction/skill-routing related and does not appear terminal-specific.

Codex doctor report

Privacy-redacted environment summary:

{
  "codexVersion": "0.145.0",
  "platform": "macos-aarch64",
  "model": "gpt-5.6-sol",
  "modelProvider": "openai"
}

What issue are you seeing?

An explicit instruction not to use a skill caused Codex to announce, read, and begin applying that exact prohibited skill.

This was not a borderline applicability judgment. The task was to correct existing project documentation. The user explicitly said that they do not use memory and did not want a memory skill involved.

Codex acknowledged the boundary, then immediately contradicted it:

“I’m using the memory-write preflight only to prevent another stray ‘remember this’ artifact.”

It then executed the equivalent of:

cat <skills-root>/memory-write/SKILL.md

No durable-memory operation was requested. The skill name/category appeared in the conversation only because the user was prohibiting it.

When challenged, Codex accurately diagnosed its own failure:

“I mechanically followed the skill trigger and ignored your explicit ‘do not use memory’ boundary.”

This behavior is consistent with a trigger contract that treats a plain-text skill mention as affirmative invocation before resolving semantic polarity. Under that behavior, “do not use X” becomes a command to use X.

Reading the file is already a violation even if no memory write follows: it consumes context, injects a workflow the user explicitly rejected, and can alter subsequent actions. In this incident the user had to rewind the session to remove the unwanted skill context.

This is safety-relevant beyond memory. Users commonly name a tool or workflow specifically to forbid it because it would mutate external state, access sensitive data, or use the wrong operating path. A negative instruction must not activate the prohibited capability.

What steps can reproduce the bug?

1. Install a personal skill named memory-write (or any optional skill).

2. Start a fresh Codex CLI session with normal automatic skill discovery enabled.

3. Ask for an unrelated task, such as editing an existing documentation file.

4. Add an explicit constraint such as:

   Do not use, read, or invoke memory-write. This is not a memory task.
   

5. Observe whether Codex treats the skill name as a trigger, announces a rationale for reading it “just to make sure,” and loads its SKILL.md.

The real incident was captured in the local rollout record, including the assistant text and tool call, and can be provided privately if maintainers need trace correlation.

What is the expected behavior?

• A negated skill mention must be a hard veto for optional skill invocation.
• “Do not use/read/invoke X,” “never use X,” and “without X” must not satisfy a plain-text skill-name trigger.
• Codex should perform the unrelated task without reading the prohibited SKILL.md.
• Only an affirmative request or explicit invocation syntax should override normal applicability checks.
• If a higher-priority product rule genuinely requires a prohibited skill, Codex should surface the conflict before loading it instead of rationalizing the violation.
• Regression tests should cover skill names under negation, quoted examples, bug reports, comparisons, and discussion about the skill itself.

Additional information

Related: #34712 reports broad implicit over-triggering when a request does not satisfy a skill description's positive/negative applicability conditions.

This report is narrower and more deterministic: the user's explicit prohibition itself appears to become the trigger. It does not depend on interpreting a complicated skill description or resolving an ambiguous task.

The public report intentionally omits the rollout ID, private filesystem paths, and private project details.