[Bug]: Explicit Codex $skill invocation does not attach user-invoked skills #6095

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Summary

T3 Code recognizes and renders $skill tokens in the composer, but an explicit token can reach a Codex turn as plain text without the selected skill's instructions being attached or injected.

This breaks skills intentionally configured as user-invoked only:

# SKILL.md
disable-model-invocation: true

# agents/openai.yaml
policy:
  allow_implicit_invocation: false

Those settings correctly keep the skill out of implicit model selection. Explicit $skill-name invocation is therefore the only intended entry point, so silently leaving it as plain text makes the skill unavailable.

This report is about send-time explicit invocation/binding after the skill is already installed and discoverable on disk, not only about whether a skill appears in the $ picker.

Steps to reproduce

1. Install mattpocock/skills, including grill-with-docs:

   npx skills add mattpocock/skills --skill grill-with-docs -g -y

2. Verify the skill exists:

   ~/.agents/skills/grill-with-docs/SKILL.md
   <repo>/.agents/skills/grill-with-docs/SKILL.md
   

   The current upstream skill is intentionally user-invoked and delegates to grilling plus domain-modeling:
   https://github.com/mattpocock/skills/blob/main/skills/engineering/grill-with-docs/SKILL.md

3. Open the repository in T3 Code and start a new Codex thread.

4. Type and send a complete explicit invocation followed by normal text:

   $grill-with-docs explain why this skill is not in the list
   

5. Inspect the resulting turn/session transcript.

How I encountered and diagnosed it

I first noticed the problem when I explicitly invoked $grill-with-docs in T3 Code and the agent reported that the skill was unavailable.

I then checked each layer:

• The skill exists both globally and under the active repository's .agents/skills.
• Both global and repository lock files identify mattpocock/skills as its source.
• The upstream skill is valid and intentionally has disable-model-invocation: true.
• Its agents/openai.yaml intentionally has allow_implicit_invocation: false.
• Model-invoked dependencies such as grilling and domain-modeling were present in the T3 Code/Codex context, proving that the skill roots were being read.
• In the T3 Code session, the transcript contained only the literal user message. No adjacent structured skill item or injected <skill>...</skill> content was present.
• As a control, the same skill and Codex app-server version used through another client produced an additional <skill> input containing the resolved SKILL.md, and the invocation worked.

That isolates the failure to explicit skill binding/injection rather than installation or malformed metadata.

Expected behavior

When a complete, installed $skill-name token is submitted:

1. T3 Code should resolve it against the active Codex provider and workspace.
2. The turn should include an explicit structured skill item, or equivalently the resolved SKILL.md instructions.
3. A user-invoked skill should work even though implicit model invocation is disabled.
4. If resolution fails, T3 Code should show a clear error instead of silently sending an inert token.

This matches the original compatibility requirement in #737: selected/local Codex skills should be sent as explicit structured skill items, not only raw text.

Actual behavior

The composer recognizes $grill-with-docs as a skill-shaped token, but the Codex turn receives only the literal text. Because the skill is intentionally absent from implicit model selection, the agent cannot load its instructions and reports it as unavailable or falls back to generic behavior.

There is no visible error indicating that explicit binding failed.

Impact

Major degradation or frequent failure

This affects an entire class of intentionally user-invoked skills, not just one package. In mattpocock/skills, workflow entry points such as grill-with-docs, grill-me, implement, to-spec, and others rely on explicit invocation by design.

The mattpocock/skills ecosystem is widely used. Users should be able to use those workflows reliably inside T3 Code rather than manually recreating their orchestration.

Version or commit

T3 Code Nightly 0.0.34-nightly.20260811.1064

Environment

macOS 26.5.2 (Apple Silicon), T3 Code desktop nightly, Codex CLI/app-server 0.147.0, Node.js 24.18.0

Logs or stack traces

# Relevant T3 Code session sequence (paths redacted)
user: "$grill-with-docs explain why this skill is not in the list"
# No following structured skill input and no injected <skill> block.

# Control client using the same installed skill:
user: "$grill-with-docs ..."
user: "<skill>
<name>grill-with-docs</name>
<path>~/.agents/skills/grill-with-docs/SKILL.md</path>
...
Run a /grilling session, using the /domain-modeling skill.
</skill>"

Local verification:

codex --version
# codex-cli 0.147.0

test -f ~/.agents/skills/grill-with-docs/SKILL.md
# success

test -f <repo>/.agents/skills/grill-with-docs/SKILL.md
# success

Related issues

• Support local Codex custom prompts and $skills in the composer #737 requested exact Codex skill binding/structured dispatch and was closed after the skills UI was added. This reproduction suggests the send-time binding portion is incomplete or has regressed for user-invoked skills.
• [Bug]: Repo-local Codex skills do not appear in T3 Code $ skill picker #3040 and PR fix(codex): discover project skills from workspace #5335 cover repository-scoped Codex skill discovery in the picker.
• [Bug]: Skill discovery never scans repo-local .agents/skills (Agent Skills standard dir) #5487 and PR fix(claude): discover repo-local .agents/skills in skill discovery #5488 cover Claude discovery of repository-local .agents/skills.
• [Bug]: Plugin-provided Claude skills (e.g. mattpocock-skills) never appear in the $ picker #5622 covers Claude plugin-provided skills missing from the picker.

Those issues concern discovery/picker inventory. This report begins after the skill is installed and focuses on the explicit token not attaching the skill instructions to the Codex turn.

Workaround

Manually ask the agent to read the exact SKILL.md path, paste the skill content into the prompt, or invoke the model-visible dependencies directly (for this example, grilling plus domain-modeling). These workarounds lose the reliability and ergonomics of the intended user-invoked wrapper.

Maintainer note

mattpocock/skills is used by many developers, and its explicit workflow entry points are a natural fit for T3 Code. I hope this compatibility gap gets attention so those workflows can be used without special handling inside T3 Code.

@juliusmarminge @t3dotgg — tagging for visibility because this affects compatibility with a widely used skill ecosystem. Thank you for taking a look when you have capacity.