Codex still writes literal "\n" into git commit messages instead of real newlines
What version of Codex CLI is running?
codex-cli 0.122.0
What subscription do you have?
Pro, but why is this relevant?
Which model were you using?
gpt-5.4 high
What platform is your computer?
Fedora 43 with all patches applied. Linux 6.19.11-200.fc43.x86_64 x86_64 unknown
What terminal emulator and version are you using (if applicable)?
_No response_
What issue are you seeing?
Codex sometimes creates Git commit messages with literal \n sequences in the
message body instead of real line breaks.
This is especially painful when Codex uses git commit -m ... -m ... orgit commit --amend -m ... -m ... for multiline commit messages.
Example of broken stored commit message:
fixup! some subject
Line one\nLine two\n\nRef: ...
Expected:
fixup! some subject
Line one
Line two
Ref: ...
This has been happening for a long time across multiple Codex sessions.
Related older issue: https://github.com/openai/codex/issues/3094
What steps can reproduce the bug?
- Ask Codex to create or amend a Git commit with a multiline body.
- Let Codex use a shell command like
git commit -m ... -m .... - Inspect the stored commit message with:
git log -1 --format=raw
or
git log -1 --format=%B | cat -vet
- Observe literal
\nin the message body instead of actual newlines.
What is the expected behavior?
Codex should create proper multiline commit messages with real line breaks.
Additional information
I reproduced the underlying behavior locally:
Bad:
git commit -m "subj" -m "line1\\nline2"
This stores:
line1\nline2
Good:
git commit -m "subj" -m "line1
line2"
This stores:
line1
line2
So this looks like a command-construction/escaping bug in Codex rather than a
Git bug. A robust fix would be for Codex to use real newlines or git commit -F for multiline messages.
<file>
So far, it has been enough to prompt Codex to fix the newline mess in the created commit.
Starting a few days ago, I also need to ask Codex to validate the fix (otherwise, it claims it fixed it, but it actually just recreated the same issue).
4 Comments
This appears to be model behavior, not something that we can fix in the Codex harness. You may be able to influence it through steering. We'll share the feedback with the team responsible for training our codex models. If you see other model behavior that you'd like to report, please use the
/feedbackcommand. That will provide us with additional details including logs and conversation text.The model states:
I tend to agree with the model.
It might also be much easier and faster to fix than in the model.
FWIW, the fix can be found here: https://github.com/openai/codex/commit/a69ecf0dc1fc92354f7d857694d33a5ca1039358.
I've pushed it on this remote branch: https://github.com/cmuellner/codex/tree/fix-commit-newline-bug.
As I am not allowed to create PRs, I did not do that.
Would be great if OpenAI could pick that.
@cmuellner, no it's not the job of the harness to second guess the model and rewrite the commands it asks to executes.