[BUG] Codex cannot discover scripts in skill's scripts directory

Open 💬 9 comments Opened Jan 14, 2026 by PaulRBerg
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.80.0

What subscription do you have?

Pro

Which model were you using?

Codex 5.2 High/Medium

What platform is your computer?

Darwin 25.2.0 arm64 arm

What issue are you seeing?

<img width="745" height="200" alt="Image" src="https://github.com/user-attachments/assets/cd1809c0-081a-4acd-a55a-0e7a1aa91db4" />

When a skill includes a scripts directory with executable scripts (e.g., Python scripts), Codex fails to discover and use them. Instead, it:

  1. Lists the scripts directory but reports it as empty
  2. Searches for scripts by name (e.g., rg --files -g 'scan-*.py') but doesn't find them
  3. Falls back to using reference files for manual patterns, concluding "no scripts are available"

The scripts exist on disk and work correctly when invoked manually or through Claude Code.

What steps can reproduce the bug?

  1. Create a skill with a scripts directory containing executable scripts (e.g., .claude/skills/codebase-audit/scripts/scan-react.py)
  2. Reference these scripts in the skill's SKILL.md file
  3. Run Codex and invoke the skill
  4. Observe that Codex cannot find or use the scripts, despite them existing at the expected path

What is the expected behavior?

Codex should:

  • Correctly discover scripts in the skill's scripts directory
  • Be able to execute these scripts when the skill instructions reference them
  • Have the same file discovery capabilities as Claude Code for skill components

Additional information

Screenshot showing the issue:

  • Codex "Explored" → List scripts but found the folder empty
  • Codex searched with rg --files -g 'scan-*.py' but found nothing
  • Codex concluded "since no scripts are available" and fell back to reference files

This suggests either:

  1. The working directory context is incorrect when listing the scripts folder
  2. The scripts directory path is not being resolved relative to the skill's location
  3. There's a sandboxing or permission issue preventing file discovery in skill directories

View original on GitHub ↗

9 Comments

etraut-openai contributor · 6 months ago

Thanks for the bug report.

How are you referencing the script within your skill file? Does it use a relative path? I ask because we received a similar report about relative paths from an internal (OpenAI) user.

PaulRBerg · 6 months ago

Like this:

````markdown

Workflow

Step 1: Run Checks

Use the domain-specific scanners in scripts/ to identify issues.

Running Checks

# List checks in a domain
python scripts/scan-tailwind.py --list

# Run a single check (files only)
python scripts/scan-tailwind.py 01

````

And the scripts are defined in .claude/skills/codebase-audit, with .codex directory symlinked to .claude.

xl-openai contributor · 6 months ago

I can reproduce this issue. Will work on a fix.

zbynekwinkler · 5 months ago

Possibly related

  • #10264
evoNick-A · 5 months ago

Personally I’d just edit the skill creator SKILLS.md to the full path or paths it needs to check but can’t say that’s the best way.

deeepanshu · 2 months ago

Any updates on this?

whitford-olmst · 26 days ago

I noticed Codex Desktop Windows gave me this message today:

The workspace doesn’t have the scripts/generate_pipeline_report.py path the skill expects. I’m checking the installed skill/plugin directories for the generator before deciding whether to create the report directly with the available document tooling.

It's right there. I'm following the conventions established in Using scripts. _How is Codex unaware of a Skill's own Scripts?_ 🫤

PaulRBerg · 25 days ago

Yeah this has continued to happen for me, too.

I noticed that this very rarely happens with xhigh. But with less intelligent models, it happens often.

whitford-olmst · 25 days ago
I noticed that this very rarely happens with xhigh. But with less intelligent models, it happens often.

Interesting because I tend to use Medium / 5.5 / Standard.