Codex App briefly shows bundled system skills, then hides them after initialization
What happened?
Codex Desktop can briefly show bundled system skills such as $imagegen, $skill-creator, and $skill-installer, then hide them after the app finishes initializing. From the user perspective this looks like the skills are not installed or not registered, even though the docs describe them as built-in/system skills and starter prompts explicitly reference them.
This is likely related to #19265, but I am filing this separately because the user-visible failure is the Codex App skill/capability UI flicker and documentation mismatch, not just the filesystem cache deletion.
Environment
- Codex Desktop:
26.429.20946/ build2312 - Desktop bundled CLI:
codex-cli 0.128.0-alpha.1 - Global CLI/npm:
codex-cli 0.128.0/@openai/codex@0.128.0 - macOS:
26.4.1(25E253) - Chronicle/memories were enabled while reproducing
User-visible symptom
- Open Codex Desktop.
- During initialization, the app/skill mention surface briefly exposes bundled system skills, including:
imagegenskill-creatorskill-installer
- A moment later, after initialization settles, those skills disappear.
- This is confusing because official Codex docs and use cases direct users to invoke these skills, e.g.
$skill-creator,$skill-installer, and$imagegenfor slide/image workflows.
Local evidence
While reproducing, the desktop app had codex_chronicle/memory background work launching child codex exec processes with:
--config skills.bundled.enabled=false
During that window:
~/.codex/skills/.systemflipped between present and missing.- When present, it contained the expected bundled system skills:
imagegen
openai-docs
plugin-creator
skill-creator
skill-installer
- Prompt metadata could still mention
.system/.../SKILL.mdpaths, but the directory could be missing immediately afterward.
After setting:
[features]
chronicle = false
and letting the background children drain, no skills.bundled.enabled=false child processes were running and ~/.codex/skills/.system stayed present in the immediate recheck.
Isolated repro of the underlying cache behavior
This reproduces the destructive shared-cache side effect without user config or Chronicle:
tmp_home=$(mktemp -d /tmp/codex-skills-repro.XXXXXX)
CODEX_HOME="$tmp_home" codex debug prompt-input -- 'probe $skill-creator' >/tmp/codex-repro-on.txt
find "$tmp_home/skills/.system" -mindepth 1 -maxdepth 1 -type d -print | sed 's#.*/##' | sort
# imagegen
# openai-docs
# plugin-creator
# skill-creator
# skill-installer
CODEX_HOME="$tmp_home" codex debug prompt-input --config skills.bundled.enabled=false -- 'probe only' >/tmp/codex-repro-off.txt
[ -d "$tmp_home/skills/.system" ] || echo missing
# missing
CODEX_HOME="$tmp_home" codex debug prompt-input -- 'probe again $imagegen' >/tmp/codex-repro-on-again.txt
find "$tmp_home/skills/.system" -mindepth 1 -maxdepth 1 -type d -print | sed 's#.*/##' | sort
# imagegen
# openai-docs
# plugin-creator
# skill-creator
# skill-installer
Why this seems app-visible, not only filesystem-visible
The app has multiple skill/capability surfaces: prompt-visible skills, app skills/list, plugins/apps, and the UI selector/mention experience. When a background process removes CODEX_HOME/skills/.system, the app can appear to switch from a broader transient system-skill set to a narrower post-refresh catalog. To users, this reads as “the documented system skills showed up for a split second, then vanished.”
Expected behavior
- Codex App should have a stable post-initialization story for bundled system skills.
- If
$imagegen,$skill-creator, and$skill-installerare documented system skills, they should either remain selectable/mentionable or be consistently hidden with explicit invocation still working. - A background or ephemeral
codex execprocess with bundled skills disabled should not remove the shared system-skill cache used by the app. - The UI should not briefly expose system skills and then silently remove them without a diagnostic.
Suggested fix
The root fix is probably the same family as #19265:
- Treat
skills.bundled.enabled=falseas process-local visibility/config only. - Do not call
uninstall_system_skills()on the sharedCODEX_HOME/skills/.systemcache from bundled-disabled processes. - Keep the existing
SkillScope::Systemroot filtering for disabled-bundled sessions. - Make the app skill/capability UI wait for one authoritative initialized catalog, or explicitly separate hidden/system skills from user-installed skills in the UI.
This would preserve background/ephemeral isolation without making documented built-in skills flicker or disappear from the main Codex Desktop session.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