openai / openai/codex

Desktop and standalone Codex overwrite each other's shared .system skills, allowing an older runtime to downgrade newer bundled skills

Open
#44,771 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

app bug skills
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

Summary

Codex Desktop and the standalone Codex CLI appear to share the same system-skills cache:

$CODEX_HOME/skills/.system

When the two runtimes bundle different versions of the system skills, launching one runtime can replace the system skills installed by the other.

This means that an older Desktop-bundled Codex runtime can downgrade system skills installed by a newer standalone CLI.

I can reproduce this deterministically with:

  • standalone Codex CLI: 0.154.0
  • Codex Desktop bundled CLI: 0.153.4
  • macOS
  • default shared CODEX_HOME=~/.codex

The most visible symptom is the bundled openai-docs skill:

standalone 0.154.0
→ GPT-6 Astra migration guidance is present

Desktop bundled 0.153.4
→ GPT-6 Astra migration guidance disappears

standalone 0.154.0 again
→ GPT-6 Astra migration guidance reappears

Why this matters

The current OpenAI model guidance officially recommends using Codex and the OpenAI Docs skill to migrate a project to GPT-6 Astra:

$openai-docs migrate this project to GPT-6 Astra

Official documentation:

https://developers.openai.com/api/docs/guides/latest-model

Codex 0.154.0 also explicitly updated the bundled OpenAI Docs skill with GPT-6 Astra migration, compatibility, and prompting guidance:

https://github.com/openai/codex/releases/tag/rust-v0.154.0

Related change:

https://github.com/openai/codex/pull/42931

However, the latest Codex Desktop available to me currently bundles codex-cli 0.153.4.

Because Desktop and standalone Codex share the same .system directory, starting Desktop can replace the newer openai-docs skill written by standalone 0.154.0 with the older copy bundled in 0.153.4.

As a result, an officially documented workflow can stop working simply because Codex Desktop was launched.

The underlying issue appears to be broader than GPT-6 Astra: any bundled system-skill change can potentially oscillate between versions when multiple Codex runtimes using the same CODEX_HOME have different embedded skill bundles.

Environment

OS: macOS

Standalone Codex:
codex-cli 0.154.0

Codex Desktop bundled CLI:
codex-cli 0.153.4

CODEX_HOME:
~/.codex

Standalone version:

codex --version

Output:

codex-cli 0.154.0

Desktop bundled version:

/Applications/ChatGPT.app/Contents/Resources/codex --version

Output:

codex-cli 0.153.4

Steps to reproduce

1. Quit Codex Desktop completely

Make sure the Desktop application is not running.

2. Move the existing system-skill cache out of the way
mv ~/.codex/skills/.system \
  ~/.codex/skills/.system.repro-backup-$(date +%s)
3. Launch standalone Codex 0.154.0
codex

Let Codex initialize, then exit it.

4. Verify that the GPT-6 Astra OpenAI Docs guidance exists
find ~/.codex/skills/.system/openai-docs \
  \( -iname '*astra*' -o -iname '*gpt-6*' \) -print

Result includes:

~/.codex/skills/.system/openai-docs/references/upgrading-to-gpt-6-astra.md

The skill also contains GPT-6 Astra references:

grep -RniE 'GPT-6 Astra|gpt-6-astra' \
  ~/.codex/skills/.system/openai-docs

At this point the 0.154.0 system skill is installed correctly.

5. Launch Codex Desktop

The Desktop-bundled Codex version is:

codex-cli 0.153.4

Let Desktop initialize normally.

6. Check the shared OpenAI Docs skill again
find ~/.codex/skills/.system/openai-docs \
  \( -iname '*astra*' -o -iname '*gpt-6*' \) -print

Result:

<no output>

And:

grep -RniE 'GPT-6 Astra|gpt-6-astra' \
  ~/.codex/skills/.system/openai-docs

no longer finds the Astra migration guidance.

7. Quit Desktop and launch standalone Codex 0.154.0 again
codex

After initialization, exit and check again:

find ~/.codex/skills/.system/openai-docs \
  \( -iname '*astra*' -o -iname '*gpt-6*' \) -print

The Astra migration file is present again:

~/.codex/skills/.system/openai-docs/references/upgrading-to-gpt-6-astra.md

Reproduction result

The behavior is repeatable:

Standalone 0.154.0
        ↓
newer system skills installed
        ↓
GPT-6 Astra guidance present

Desktop bundled 0.153.4
        ↓
shared .system cache rewritten
        ↓
GPT-6 Astra guidance removed

Standalone 0.154.0
        ↓
shared .system cache rewritten again
        ↓
GPT-6 Astra guidance restored

Actual behavior

Different Codex runtimes sharing the same CODEX_HOME can overwrite:

$CODEX_HOME/skills/.system

with their own embedded system-skill bundle.

The observable behavior is effectively:

runtime A starts
→ installs runtime A's embedded system skills

runtime B starts with a different embedded skill fingerprint
→ replaces the shared .system directory with runtime B's embedded skills

runtime A starts again
→ replaces it again with runtime A's embedded skills

This allows an older runtime to downgrade the system-skill state written by a newer runtime.

In this reproduction, the contents of .system/openai-docs change depending on which Codex runtime initialized the shared cache most recently.

Expected behavior

Starting an older Codex runtime should not silently downgrade system skills installed by a newer runtime sharing the same CODEX_HOME.

Possible approaches could include:

  1. Version the system-skill cache by runtime or embedded-skill bundle version.
  2. Keep Desktop-bundled system skills isolated from standalone CLI system skills.
  3. Make the refresh mechanism version-aware so an older bundle cannot overwrite a newer one.
  4. Treat binary-embedded system skills as runtime-local resources instead of mutable shared user state.
  5. Otherwise ensure that multiple supported Codex installations can safely share the default CODEX_HOME.

User impact

The immediate impact is that this documented workflow:

$openai-docs migrate this project to GPT-6 Astra

may work after using standalone Codex 0.154.0, then stop working after launching Codex Desktop 0.153.4.

A user can therefore:

upgrade standalone Codex
→ receive the new system skill
→ launch Desktop
→ silently lose the new system skill

without changing any configuration or manually modifying the skill directory.

This is particularly confusing because both Codex installations are functioning normally and the downgrade happens through their shared default state.

The same issue could affect future bundled skill updates whenever Desktop and standalone Codex releases temporarily contain different versions of system skills.

Notes

I originally encountered this while investigating why the official GPT-6 Astra migration command did not work in Codex Desktop.

After upgrading standalone Codex to 0.154.0, the Astra guidance appeared correctly. Launching Desktop, whose bundled CLI is 0.153.4, removed it again. Re-launching standalone 0.154.0 restored it.

This makes the cross-version shared system-skill cache behavior independently reproducible, rather than being specific to an existing Codex session or an old cached copy of the skill.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the system-skill initialization used when the standalone codex and Desktop-bundled CLI launch, focusing on writes to $CODEX_HOME/skills/.system. Reproduce the 0.154.0/0.153.4 sequence described in the issue and inspect how embedded skill bundles are refreshed. Done means an older runtime no longer overwrites newer shared system skills, or the bundles are isolated.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.