Start with the reviewer’s next question
A useful commit message answers two questions: what changed, and why did it need to change? Reviewers can inspect the code themselves. What they need from your message is a clear starting point, especially when the reason for a change is not obvious from the diff.
Codex can help turn code changes into that explanation. Treat it as a drafting partner, not a witness to decisions it never saw. It can describe a changed condition, but it cannot reliably know the customer complaint, design discussion, or production incident behind it unless you supply that context.
Give Codex the staged diff, not the whole workspace
Git’s staging area contains the changes selected for the next commit. Your working directory may also contain unfinished edits. Keeping those separate prevents a polished message from describing work that will not actually be committed.
- Run git status to see which files are staged, unstaged, or untracked.
- Run git diff --cached to inspect the staged patch.
- Check the patch for credentials, personal data, and unrelated edits before sharing it.
- If the patch mixes unrelated changes, split it into focused commits before asking for a message.
In a local Codex session with repository access, ask it to inspect the staged diff. If you are pasting text instead, provide that diff explicitly. Avoid a vague request such as “write a message for my changes,” which leaves the scope unclear.
Use a prompt that separates evidence from intent
A good prompt tells Codex which evidence to use, supplies the reason for the work, and limits what it may claim. Start with this:
“Inspect only the staged diff. Draft a commit subject and a short body explaining the behavior change and its purpose. Context: users could submit the checkout form twice while the first request was pending. Do not claim tests passed unless I provide results. Flag uncertainty separately from the proposed message. Do not modify files or create a commit.”
This keeps drafting separate from repository changes. It also gives Codex permission to admit uncertainty instead of filling gaps with plausible details. Replace the checkout context with the actual reason for your patch.
Turn a vague subject into a readable checkout commit
Suppose the patch disables the checkout button while a request is pending, then enables it again when the request finishes. A subject such as “Update checkout logic” names the area but hides the behavior.
A stronger draft would be:
Disable checkout submission while a request is pending
Disable the checkout button until the current request completes to reduce accidental repeat submissions. Re-enable it after success or failure so the form does not remain locked.
Notice the boundary: this message does not claim that duplicate orders are impossible. Disabling a button is not the same as server-side duplicate protection. Reviewers need the actual scope, not an inflated promise.
Check every claim before accepting the draft
Read the generated message against the patch, sentence by sentence. Ask whether each statement is visible in the code or supported by context you supplied.
- Behavior: Does the subject name the meaningful change rather than say “fix stuff”?
- Reason: Does the body explain the problem without inventing a ticket or incident?
- Scope: Does the message cover only this commit?
- Verification: Are test claims backed by actual results?
- Style: Does it follow the repository’s existing commit conventions?
If your team uses prefixes such as fix: or feat:, tell Codex that rule. Otherwise, prioritize plain language over adding a convention nobody requested.
Keep the relay setup separate from the writing task
If you use Codex through a compatible relay, SwiftRelay supports Codex with pay-as-you-go, per-token billing. Sign up for SwiftRelay if that setup fits your workflow, then configure your client before starting the drafting session. Connection settings do not belong in the commit message.
Before committing, read the final message once more without looking at the diff. A reviewer should understand the change’s purpose, its limits, and where to focus their attention.