Searching old Codex sessions by a word you remember, next to every other agent you run

[hxreborn]

I lose Codex sessions. codex resume shows me a list, but what I actually remember is one word from the conversation, not the day and not the repo, and when work moves between Codex and another agent the history ends up split across two stores that know nothing about each other.

This reads the rollout files under ~/.codex/sessions directly and puts them in one fzf list together with Claude Code, OpenCode, Gemini CLI, Droid, Copilot CLI, Kimi Code and Qwen Code. Type a word, every session containing it comes up, the preview highlights the turn that matched, Enter runs codex resume <id> in the directory that session ran in.

https://github.com/hxreborn/herdr-transcripts

It ships as a Herdr plugin, but ./transcripts runs the same picker in a plain terminal with no Herdr involved.

Two Codex-specific notes, in case they save someone time reading these files themselves.

A rollout interleaves real turns with event_msg, reasoning, token_count and context records. Testing the first bytes of each line before calling json.loads skips most of the file undecoded, which is what keeps a large session at tens of milliseconds instead of seconds. The cwd and the originator both live in the session_meta line, and I use originator to hide runs that were not interactive CLI threads, so MCP and exec invocations do not flood the list.

The one thing Codex does not get: the preview scores a session against your working tree, splitting the files it touched into still there, deleted by a commit, and gone with nothing in git explaining it. That needs a tool call carrying a path argument. Codex edits ride inside apply_patch shell text, so Codex sessions show no line at all rather than a guessed one. If anyone knows a reliable way to recover touched paths from a rollout I would rather read it than mine the shell text.

Python standard library only, plus fzf. GPL-3.0, entirely local.

[ooocooc]

There is a structured source worth checking before parsing shell text, but I would label its result “reported successful patch paths,” not “all files touched.”

At the inspected Codex source commit, PatchApplyEndEvent carries success, status, and a changes map keyed by paths. FileChange::Update also has move_path, so preserve the source path and rename destination separately rather than treating a move as an ordinary edit.

For a legacy rollout, look for type: "event_msg" with payload.type: "patch_apply_end". Your current parse_codex filter skips records that are neither calls nor messages, excluding these records before their structured paths can be inspected.

The important caveat is persistence policy: this commit persists PatchApplyEnd for Legacy history; Paginated history instead persists completed turn items. It does not establish that every historical rollout contains that event or a populated changes map.

A conservative first implementation could collect map keys when success is explicitly true, status is "completed", and changes is present as a mapping. Missing or inconsistent evidence should remain unknown, not default to success. Keep failed/declined events separately: excluding them from the successful-patch set must not imply that they changed nothing or rolled back every partial effect. Likewise, an empty result does not cover writes through arbitrary shell commands or external tools.

Useful fixtures would be successful add/delete/update/rename, failed or declined application, missing changes, and both history modes. This is source-based guidance for the inspected revision; I have not run your picker or verified coverage against your session corpus.

[hxreborn]

Thanks, this is the most useful thing anyone has sent me about this project, and you were right on every structural point.

I measured it against my own store before touching anything: 716 patch_apply_end events across 75 of 679 rollouts, all with success: true and a changes mapping present, 1208 path entries split 933 update / 258 add / 17 delete, every path absolute. move_path is a key on all 933 updates but non-null exactly once, so renames are rare here and real.

Your read of the filter was exactly the bug. parse_codex tested for function_call, custom_tool_call and message, so event_msg records never reached json.loads. I had been telling people Codex simply has no path to read, which was only ever true of the apply_patch shell text, and I have corrected that in the README.

Shipped in 59dc68e, the conservative version you described. Keys collected only when success is True and changes is a mapping, and a non-null move_path recorded as a second path rather than replacing the source, since the preview scores paths against the working tree and a rename should show its source gone and its destination alive. The byte-marker branch sits before the call and message tests; the marker lands within 94 bytes of line start across all 716 events, so it stays inside the 300-byte head window the parser already reads. 58 of 679 sessions now carry the line, up from zero.

Your label is the better one. I have not renamed the line, but this is reported successful patch paths, and the same line already carries paths mined from other agents' tool arguments, which are a claim too. Nothing here sees a plain shell write, so it is a floor rather than an inventory. The fixtures you listed are the gap I still have, particularly declined application and the paginated history mode, since every rollout in my corpus is legacy and every event in it succeeded.