Advanced: Use Codex CLI to Check Markdown Frontmatter Before You Publish

A Markdown article can read well and still fail a publishing rule because one field is missing or a value is misspelled. Codex CLI can help build a small local checker, but the safe first version should report problems without changing files.

Reader and decision: You are a content engineer maintaining a local Markdown folder. The artifact is a read-only checker and a report. The decision is whether the files need repair before a human reviews them for publication.

Evidence label: Documentation-based and illustrative. OpenAI documents Codex CLI as a terminal tool that can inspect files, make changes, run commands, and support repeatable workflows. The repository, files, commands, and report below are fictional. No Codex run or personal test is claimed.

Advanced setup

You need:

• Codex CLI installed and signed in.
• A terminal and a local practice folder.
• Permission to run a script in that folder.
• A human who can define the publishing rules.

OpenAI’s Codex CLI guide documents the codex command, the /permissions control, and codex exec for repeatable workflows. Start with a disposable practice folder. Keep secrets and production content out of it.

No-code alternative: use a text editor search for title:, description:, answer:, category:, date:, and level, then review each file manually. The script is useful only when the same checks recur.

Fictional input

Create a folder named practice-posts with these files.

good.md:

---
title: "A useful report"
description: "A short description."
answer: "A direct answer with enough detail for the reader."
category: "Office workflows"
date: "2026-10-26"
level: "Beginner"
---

## Body

This is a practice article.

needs-review.md:

---
title: "Another report"
description: "A short description."
answer: "A direct answer with enough detail for the reader."
category: "Office workflows"
date: "2026/10/26"
level: "Expert"
---

## Body

This file has two deliberate rule violations.

The checker should report the date format and level value without editing either file.

Build the dry-run checker

1. Open a terminal in the parent folder of practice-posts.
2. Run codex and inspect the active permissions with /permissions. Choose the most restrictive setting that still lets Codex read the practice folder and create a new checker file.
3. Paste this request:

Create a read-only Markdown frontmatter checker for the practice-posts folder.

The checker must:
- inspect only .md files in practice-posts
- read the YAML block between the first pair of --- markers
- require exactly these six fields: title, description, answer, category, date, level
- accept date only when it matches YYYY-MM-DD
- accept level only when it is Beginner, Intermediate, or Advanced
- report filename, field, observed value, and a short reason
- exit with a nonzero status when a file fails
- never edit, rename, delete, or overwrite any Markdown input
- include a dry-run test or fixture showing one passing file and one failing file

Before writing code, explain the parsing approach and the files you will create. Do not use network calls or secrets. Keep the checker small enough to review in one diff.

4. Read the proposed plan and diff. Confirm that the checker writes only its own script and test fixture, not the input files.
5. Run the checker against practice-posts. Save the terminal output as a local review note if your process needs one.
6. Open both Markdown files and confirm their bytes and modification times did not change. The expected report should flag needs-review.md for its date and level.
7. Ask Codex to run the fixture, then use /review or a separate human review to inspect the resulting diff before you keep the checker.

Illustrative output

This is an editor-written target, not a captured Codex result:

practice-posts/good.md: PASS
practice-posts/needs-review.md: FAIL
  field: date
  observed: 2026/10/26
  reason: expected YYYY-MM-DD
  field: level
  observed: Expert
  reason: expected Beginner, Intermediate, or Advanced
summary: 1 passed, 1 failed
exit status: 1
input files changed: no

The report is useful because it names the file and field. It does not decide whether the article’s claims, sources, or writing are ready.

Acceptance checks

Before using the checker on real content, verify:

• It reads only the intended folder.
• It requires exactly the six fields named in the prompt.
• It rejects the deliberate date and level violations.
• It leaves both input files unchanged.
• It returns a nonzero status when a file fails.
• It does not make network calls or read secrets.
• The script and its tests are visible in one reviewable diff.
• A human still checks sources, links, and article meaning.

Troubleshooting

• Codex proposes to edit the articles: stop the run and restate the read-only boundary. The checker should report problems, not repair content.
• The parser accepts the slash date: add a test for 2026/10/26 and require the exact hyphenated pattern.
• The checker rewrites a file: restore the practice copy, remove write logic, and rerun the unchanged-file check.
• Codex cannot access the folder: inspect /permissions, confirm the working directory, and grant access only to the practice folder.
• The report passes everything: add a deliberately failing fixture before trusting the checker.

Limits and verdict

A frontmatter checker catches structural mistakes. It cannot verify whether a feature exists, a source supports a claim, or a tutorial is useful. Keep it as one small gate inside a human editorial process.

TRY: the checker on fictional files and a disposable folder.

SKIP: production content, secrets, or automatic repair on the first run.

USE: the read-only report when the same six-field check recurs and a human reviews the diff.

For one practical AI workflow each week, join The Weekly Verdict.

Sources

• Codex CLI
• Codex permissions and approvals
• Codex code review