Bundled skill validator fails because Codex Python lacks PyYAML
What version of the Codex App are you using (From “About Codex” dialog)?
26.519.41501
What subscription do you have?
Plus
What platform is your computer?
Windows 11
What issue are you seeing?
Codex bundled skill validator fails because bundled Python lacks PyYAML.
Environment:
- Codex desktop.
- Windows.
- Bundled Python: C:\Users\steph\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe.
- Validator: C:\Users\steph\.codex\skills\.system\skill-creator\scripts\quick_validate.py.
Observed:
Running quick_validate.py with Codex’s bundled Python fails immediately:
ModuleNotFoundError: No module named 'yaml'
Expected:
A built-in Codex skill toolkit script should run with Codex’s bundled runtime, or avoid undeclared external dependencies.
Impact:
Codex cannot validate skills using its own documented skill-creator workflow unless the user supplies an unrelated local Python environment or installs PyYAML manually.
What steps can reproduce the bug?
- Open Codex on Windows.
- Use Codex’s bundled skill creator validator:
C:\Users\steph\.codex\skills\.system\skill-creator\scripts\quick_validate.py.
- Run it with Codex’s bundled Python:
C:\Users\steph\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe C:\Users\steph\.codex\skills\.system\skill-creator\scripts\quick_validate.py C:\Users\steph\.agents\skills\archive_doc
- Observe that the script exits before validating the skill with:
ModuleNotFoundError: No module named 'yaml'
What is the expected behavior?
quick_validate.py should validate the skill folder using Codex’s bundled runtime, or the bundled runtime should include the script’s required dependencies.
Additional information
_No response_
7 Comments
I took a quick look at current
origin/main(7d47056). This looks consistent with the report: the bundled skill/plugin helper scripts have a Python YAML dependency that does not appear to be declared in the bundled Python runtime metadata.Code pointers:
codex-rs/skills/src/assets/samples/skill-creator/scripts/quick_validate.pyimportsyamlat module load time and usesyaml.safe_load, so it fails before validation can run if PyYAML is absent.codex-rs/skills/src/assets/samples/skill-creator/SKILL.mddocumentsscripts/quick_validate.py <path/to/skill-folder>as the validation step.codex-rs/skills/src/lib.rsembeds theskill-creatorassets as system skills underCODEX_HOME/skills/.system.PyYAML/pyyamlin the bundled Python runtime metadata (sdk/python-runtime/pyproject.toml/uv.lock).There are adjacent hits too:
skill-creator/scripts/generate_openai_yaml.pyandplugin-creator/scripts/validate_plugin.pyalso import/useyaml, so the same dependency contract can affect more than justquick_validate.py.A narrow fix would be either to make PyYAML available in the Python environment expected to run these bundled skill/plugin scripts, or to remove the PyYAML dependency from those bundled scripts / fail with a clearer dependency diagnostic before validation starts.
Proposed Solution: Add PyYAML to Bundled Python Dependencies
Root Cause
Codex bundles a minimal Python runtime for skill validation, but PyYAML is not included. Skills are defined in YAML format, making PyYAML a critical dependency.
Fix
Add PyYAML to the bundled Python dependency list:
Plus graceful degradation with clear error message when PyYAML is missing.
Impact
Testing
Full solution:
solutions/codex-24195-pyyaml-missing-bundled-python-fix.mdSubmitted feedback ID 019f0345-32c8-7113-9d9a-3f19c9c6d58a
I can reproduce the underlying bundled-runtime dependency issue on Windows with a newer Codex App build.
Environment:
OpenAI.Codex 26.623.5175.0C:\Program Files\WindowsApps\OpenAI.Codex_26.623.5175.0_x64__2p2nqsd0c76g0C:\Users\Administrator\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe3.12.13C:\Users\Administrator\.codex\skills\.system\skill-creator\scripts\quick_validate.pyObserved with the bundled Codex Python:
Current workaround on this machine:
C:\Python314\python.exehasPyYAMLinstalled, so runningquick_validate.pythrough systempythonsucceeds.Why this still matters:
PyYAML, but Codex's bundled runtime does not include it. A built-in Codex skill workflow is more robust if either the bundled runtime includes the dependency, the validator avoids the dependency, or the docs/wrapper clearly call out the required external Python package.Plus one from here. Every time I create a skill, Codex tries to improvise to resolve this dependency. Trying different Python interpreter (system one), downloading PyYAML to a temp directory and adding ENV vars so that script would pick it up, using bundled Ruby yaml.
ARM MacOS, latest version, but do not think that platform really matters here.
Confirming this still reproduces on macOS with the current Codex Desktop bundled skill workflow as of 2026-08-09.
I ran:
The default Python failed before validation with:
I then retried with Codex’s bundled Python at:
It produced the same missing
yamlerror. Installing PyYAML into an isolated temporary directory and exposing it only throughPYTHONPATHallowed the unchanged bundled validator to complete successfully withSkill is valid!.This confirms the skill itself was valid and the failure was the undeclared validator dependency. No global Python installation was needed for the workaround.
I investigated where the dependency belongs and found that adding PyYAML to
sdk/python-runtimewould target the wrong runtime. That package builds the platform-specificopenai-codex-cli-binwheel for the Python SDK; it is not the Desktopcodex-primary-runtimewhose bundled Python reproduced this failure.More importantly, Codex already has a production skill-frontmatter parser in Rust:
codex-rs/skills/src/parser.rsparse_skill_frontmatter_metadata(...)serde_yamldependencyquick_validate.pycurrently creates a second parsing path with PyYAML and additional authoring-policy checks. That duplication is the source of both the undeclared dependency and potential drift between what the validator accepts and what Codex actually loads.Proposed direction
``
text
``codex skills validate /path/to/skill
codex-skillsRust parser.quick_validate.py, including:skill-creatorinstructions to use that command.quick_validate.py, or retain it temporarily as a compatibility wrapper that delegates to the Codex command.This would provide one canonical YAML implementation, use the same parser during authoring and runtime loading, avoid a partial custom YAML parser, remove the PyYAML provisioning problem, and behave consistently across platforms.
The smaller fallback would be to provision PyYAML in the Desktop primary runtime and improve the import error, but that would preserve two independent validation paths and would not address behavioral drift.
Would the maintainers agree that a Rust-backed
codex skills validatecommand is the preferred direction? If so, would you be willing to invite a focused pull request for this change under the repository's invitation-only contribution policy?Related reports
This change should also resolve the same
quick_validate.py/ missing-PyYAML failure reported in #30935, #33022, and #36245. Those issues describe the same underlying split between the bundled validator and the Python environments available to run it. Consolidating validation in the existing Rust skill parser would address the shared root cause rather than applying separate environment-specific workarounds.Considered alternative and prior work
An earlier independent attempt in ChronoAIProject/FKST-codex-harness#368 implemented a focused stdlib-only parser on a fork branch, together with a
python3 -Sregression test. That work did not proceed to an upstream PR, but it is useful prior art and directly demonstrates that removing the import can make the bundled script runnable without site packages.I considered that approach but do not recommend it as the canonical fix because the replacement parser intentionally handles only top-level
key: valuelines, skips indented content, and does not validate the full YAML structures already handled by Codex’s Rustserde_yamlparser. Keeping a separate partial parser would preserve semantic drift between authoring validation and runtime loading. Reusing the existing Rust parser retains full YAML handling while addressing the same dependency failure.