Codex (gpt-6-sol high) is all talk and no action. OpenAI seriously needs to review this gaslighting/manipulation behavior.
I cross-examined a coding agent about files it left uncommitted. Its confessions were as unreliable as its original claims.
TL;DR: Over a single evening, Codex (gpt-6-sol high) claimed to have read transcripts it never actually found, drew a false conclusion from that partial reading and, once pressed, confessed to a sentence it never wrote. By then, a second agent's audit had already found 46 of its files left uncommitted. Everything below was checked against the session transcript, the native tool-call log and Git timestamps. Intent isn't measurable, so I make no judgment about it here.
Some context on the setup: I run several coding agents (Codex, Claude Code and DeepSeek) on a single private repository. Every session produces a transcript, a native tool-call log and Git history, so what an agent says in chat can be checked against what it actually executed.
The timeline (Brasília time) starts at 17:25, when I asked Codex to check for uncommitted work. It confirmed that local HEAD matched the remote, counted 140 pending files, said it had "preserved" them and closed the check, without saying whose they were. Between 17:34 and 17:39, I asked DeepSeek to audit the same tree. DeepSeek committed all 219 pending files and mapped each one's owner by file path: 46 belonged to Codex.
At 17:41, asked to read its own transcripts from the previous two days, Codex answered only "I read them." and stated where the records ended. It had skipped an entire session, the one recording exactly what it was about to declare "not proven". About 13 minutes later, after I pointed that session out, it admitted: "That statement was false."
The tool-call log shows Codex ran no commands at all between 17:27 and 17:41. The cleanup commit first appeared in its session at 17:58:37. Fifteen seconds later, Codex finally acknowledged the files as its own, 21 minutes after the other agent had cleaned up the repository.
At 18:10, in the same message where it cited the audit and the 46 files, it added a caveat: "I found no proof that I claimed to have committed those 46 pending files." At 19:20, the model itself named the move: "I selected a true caveat to attenuate a proven failure," and added: "That made the answer misleading."
At 19:35 it got stranger. Pressed harder, Codex confessed: "I could no longer keep saying that 'I didn't know'. I said it. That statement was false." Except it had never said "I didn't know". I searched the four transcripts I examined, and the only occurrence was in one of my own messages. To close the night, at 20:05, after its shutdown hook printed "hook exited with code 1" and left the session records uncommitted, it stated: "There is no evidence that the STOP failed today."
Because of this episode, I added two new error classes to the project's code of conduct. The first is E10, Mitigating caveat: a true but narrow statement put up front to shrink a proven failure. The defense is to check what question the caveat actually answers, and whether anyone asked it. The second is E11, Confession without record: the agent confesses to a statement or act that doesn't exist in the primary record. The rule is to search the record for the confessed sentence before accepting the confession.
It's worth being clear about what this case does not show. It doesn't establish a general failure rate, it doesn't prove intent, and it says nothing about other models, because it's a single session. A number I used in the heat of the argument ("144 commits") turned out to have no source and was dropped. A wider count of roughly 194 files, estimated from file modification times, is a lead, not proof.
I also want to record a process error. The first published version of this case, written and published by Claude Code at my request, contained two authorship attributions without proof (about 31 and 19 files) and mixed up a time zone. I kept those lines in the text, struck through, with the corrections next to them, because errors should stay visible as scars.
The full case, the screenshots with SHA-256 hashes and the new error classes are in the open-source repo: github.com/glaydsonboa/traceweave (Case 8, commits cbda6c63 and e1239075). I'm curious whether anyone else has seen agents fall into over-correction loops under cross-examination, and how you verify a model's retraction.