Codex Desktop reader should expose persistent per-message timestamps for reliable history automation

Summary

The Codex Desktop app-facing thread reader exposes thread/turn timing but drops the original persistent timestamp of individual user/assistant messages. This makes correctness-sensitive history automation impossible for long-running threads that span multiple calendar days.

This is separate from the existing thread-list completeness/pagination gap tracked in #39849. A reliable archival workflow needs both complete thread enumeration and per-message timestamps.

What I observed

I audited the current Codex Desktop reader path on macOS using only read-only inspection and staging tests.

• Official ChatGPT export data contains a message timestamp for 35,614 of 35,617 messages in the inspected archive.
• For 17 matching message IDs checked across the official export and the Codex app-facing reader, the export had timestamps for 17/17 while the reader exposed message-level timestamps for 0/17.
• Raw ChatGPT messages contain create_time.
• The conversion path retains that value as createTime internally, but the public message item emitted to the app-facing reader drops it and only exposes turn-level timing such as startedAt / completedAt.
• read_thread itself can paginate thread history, but without the original timestamp on each message a thread containing messages from several days cannot be split accurately by calendar day.

No private conversation text, thread IDs, account identifiers, or local paths are included here.

Why turn-level timestamps are insufficient

A long-lived thread can contain multiple user/assistant messages that belong to different calendar days. Aggregating time at the turn level loses the provenance needed to determine the actual day of each message.

A safety-conscious automation must therefore fail closed rather than guess. In our staging implementation, any missing message timestamp causes the entire calendar-day snapshot to remain pending and prevents partial Markdown output.

Requested capability

Please expose the original persistent timestamp for every user/assistant message returned by the app-facing thread reader.

The minimum useful contract would preserve:

• stable thread ID
• stable message/item ID
• original persistent message timestamp, ideally as an unambiguous timezone-aware value or UTC instant
• existing turn-level timing as a separate concept

For ChatGPT-backed messages, preserving the source create_time through the final public message-item schema would satisfy this use case.

For Codex-native messages, the equivalent persisted rollout/item timestamp should be exposed rather than synthesizing a new read-time value.

Acceptance criteria

1. read_thread returns a persistent timestamp for every user and assistant message item.
2. The timestamp survives resume, pagination, compaction, and long-running threads.
3. The timestamp represents the original persisted message time, not the time the reader fetched or reconstructed the item.
4. Stable message IDs remain available so consumers can deduplicate across repeated reads.
5. A thread spanning multiple days can be deterministically partitioned by message timestamp.

Related

• #39849 — list_threads needs cursor pagination / explicit completeness for safe automations.
• #36713 — request for temporal awareness across resumed turns; related motivation, but this request is specifically for exposing persistent per-message timestamps at the reader/protocol boundary.

Impact

This would enable reliable local backups, audit trails, journaling, daily archives, and other correctness-sensitive automations without unsupported app-bundle patching, local DB scraping, or timestamp inference.

The underlying timestamp already appears to exist; the request is to preserve it through the public reader schema.

Start at the app-facing read_thread reader and its public message-item schema, then trace how the internal createTime value reaches that boundary. Check how pagination, resume, compaction, and Codex-native items represent timestamps. Done means every user and assistant item exposes its original persistent timestamp and stable ID without replacing existing turn-level timing; add or run staging tests covering multi-day partitioning.