Skip to content

Codex App briefly shows bundled system skills, then hides them after initialization #20629

Open
Open
Codex App briefly shows bundled system skills, then hides them after initialization#20629
Labels
appIssues related to the Codex desktop appbugSomething isn't workingskillsIssues related to skills

Description

@baykalc
baykalc
opened on May 1, 2026

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 / build 2312
  • 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

  1. Open Codex Desktop.
  2. During initialization, the app/skill mention surface briefly exposes bundled system skills, including:
    • imagegen
    • skill-creator
    • skill-installer
  3. A moment later, after initialization settles, those skills disappear.
  4. This is confusing because official Codex docs and use cases direct users to invoke these skills, e.g. $skill-creator, $skill-installer, and $imagegen for 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/.system flipped 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.md paths, 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-installer are documented system skills, they should either remain selectable/mentionable or be consistently hidden with explicit invocation still working.
  • A background or ephemeral codex exec process 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:

  1. Treat skills.bundled.enabled=false as process-local visibility/config only.
  2. Do not call uninstall_system_skills() on the shared CODEX_HOME/skills/.system cache from bundled-disabled processes.
  3. Keep the existing SkillScope::System root filtering for disabled-bundled sessions.
  4. 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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    skillsIssues related to skills
    on May 1, 2026

  2. github-actions commented on May 1, 2026

    @github-actions
    github-actionsbot
    on May 1, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. omarpinarecords commented on May 4, 2026

    @omarpinarecords
    omarpinarecords
    on May 4, 2026

    Additional OpenAI Docs-specific confirmation from Codex Desktop for macOS.

    Sanitized symptom:

    • The affected route is the first-party/bundled OpenAI Docs route, not a custom workspace integration.
    • openai-docs is one of the bundled system skills affected by the same .system instability described here and in Codex Desktop background exec intermittently deletes ~/.codex/skills/.system #19265.
    • From the user-facing app perspective, this is especially confusing because OpenAI Docs can appear across several different concepts: System skill, Personal skill, Skills, Plugins, MCP server, $ skill invocation, @ mention/picker search, and slash commands.
    • After a recent app restart, the current UI showed an OpenAI Developer Docs MCP entry and an OpenAI Docs skill entry, but this still does not clearly prove to a normal user which route is the intended first-party/System route or whether a duplicate/personal fallback is active.

    Expected product behavior:

    • Codex should keep the bundled openai-docs System skill stable when the app initializes and when background/ephemeral runs execute with bundled skills disabled.
    • The app should expose a clear health/status path for the official OpenAI Docs route: System skill present, MCP route enabled/usable if applicable, and no duplicate Personal override unless intentionally configured.
    • The UI/docs should clarify the difference between $openai-docs, @ picker/mentions, slash commands, Skills, Plugins, MCPs, and System vs Personal rows.
    • If the app hides System skills while still allowing explicit invocation, it should say that explicitly instead of looking like the official OpenAI Docs route disappeared.

    Impact:

    This causes repeated local troubleshooting because a user cannot tell whether official OpenAI Docs access is working, missing, duplicated, or only available through a workaround. No private logs, screenshots, workspace names, or local file paths are included here.

  4. johnsilvavlogs commented on May 5, 2026

    @johnsilvavlogs
    johnsilvavlogs
    on May 5, 2026

    Fresh confirmation from Codex Desktop on macOS that this is still happening, specifically for $imagegen.

    Environment:

    • Codex Desktop: 26.429.61741 / build 2429
    • CLI: codex-cli 0.128.0
    • macOS: 26.3 (25D125), arm64

    User-visible symptom:

    • The user had been using $imagegen in the Codex app a couple of minutes earlier.
    • Then the app/mention surface made it look like the native/system imagegen skill had vanished.
    • The user specifically described it as a native/system Codex app skill, not a custom installed skill.

    Local checks from the same session showed this was not an on-disk deletion in this case:

    $CODEX_HOME/skills/.system/imagegen/SKILL.md exists
$CODEX_HOME/skills/.system/imagegen/scripts/image_gen.py exists
$CODEX_HOME/skills/.system/imagegen/scripts/remove_chroma_key.py exists

    The installed system skills visible on disk were:

    imagegen
openai-docs
plugin-creator
skill-creator
skill-installer

    imagegen/SKILL.md was readable and contained the expected bundled Image Generation Skill frontmatter/rules. Its local modified time was 2026-05-05 20:28:01 -03, and the current Codex session still exposed the native built-in image_gen tool.

    So this looks like the same app-visible catalog/autocomplete/index instability described in this issue, but with the important variant that .system was present and healthy on disk when inspected. From the user perspective, $imagegen still appeared to disappear from the Codex app shortly after being usable.

    Expected behavior for this variant:

    • If $CODEX_HOME/skills/.system/imagegen/SKILL.md exists and the native image_gen tool is available in the session, the app skill picker/mention surface should keep $imagegen stable or clearly explain that system skills are hidden but directly invocable.
    • The app should not present this as a vanished/missing skill when the system skill bundle is installed and readable.

  5. TyceHerrman commented on Jul 28, 2026

    @TyceHerrman
    TyceHerrman
    on Jul 28, 2026

    #19265 tracks deletion of the shared .system directory. This issue should remain focused on bundled skills disappearing from the UI while their files are still present. Full evaluation of this issue is blocked until #19265 is fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingskillsIssues related to skills

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions