Codex skill loader fails to detect valid YAML front matter in SKILL.md files saved as UTF-8 with BOM

What version of the IDE extension are you using?

26.304.20706

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When a local skill definition file named SKILL.md is saved as UTF-8 with BOM, Codex fails to load it even though the file contains valid YAML front matter delimited by ---.

The loader reports:

failed to load skill <redacted-path>\SKILL.md: missing YAML frontmatter delimited by ---

The file content is valid. The only difference is that the file begins with the UTF-8 BOM bytes EF BB BF before the opening ---.

This causes the skill to be skipped and not appear in the session’s available skills list.

What steps can reproduce the bug?

1. Create a local skill file named SKILL.md.
2. Put valid front matter at the top of the file:

---
name: example-skill
description: Example description
---

# PURPOSE

Example content.

1. Save the file as UTF-8 with BOM.
2. Start or reload the Codex session so skills are discovered.

Observed result:

• the skill is not loaded
• the loader reports:

failed to load skill <redacted-path>\SKILL.md: missing YAML frontmatter delimited by ---

1. Save the exact same file as UTF-8 without BOM.
2. Start or reload the session again.

Observed result:

• the skill loads successfully

Byte-level difference at the beginning of the file:

UTF-8 with BOM:    EF BB BF 2D 2D 2D
UTF-8 without BOM: 2D 2D 2D

What is the expected behavior?

Codex should successfully load a valid SKILL.md file even if it is encoded as UTF-8 with BOM.

At minimum, the loader should either:

• support UTF-8 BOM transparently, or
• return an explicit error that BOM-prefixed files are unsupported

It should not report that YAML front matter is missing when valid front matter is present.

Additional information

This appears to be a parser/loader issue at the start-of-file boundary. The closing --- delimiter is normal and on its own line. The failure only occurs when the opening front matter delimiter is preceded by BOM bytes.

This is easy to trigger on Windows because some editors save Markdown/text files as UTF-8 with BOM by default.

The current error message is misleading and makes the problem difficult to diagnose.