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

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.

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.

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.

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.

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.

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.

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:

• #30014: non-atomic marker-mismatch refresh.
• Marker-integrity issue: a matching marker can mask missing cached files.

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

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: #30014: non-atomic marker-mismatch refresh. Marker-integrity issue: a matching marker can mask missing cached files. the skills.bundled.enabled=false deletion reported here appears done though and this can be closed afaik

Same as this? https://github.com/openai/codex/issues/37783#issuecomment-5268831523

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

chronicles removed and replaced by computer history i think