Codex CLI history: reviewing an incident

Which change caused this, and why did it look correct at the time?

Why this is hard

Git answers the first half of an incident question. The second half — what the author was trying to do, what constraint they gave the model, what the model quietly worked around — is in the conversation, and it is the half that stops the same failure recurring.

What Codex CLI specifically does to you here

The thread index records the git branch, commit and working directory of each session, so a session can be tied to the state of the repository at the time — the join an incident actually needs, and one no other tool here provides.

sqlite3 -readonly ~/.codex/state_5.sqlite ".schema threads"

Where Codex CLI keeps this in the first place: ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl. Nothing prunes ~/.codex/sessions, so it grows until a person deletes it — usually all of it, usually in a hurry.

What a working answer looks like

A working answer means going from a line of code to the prompt that produced it, months later, without depending on anyone's memory.

Start by measuring what you have. npx promptwake doctor reports what every AI tool on the machine is holding and how much of it sits inside a deletion window — no account, writes nothing, sends nothing anywhere. If the conclusion is that the record should not depend on one laptop, that is what PromptWake captures: prompt, response and the resulting diff, local by default and synced into a shared timeline on the paid tiers.