›_ Codex Issues
Codex Issues / #34501

Codex App ignores supplied Gmail skill root and invents stale openai-bundled path

Open 💬 1 comment Opened Jul 21, 2026 by fantamp

What version of the Codex App are you using (From “About Codex” dialog)?

26.715.61943 (build 5628)

The session metadata reports the embedded Codex version as 0.145.0-alpha.27.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

In a brand-new Codex App task, the agent was given the correct installed Gmail skill path in its developer-provided skill catalog:

r11 = $HOME/.codex/plugins/cache/openai-curated-remote/gmail/0.1.5/skills
gmail:gmail -> r11/gmail/SKILL.md

The agent was also explicitly required to read the complete SKILL.md before taking task actions.

Instead, it invented/used a different marketplace root and tried to read:

$HOME/.codex/plugins/cache/openai-bundled/gmail/0.1.5/skills/gmail/SKILL.md

That path did not exist, so the shell returned:

sed: .../openai-bundled/gmail/0.1.5/skills/gmail/SKILL.md: No such file or directory

The agent then made an unsupported claim to the user:

The path to the installed version of the Gmail plugin has changed, so I am first locating the current policy file.

No installation or path change had occurred. The correct path had been supplied at session start and the file existed throughout the task.

The agent searched the same incorrect openai-bundled/gmail parent once more, received another No such file or directory, then proceeded to use Gmail tools without ever reading the required Gmail skill.

This appears to combine three failures:

  1. Ignoring the exact skill root supplied in the current developer context.
  2. Substituting a stale or hallucinated marketplace root.
  3. Presenting the resulting ENOENT as evidence of an installation change, then bypassing the mandatory skill read.

No email contents or personal data are included in this report.

What steps can reproduce the bug?

  1. Use the Codex App with the Gmail plugin supplied through the openai-curated-remote catalog.
  2. Start a new task that triggers gmail:gmail.
  3. Confirm that the developer skill catalog contains:

``text
r11 = $HOME/.codex/plugins/cache/openai-curated-remote/gmail/0.1.5/skills
gmail:gmail -> r11/gmail/SKILL.md
``

  1. Ask the agent to perform a task requiring Gmail.
  2. Observe whether it reads the supplied r11/gmail/SKILL.md path or substitutes:

``text
$HOME/.codex/plugins/cache/openai-bundled/gmail/0.1.5/skills/gmail/SKILL.md
``

  1. After the incorrect path returns ENOENT, observe whether the agent falsely explains this as a plugin update/path change and continues without loading the skill.

Session ID:

019f83f7-235b-7411-b247-157de5e997fd

Turn ID:

019f83f7-5abd-7a61-8e50-f56bfa4c802f

Model: gpt-5.6-sol, reasoning effort medium.

At the nearby token-count event, the model context window was 258,400 tokens and the last turn used approximately 72,544 tokens, so this did not occur near context exhaustion.

What is the expected behavior?

The agent should resolve r11 exactly as supplied and read:

$HOME/.codex/plugins/cache/openai-curated-remote/gmail/0.1.5/skills/gmail/SKILL.md

If a skill read unexpectedly returns ENOENT, it should re-check the current developer-provided skill catalog before inferring that an installation changed. It should not proceed with skill-owned actions until the required skill instructions have been loaded, unless it clearly reports that the skill is unavailable and uses an allowed fallback.

Additional information

The correct file was verified to exist after the task:

$HOME/.codex/plugins/cache/openai-curated-remote/gmail/0.1.5/skills/gmail/SKILL.md

This was a newly created task, not a resumed task that retained an old plugin path. Searches for existing issues using openai-bundled, openai-curated-remote, Gmail, wrong SKILL.md paths, and ignored skill roots did not find a matching report.

View original on GitHub ↗

1 Comment

iskandersierra · 11 days ago

I can reproduce the same failure with a non-plugin skill on Windows, so this appears to affect the general skill catalog path handling, not only Gmail/plugin skills.

The session-provided catalog included:

r1 = C:/Users/<USER>/.agents/skills
using-superpowers -> r1/using-superpowers/SKILL.md

The agent interpreted r1 as a literal directory component and attempted to read:

C:\Users\<USER>\.codex\skills\r1\using-superpowers\SKILL.md

PowerShell returned:

Cannot find path

The correct path was:

C:\Users\<USER>\.agents\skills\using-superpowers\SKILL.md

The same session also exposed the equivalent ambiguity for system skills:

r2 = C:/Users/<USER>/.codex/skills/.system
openai-docs -> r2/openai-docs/SKILL.md

The agent initially tried:

C:\Users\<USER>\.codex\skills\openai-docs\SKILL.md

instead of:

C:\Users\<USER>\.codex\skills\.system\openai-docs\SKILL.md

This suggests that model-visible aliases such as r1 and r2 are being treated as path segments rather than as references that must be resolved through the supplied root map.

The catalog-provided skill file should be authoritative. Possible fixes:

  • provide the canonical absolute path directly;
  • expose a stable skill identifier and let the host resolve it internally;
  • if aliases remain, provide a structured mapping that is not ambiguous to the model;
  • validate that every injected file: path exists before adding it to the session catalog;
  • do not proceed with a required skill-owned workflow after the skill read fails.

This is the same class of failure described in this issue, but reproduced with user and system skills rather than a marketplace plugin.