Bundled skill-creator documents direct script execution, but its scripts are not executable

Open 💬 0 comments Opened Aug 2, 2026 by Muatasim-Aswad

Summary

The bundled skill-creator instructs agents to invoke its Python helpers directly:

scripts/init_skill.py <skill-name> --path <output-directory>
scripts/quick_validate.py <path/to/skill-folder>

However, the scripts are committed upstream with mode 100644 and installed locally with mode 0644. Direct execution therefore fails with exit code 126 before Python starts.

Upstream source:

https://github.com/openai/codex/tree/main/codex-rs/skills/src/assets/samples/skill-creator

Environment

  • Codex CLI: 0.145.0
  • OS: Arch Linux, kernel 7.1.3-arch1-2, x86_64
  • Shell: Bash
  • Terminal: xterm-256color

Reproduction

cd ~/.codex/skills/.system/skill-creator

stat -c '%a %n' scripts/init_skill.py scripts/quick_validate.py

scripts/init_skill.py --help
echo $?

scripts/quick_validate.py /tmp/nonexistent-skill
echo $?

Observed output:

644 scripts/init_skill.py
644 scripts/quick_validate.py

bash: scripts/init_skill.py: Permission denied
126

bash: scripts/quick_validate.py: Permission denied
126

The corresponding files on the openai/codex main branch also have Git mode 100644, so this does not appear to be local permission drift.

Expected behavior

The commands documented by the bundled SKILL.md should work as written.

Either:

  1. the scripts should be committed and distributed as executable files; or
  2. SKILL.md should explicitly invoke them through the supported Python runtime, for example python3 scripts/init_skill.py ....

A packaging or clean-install test should execute the exact commands documented in SKILL.md.

Actual behavior

Agents must discover an undocumented workaround such as:

python3 scripts/init_skill.py ...

This affects a mandatory step in the skill-creation workflow and can lead agents to skip the provided initializer or validator.

Related issue

After invoking quick_validate.py through Python, a separate undeclared-PyYAML problem may occur. That dependency issue is already tracked in:

This report is specifically about the mismatch between the documented direct invocation and the distributed file modes.

View original on GitHub ↗