Include session start timestamp in codex exec --json stream

[hubix2000]

Feature request

When consuming codex exec --json, there is no session creation timestamp in the JSONL stream. If a client cannot process the full stream (or processes it asynchronously), it is hard to later reconcile and synchronize sessions by time across the JSONL rollout files. I need a stable session timestamp so I can query “changes since X” reliably.

Proposed behavior

Emit the session start timestamp (RFC3339, UTC) in the JSON stream as part of the initial thread.started event. Ideally this is the same “locked” timestamp written into the rollout file’s SessionMeta.timestamp and remains stable across resumes.

Example (new field):

{"type":"thread.started","thread_id":"<uuid>","timestamp":"2025-09-05T16:53:11.850Z"}

Rationale

• Enables offline/partial stream processing and later synchronization.
• Allows clients to correlate the exec stream with stored JSONL sessions using the canonical session timestamp.
• Avoids relying on event arrival time, which is not stable across resumptions.

Notes

• For resumed sessions, the timestamp should come from the existing rollout SessionMeta (not a new clock value).
• The format can match the existing rollout SessionMeta.timestamp RFC3339 format.

[hubix2000]

PR: #8622

[hubix2000]

This is a bug, not an enhancement.

The JSONL session format already defines a canonical timestamp that is used to uniquely identify and order persisted entries. However, the streamed output does not expose this same timestamp, even though it represents the same underlying events.

This creates a correctness issue: the stream is not a faithful or lossless representation of the persisted session. Clients cannot deterministically map streamed entries to their stored JSONL counterparts, which breaks idempotency, replay, and resume semantics.

Using client-side arrival time as a substitute is incorrect, because arrival time is not stable across retries or resumptions. As a result, the same logical event can be observed with different timestamps, violating the uniqueness and ordering guarantees implied by the persisted session format.

Since the system already has a canonical timestamp and uses it for persistence, omitting it from the stream is a defect in the streaming interface, not a request for additional functionality.

Expected behavior: every streamed entry must include the exact canonical timestamp that is written to the JSONL session, so that streamed and persisted representations remain equivalent.