Skip to content

Codex Desktop background exec intermittently deletes ~/.codex/skills/.system #19265

Open
Open
Codex Desktop background exec intermittently deletes ~/.codex/skills/.system#19265
Labels
appIssues related to the Codex desktop appbugSomething isn't workingexecIssues related to the `codex exec` subcommandskillsIssues related to skills

Description

@markmdev
markmdev
opened on Apr 24, 2026

What happened?

On Codex Desktop, the Codex-managed system skills directory under ~/.codex/skills/.system repeatedly disappears and later reappears. When it is absent, new turns do not get the bundled system skills in the available-skills list.

The missing skills are:

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

Observed timeline

Local timezone: EDT, April 23, 2026.

  • 22:53:09: ~/.codex/skills/.system was present with all five expected SKILL.md files and .codex-system-skills.marker.
  • 22:56:24: codex_chronicle launched a child codex exec process with --ephemeral, --ignore-user-config, --ignore-rules, and --config skills.bundled.enabled=false.
  • 22:56:25: ~/.codex/skills mtime/ctime changed.
  • 23:01:51: ~/.codex/skills/.system was missing. A search only found plugin-creator in a temp plugin area and openai-docs under vendor_imports; none of the expected system skills existed under ~/.codex/skills/.system.
  • 23:02:57: ~/.codex/skills changed again, and the .system directory was later present again.

This also happened earlier in the same session: a check saw the full .system directory with all system skills, and a follow-up check about 15 seconds later found the directory gone.

Why this looks like a Codex bug

The Codex binary appears to contain a built-in system-skills sync path. Running strings against the desktop app's codex binary shows strings including:

  • remove existing system skills dir
  • create system skills dir
  • write system skill file
  • .codex-system-skills.marker

That suggests Codex owns this directory and likely removes/recreates it during system-skill sync. The observed failure mode looks like a delete-before-rewrite race or a background/ephemeral process running the cleanup path while skills.bundled.enabled=false, so it removes the global system skills but does not rewrite them.

Expected behavior

  • Background or ephemeral codex exec jobs, especially ones launched with skills.bundled.enabled=false, should not mutate the global ~/.codex/skills/.system directory.
  • System skill refresh should be atomic, e.g. write to a temporary directory and rename into place, so there is never a window where the directory is missing.
  • Disabling bundled skills for one process should not delete the user's shared system skills installation.

Actual behavior

~/.codex/skills/.system flickers between present and absent. When absent, system skills are not available in new turns/sessions.

Environment

  • Codex Desktop: 26.422.21459 / build 2049
  • codex-cli: 0.124.0-alpha.2
  • macOS: 26.0.1 (25A362)
  • Chronicle/memories enabled in the desktop app

Suggested fix

The safest fix is likely:

  1. Do not run global system-skill installation/removal from ephemeral/background codex exec processes.
  2. Never remove ~/.codex/skills/.system when skills.bundled.enabled=false.
  3. Make the system-skill sync atomic: write ~/.codex/skills/.system.tmp-*, validate contents and marker, then rename into place.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    skillsIssues related to skills
    execIssues related to the `codex exec` subcommand
    on Apr 24, 2026

  2. gustavosmendes commented on Apr 28, 2026

    @gustavosmendes
    gustavosmendes
    on Apr 28, 2026

    Additional confirmation from Codex Desktop on macOS.

    Environment:

    • Codex Desktop: 26.422.62136 / build 2180
    • codex-cli: 0.125.0
    • macOS: 26.4.1 (25E253), arm64

    Observed today: the same five documented system skills were not available in the local Codex session:

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

    A local docs check showed that the official Codex docs describe $skill-creator and $plugin-creator as built-in/system skills. Local Git evidence also showed that the vendored openai/skills checkout contains all five under skills/.system in the Git tree:

    git -C ~/.codex/vendor_imports/skills ls-tree --name-only HEAD:skills/.system
# imagegen
# openai-docs
# plugin-creator
# skill-creator
# skill-installer

    But the materialized sparse checkout only included:

    skills/.curated
