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 ... or
git 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: #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
\n in 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:
Good:
git commit -m "subj" -m "line1
line2"
This stores:
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 <file> for multiline messages.
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).
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
\nsequences in themessage 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:
Expected:
This has been happening for a long time across multiple Codex sessions.
Related older issue: #3094
What steps can reproduce the bug?
git commit -m ... -m ....git log -1 --format=rawor
git log -1 --format=%B | cat -vet\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:
This stores:
Good:
This stores:
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 <file>for multiline messages.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).