Codex still writes literal "\n" into git commit messages instead of real newlines

Resolved 💬 4 comments Opened Apr 21, 2026 by cmuellner Closed Apr 21, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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: https://github.com/openai/codex/issues/3094

What steps can reproduce the bug?

  1. Ask Codex to create or amend a Git commit with a multiline body.
  2. Let Codex use a shell command like git commit -m ... -m ....
  3. Inspect the stored commit message with:

git log -1 --format=raw
or
git log -1 --format=%B | cat -vet

  1. 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:

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
<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).

View original on GitHub ↗

4 Comments

etraut-openai contributor · 4 months ago

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 /feedback command. That will provide us with additional details including logs and conversation text.

cmuellner · 4 months ago

The model states:

Yes, I’d still treat it as a Codex issue. ... product bug: Codex passes that through unsafely in a common Git workflow expected fix: Codex should harden commit-message handling so model quirks cannot corrupt commit messages

I tend to agree with the model.
It might also be much easier and faster to fix than in the model.

cmuellner · 4 months ago

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.

etraut-openai contributor · 4 months ago

@cmuellner, no it's not the job of the harness to second guess the model and rewrite the commands it asks to executes.