skills/.experimental

    So skills/.system existed in the Git object tree but was absent from the filesystem. The active local skill directory also lacked these five system skills, and the local bundled/runtime marketplace JSON files did not list them as plugins.

    Manual remediation worked: copying the five skills/.system/* directories from the vendored Git tree into a scanned local skill path made them structurally valid. Validation passed with:

    npx --yes skills-ref validate
skill-creator-modern/scripts/quick_validate.py

    One related nuance: absence from a generated visible skill inventory is not sufficient proof that a skill cannot load, because explicit linked-skill invocation can still work. In this case, however, the stronger evidence is filesystem-level: the five system skill folders were not materialized under scanned skill paths until copied manually.

    This seems consistent with this issue's root concern: Codex-managed system skills can be missing from local sessions even though the current docs and the vendored openai/skills tree expect them to exist.

  3. baykalc commented on May 1, 2026

    @baykalc
    baykalc
    on May 1, 2026 – with ChatGPT Codex Connector

    Additional confirmation from another macOS Codex Desktop install, with a smaller isolated repro.

    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)

    User-visible symptom:

    • $imagegen, $skill-creator, and $skill-installer appear briefly in the Codex app skill/capability surface, then disappear after the app finishes initializing.
    • ~/.codex/skills/.system flips between present and missing.
    • When present, it contains the expected bundled system skills: imagegen, openai-docs, plugin-creator, skill-creator, skill-installer.

    Local process correlation:

    • While reproducing, Codex Desktop had codex_chronicle/memory background work launching child codex exec processes with --config skills.bundled.enabled=false.
    • During that window, a prompt-build probe could see .system/.../SKILL.md paths in the prompt metadata, but the on-disk ~/.codex/skills/.system directory was then missing immediately afterward.
    • After disabling Chronicle locally and letting those child processes drain, no skills.bundled.enabled=false child processes were running and ~/.codex/skills/.system stayed present in the immediate recheck.

    Isolated repro, no user config needed:

    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

    Code-level read from current main appears to explain the behavior:

    • codex-rs/skills/src/lib.rs materializes embedded system skills under CODEX_HOME/skills/.system.
    • codex-rs/core-skills/src/manager.rs calls uninstall_system_skills(&manager.codex_home) when bundled_skills_enabled is false.
    • The same manager path already filters out SkillScope::System roots when bundled skills are disabled, so deleting the shared cache looks unnecessary for enforcing the config.
    • codex-rs/core-skills/src/manager_tests.rs currently asserts that disabled bundled skills remove the cached .system directory, which bakes in the cross-process side effect.

    My read: skills.bundled.enabled=false should be process-local visibility/config, not a global mutation of shared CODEX_HOME. If stale cleanup is still needed, it should not run from ephemeral/background child jobs and should not delete the cache used by the main app/session.

  4. y2ambition-ai commented on Jul 17, 2026

    @y2ambition-ai
    y2ambition-ai
    on Jul 17, 2026 – with ChatGPT Codex Connector

    Additional confirmation on the current desktop build, with the cross-thread impact made explicit.

    Environment

    • ChatGPT/Codex desktop app: 26.707.91948
    • Bundled Codex CLI: 0.144.5
    • macOS, arm64
    • Chronicle/memories enabled

    Still reproducible on 0.144.5

    Using an isolated temporary CODEX_HOME:

    probe_root=$(mktemp -d /tmp/codex-system-skills-probe.XXXXXX)

CODEX_HOME="$probe_root" codex debug prompt-input -- 'probe $skill-creator' >/dev/null
test -d "$probe_root/skills/.system" && echo present
# present

CODEX_HOME="$probe_root" codex debug prompt-input   --config skills.bundled.enabled=false   -- 'probe only' >/dev/null
test -d "$probe_root/skills/.system" || echo missing
# missing

CODEX_HOME="$probe_root" codex debug prompt-input -- 'probe again $imagegen' >/dev/null
test -d "$probe_root/skills/.system" && echo present
# present

    The affected user's global config.toml does not set skills.bundled.enabled=false. The live Chronicle background process was observed launching an ephemeral child with both:

    --ignore-user-config
--config skills.bundled.enabled=false

    Therefore setting skills.bundled.enabled=true in the user's global config cannot prevent this: the child ignores user config and the explicit CLI override wins.

    Why this is a cross-thread correctness bug

    All desktop threads share the same $CODEX_HOME/skills/.system directory. A background Chronicle/summary child created for one thread can therefore delete the system-skill installation used by every other concurrent thread.

    Consequences are broader than the skill picker briefly flickering:

    • New turns in unrelated threads can start without imagegen, openai-docs, plugin-creator, skill-creator, or skill-installer.
    • An active turn that needs to read a system skill's referenced scripts, assets, or supporting files can fail if the shared directory is removed mid-turn.
    • One background/ephemeral thread can change the capability surface of otherwise unrelated foreground threads.
    • A later normal skill load recreates the directory, making the failure intermittent and difficult to diagnose.

    The root cause appears to be that process-local visibility configuration is implemented as a global filesystem mutation: bundled_skills_enabled=false calls the system-skill uninstall path against the shared CODEX_HOME.

    Expected behavior: disabling bundled skills should only filter SkillScope::System for that process. It should never delete the shared system-skill cache, especially from an ephemeral/background child. If refresh/removal is needed, it should be owned by one authoritative process and performed atomically.

  5. JavierPiedra commented on Jul 24, 2026

    @JavierPiedra
    JavierPiedra
    on Jul 24, 2026 – with ChatGPT Codex Connector

    Confirming this is still happening in Codex Desktop on macOS (2026-07-23).

    ~/.codex/skills/.system exists but contains only .codex-system-skills.marker (4 KB), with no bundled SKILL.md files. As a result, skill-creator is absent from the available-skills list.

    I did not modify that directory.

  6. alfozan commented on Aug 9, 2026

    @alfozan
    alfozan
    on Aug 9, 2026
    Contributor

    Additional confirmation on a newer Codex Desktop build.

    Environment:

    • Codex Desktop 26.803.41515 (build 6321)
    • Bundled codex-cli 0.147.0-alpha.6.5
    • Homebrew codex-cli 0.147.0
    • macOS 26.6.1 (25G76), arm64

    Observed:

    • With Chronicle enabled, ~/.codex/skills/.system was missing while ~/.codex/skills/chronicle remained.
    • A second Mac using the same synced config.toml, Desktop version, and CLI version still had the current six-skill bundle: imagegen, openai-docs, plugin-creator, review-agent, skill-creator, and skill-installer.
    • I restored the six skill directories on the affected Mac and verified them. Within a few minutes, .system disappeared again.
    • The installed codex_chronicle binary contains an embedded internal configuration with skills.bundled.enabled=false. The persistent user config did not contain that global setting.
    • The current bundle now includes review-agent, and its files on the healthy Mac matched the current openai/codex source byte-for-byte.

    Workaround verification:

    1. Set [features] chronicle = false.
    2. Gracefully stop the existing codex_chronicle process, since changing the config did not stop the already-running process immediately.
    3. Restore .system from the healthy same-version Mac.
    4. Run a recursive checksum comparison. There were no differences, the .codex-system-skills.marker file was present, Chronicle stayed stopped, and all six skills remained present in the immediate delayed recheck.

    This confirms the destructive shared-cache behavior still reproduces on Desktop 26.803.41515 / bundled CLI 0.147.0-alpha.6.5. It also matches the exact duplicate in #21933 and the UI-level symptom in #20629.

  7. techronin commented on Aug 10, 2026

    @techronin
    techronin
    on Aug 10, 2026

    Independent confirmation from another current Codex Desktop installation, plus a tested bounded recovery.

    Environment

    • Codex Desktop 26.803.41515 / build 6321
    • App-bundled CLI: codex-cli 0.147.0-alpha.6.5
    • macOS, arm64
    • Chronicle/memories enabled

    Isolated reproduction

    Using the exact binary bundled in /Applications/ChatGPT.app and an isolated temporary CODEX_HOME:

    1. An ordinary debug prompt-input materialized the current six-package system bundle: imagegen, openai-docs, plugin-creator, review-agent, skill-creator, and skill-installer.
    2. Repeating prompt construction with --config skills.bundled.enabled=false removed the entire skills/.system directory.
    3. A subsequent ordinary prompt rematerialized the same six packages and marker.

    The affected normal CODEX_HOME had the same user-visible symptom: the whole .system cache disappeared while personal skills remained. I cannot retrospectively identify the exact historical deleting PID, but the destructive binary behavior itself is deterministic in isolation.

    Impact

    This removed both skill-creator and skill-installer during active Skills work. The session still advertised their paths, so agents could either fail when reading the files or silently substitute package-specific checks. The failure recurred after earlier local repairs because those repairs addressed package contents, not global cache deletion.

    Bounded local mitigation

    I implemented and tested a fail-closed recovery in techronin/skills PR #258:

    • only acts when the entire .system directory is absent;
    • invokes the exact Codex binary bundled in the installed app to rematerialize the embedded packages;
    • verifies the system marker plus required skill-creator and skill-installer files;
    • repairs only two separately known packaging regressions;
    • refuses partial or unfamiliar cache state;
    • validates skill-creator by initializing and validating a fresh temporary skill.

    This is only a local mitigation. The durable fix should make skills.bundled.enabled=false process-local and remove the global uninstall side effect, particularly for ephemeral/background jobs.

  8. TyceHerrman commented on Aug 16, 2026

    @TyceHerrman
    TyceHerrman
    on Aug 16, 2026

    looks like fixed with #36989. Processes with skills.bundled.enabled=false now hide system skills without deleting the shared $CODEX_HOME/skills/.system cache.

    Two independent bugs remain:

    the skills.bundled.enabled=false deletion reported here appears done though and this can be closed afaik

  9. omarpinarecords commented on Aug 17, 2026

    @omarpinarecords
    omarpinarecords
    on Aug 17, 2026

    looks like fixed with #36989. Processes with skills.bundled.enabled=false now hide system skills without deleting the shared $CODEX_HOME/skills/.system cache.

    Two independent bugs remain:

    the skills.bundled.enabled=false deletion reported here appears done though and this can be closed afaik

    Same as this? #37783 (comment)

  10. TyceHerrman commented on Aug 18, 2026

    @TyceHerrman
    TyceHerrman
    on Aug 18, 2026

    yea i think it's basically a duplicate and should be closed as such. this issue should also be closed, but because 36989 fixed it

  11. omarpinarecords commented on Aug 22, 2026

    @omarpinarecords
    omarpinarecords
    on Aug 22, 2026

    chronicles removed and replaced by computer history i think

  12. Racerx323 commented on Sep 29, 2026

    @Racerx323
    Racerx323
    on Sep 29, 2026

    Additional, related reproduction on Ubuntu/WSL with two clients sharing a Codex home. This differs from the original disabled-bundled-skills reproduction, so I cannot yet establish a common root cause.

    With CLI 0.159.0, and again after updating to 0.159.1, app-server initialization followed by forced skills/list removes all eleven files of a host-materialized plugin-creator system skill and replaces .codex-system-skills.marker. Other system-skill file hashes remain unchanged. A later host invocation materializes the omitted skill again. The precise host bundle release is not established.

    The same SKILL.md is accepted when placed in an isolated throwaway repository skill directory. This narrows the problem to bundle refresh/discovery rather than demonstrating invalid frontmatter. The temporary copy was only a diagnostic fixture; no permanent personal duplicate was installed.

    Reproduction (back up the managed system directory first):

    1. With the host-provided plugin-creator present, record every system file hash.
    2. Start codex app-server --stdio against the same Codex home.
    3. Send initialize (clientInfo and experimentalApi capability), then initialized.
    4. Send skills/list with the workspace in cwds and forceReload: true.
    5. In that same invocation, compare file hashes and the marker; inspect the returned skill names/scopes/errors.

    Sanitized observations and reproduction notes:

    Could maintainers clarify intended bundle ownership when clients share a Codex home? Client/bundle-specific caches or explicit ownership, combined with locked atomic refresh, appear worth investigating. Atomic replacement alone would remove the missing-directory window but would not prevent two distinct bundles from replacing one another. These are proposed directions, not a tested upstream fix.

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 workingexecIssues related to the `codex exec` subcommandskillsIssues related to skills

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions