Codex App advertises bundled imagegen skill but does not materialize $CODEX_HOME/skills/.system

Open 💬 3 comments Opened May 4, 2026 by neilsanghrajka
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

OpenAI.Codex 26.429.30905 (2345)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS 26.4.1 (Darwin 25.4.0 arm64)

What issue are you seeing?

The Codex App session advertises a bundled system skill path for imagegen, but the expected on-disk system skills cache is not present, so skills that rely on the local $imagegen skill file fail when they try to load it.

In the session bootstrap, imagegen is listed as available at:

/Users/neilsanghrajka/.codex/skills/.system/imagegen/SKILL.md

But on disk, the whole .system directory is missing:

$ test -d /Users/neilsanghrajka/.codex/skills/.system; echo $?
1

The concrete symptom appeared while using a user-installed hatch-pet skill that delegates visual generation to $imagegen. It tried to load the advertised system skill path and failed:

sed: /Users/neilsanghrajka/.codex/skills/.system/imagegen/SKILL.md: No such file or directory

What steps can reproduce the bug?

  1. Use Codex App on macOS.
  2. Start a new Codex thread.
  3. Observe that imagegen is listed in the available skills metadata with path /Users/<user>/.codex/skills/.system/imagegen/SKILL.md.
  4. Check the filesystem:
find ~/.codex/skills -maxdepth 2 -type d | sort
find ~/.codex -maxdepth 4 -path '*/imagegen/SKILL.md' -o -path '*/imagegen/scripts/remove_chroma_key.py'
  1. Try to use a skill that loads $CODEX_HOME/skills/.system/imagegen/SKILL.md, such as a pet/spritesheet workflow that composes $imagegen.

What is the expected behavior?

If bundled system skills are advertised in the session, Codex should materialize them under:

$CODEX_HOME/skills/.system

In particular, this file should exist when $imagegen is advertised:

$CODEX_HOME/skills/.system/imagegen/SKILL.md

What happened instead?

The runtime advertised the skill path, but $CODEX_HOME/skills/.system was never created locally. The skill can be listed/invoked conceptually, but any workflow that needs the actual skill files or helper scripts fails on missing files.

Additional diagnostics

Local CLI version:

codex-cli 0.125.0

CODEX_HOME is unset in the shell, so default ~/.codex is expected.

Existing local skills directory:

/Users/neilsanghrajka/.codex/skills
/Users/neilsanghrajka/.codex/skills/chronicle
/Users/neilsanghrajka/.codex/skills/codex-primary-runtime
/Users/neilsanghrajka/.codex/skills/frontend-skill
/Users/neilsanghrajka/.codex/skills/hatch-pet
/Users/neilsanghrajka/.codex/skills/keep-codex-fast

There is no .system directory.

I also checked current openai/codex source. It appears imagegen is embedded as a bundled sample skill at:

codex-rs/skills/src/assets/samples/imagegen/SKILL.md

And the installer code appears intended to write embedded system skills to $CODEX_HOME/skills/.system via install_system_skills / system_cache_root_dir. So this looks like either the installer is not running in the Codex App path, bundled_skills_enabled is false unexpectedly, or the app is advertising bundled skill metadata from another source without ensuring the on-disk system cache exists.

Related but not exact issues

This resembles bundled/local cache discovery issues such as #18258, but this report is specifically about bundled system skills under $CODEX_HOME/skills/.system and the advertised $imagegen skill path being missing.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #20629

Powered by Codex Action

wakadorimk2 · 1 month ago

I can reproduce a broader variant of this issue in a WSL/Linux Codex session.

Environment:

  • Codex CLI: 0.145.0
  • Platform: WSL/Linux
  • The session advertised filesystem-backed skills from several sources, including bundled system skills, user skills, and installed plugin skills.

Observed behavior:

  • The advertised SKILL.md paths did not exist in the agent's execution environment.
  • A representative check returned MISSING for 10 out of 10 advertised paths.
  • This included paths such as:
  • ~/.codex/skills/.system/openai-docs/SKILL.md
  • ~/.codex/skills/.system/imagegen/SKILL.md
  • ~/.codex/skills/cloudflare/SKILL.md
  • ~/.codex/plugins/cache/openai-curated-remote/github/.../skills/github/SKILL.md
  • Attempting to load an advertised skill produced:

No such file or directory

  • Searching the accessible filesystem did not find relocated copies of those advertised skills.

This appears broader than the missing bundled imagegen cache originally reported here: the skill catalog and the filesystem available to the agent can disagree across system, user, and plugin skill sources.

Expected behavior:

Every filesystem-backed skill advertised to the agent should either have a readable SKILL.md at the supplied locator, or be represented as an environment-owned/resource-backed skill rather than a local file path.

These diagnostics were collected by Codex during the affected session.

fffokazaki · 16 days ago

I can reproduce this exact issue in the current Codex App environment.

Environment:

  • Codex App: 26.803.61601 (6396), bundle id com.openai.codex
  • macOS 26.5.2 (25F84), arm64
  • Codex CLI: 0.144.5

The session advertises:
/Users/futoshi/.codex/skills/.system/imagegen/SKILL.md

But:

  • /Users/futoshi/.codex/skills/.system does not exist
  • searching /Users/futoshi/.codex finds no imagegen/SKILL.md
  • the callable image_gen tool itself is available, so the mismatch is specifically between advertised filesystem-backed skill metadata and materialized skill files

This was reproduced while following a repository skill that composes Praxis illustration generation with the advertised system imagegen skill. I avoided creating a local fake .system cache because it is app-managed state and could conflict with a later installer refresh.