Add repository-level enforcement for conventional commit messages and branch naming to make Codex output consistent and CI-friendly by default

ChatGPT Feature requests
1

Problem

Codex does not reliably follow Conventional Commits or conventional branch naming (feat/*, fix/*, refactor/*), even with strong custom prompts and examples.
The chosen commit type is often incorrect, and branch names frequently need manual correction. That’s okay for small stuff but as a power user that gets really disturbing, at the moment I have to execute the following commands very often to get a clean branch and commit name:

git fetch
git pull
git checkout OLD_BRANCH_NAME_OF_CODEX
git commit --amend -m "NEW_COMMIT_MESSAGE"
git branch -m NEW_BRANCH_NAME
git push origin -u NEW_BRANCH_NAME
git push origin --delete OLD_BRANCH_NAME_OF_CODEX

This causes unnecessary overhead:

  • Manual commit/branch rewrites
  • Extra CI/CD runs and automated reviews
  • Wasted compute time
  • Noisy GitHub activity for non-code changes

Requested features

1. Enforced Conventional Commits (repo-level)

  • Policy mode: Off | Warn | Enforce
  • Format template: {type}({scope}): {message}
  • Configurable allowed types (feat, fix, refactor, docs, chore, ci, etc.)
  • Validation and correction before committing

2. Enforced Conventional Branch Naming

  • Extend branch templates with semantic variables:
  • {type}, {scope}, {slug}
  • Example templates:
    • {type}/{slug}
    • {type}/{scope}/{slug}
  • Branches should be created and validated upfront

3. Commit ↔ branch intent sync

  • Commit message and branch name must share the same type and scope
  • Prevent semantic mismatches

4. One-click “Normalize to policy”

  • Single Codex action to:
  • Amend commit message
  • Rename branch (local + remote)
  • Update upstream safely
  • Replaces manual history-rewrite workflows

Easy to implement alternative:

When clicking on “Create Pull Request”, a small menu which displays which commit message and branch name would be picked, allowing users to update those and pass it to the creation. That wouldn’t need a lot of developer overhead for such a integration as the alternative on top but still allow users to have more convenience when working with Codex.

Why this matters

  • Fewer redundant CI/CD runs
  • Cleaner Git history
  • Better release automation
  • Makes Codex usable in strict, production-grade repositories
1 Like