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

[markmdev]

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.

[gustavosmendes]

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.

[baykalc]

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.