Codex CLI emitted Git-looking commit output for nonexistent SHAs; no repository change observed

Summary

We saw behavior that looks similar to other reports of Codex producing convincing Git/tool-looking output that does not correspond to repository state.

In our case, a long Codex CLI session using GPT-5.6 Sol on Linux emitted a malformed assistant/AgentMessage containing what looked like a fresh Git commit receipt, including full 40-character SHAs and an unexpected GitHub noreply author identity.

Afterward, we checked the repository and session evidence and could not find any evidence that those Git operations actually happened.

What appeared

The message began with visibly garbled/truncated text resembling status/search output, then included Git-looking material such as:

commit 18fef8e76bef7221dff048425217c42e757572ad5
Author: Dan <113506017+Sorcerers-Cave@users.noreply.github.com>
Date:   Sun Sep 6 12:05:55 2026 -0400

    Guard Phase 1 installer prefix integration

Several additional full SHAs appeared in the same style.

The confusing part was that the output looked very much like a normal fresh git show / commit receipt and reused the same short prefixes and subjects as real nearby commits.

What we found afterward

We did read-only checks of the saved Codex JSONL and the repository:

1. The first occurrence of the unexpected identity and full SHA is inside a Codex AgentMessage / assistant message.
2. We found no preceding custom_tool_call, CommandExecution, git log, git show, or other tool result in that turn that supplied this material.
3. git reflog shows no HEAD movement, commit, amend, reset, or checkout at the timestamp of the malformed message.
4. The displayed 40-character SHAs are not present in the repository object database (git cat-file -e fails for them).
5. Real commits with matching short prefixes exist, but their full hashes are different. Example:
   • displayed: 18fef8e76bef7221dff048425217c42e757572ad5
   • actual local commit: 18fef8e75e077b9ed81ddbd58b5ba7bdd8b4d02b
6. The real commits have the expected local author identity, not the unexpected noreply identity.
7. Normal commits immediately before and after the event are intact.

So the practical observation is: the Git-looking output appeared in the conversation, but we cannot see evidence that it actually changed the repository or created those objects.

Session characteristics

• Codex CLI on Linux
• Model: GPT-5.6 Sol
• Very long, tool-heavy session
• Multiple prior context compactions
• Extensive shell/Git work elsewhere in the session
• This event occurred after user instructions and model reasoning, before any tool invocation in that turn

I can provide the exact session ID / JSONL ordinal and additional sanitized excerpts privately if useful.

Why reporting

This was convincing enough to initially look like a real commit receipt / author-identity change, so I wanted to report it in case it is useful for diagnosing message/tool-output boundary issues or similar behavior reported elsewhere.

Start with the saved Codex JSONL around the malformed AgentMessage and compare it with preceding tool-call and result records, using the reported Linux, long-session conditions as reproduction context. Run the reported read-only checks, including git reflog and git cat-file -e, against the displayed SHAs. Done means the message/tool boundary issue is reproduced and diagnosed, with evidence distinguishing conversation output from actual repository changes.