Codex transcript silently drops a tool result or message that shares a millisecond with its sibling #1288

src/providers/codex/renderer/transcript/rollout.ts:260-262 builds the entry uuid as ${timestamp}:${payload.id ?? call_id ?? payload.type}, with no line ordinal. A function_call and its function_call_output in the same millisecond share ts:call_id. Two user/assistant message items (no id) in the same millisecond share ts:message. committedRecords.ts:100-111 then drops the second as already seen, on the live, tail and older-page paths alike. The tool card stays without its result, or the second message never renders. The loss is permanent and invisible in the ledger decisions. codexHistoryMarker (:612-617) collides the same way, so page anchors are ambiguous. A missing timestamp falls back to Date.now(), so such an entry is re-admitted on every read.

Counted by the loop on the owner's ~/.codex/sessions: 270 of 2,212 rollouts, 1,232 colliding keys among visible call/output/user/assistant items. It is still current: 4 files in 2026-09. Example: rollout-2026-04-28T17-25-54-019dd4b2… lines 469/475 (df -h, both .649Z).

Fix direction: a uuid that is unique per rollout line (a byte offset or line ordinal from the reader, or type + id for call vs output), with markers keyed the same way. Severity P1 (content silently lost).

Found by the Stage 3 C8 hunt; lines are origin/main d525d45. Findings: temp/quality-loop/hunt-c8.md.

🤖 Generated with Claude Code