Include session start timestamp in codex exec --json stream

Resolved 💬 3 comments Opened Dec 30, 2025 by hubix2000 Closed Feb 23, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

3 Comments

hubix2000 · 8 months ago

PR: https://github.com/openai/codex/pull/8622

hubix2000 · 8 months ago

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.

etraut-openai contributor · 6 months ago

This feature request hasn't received any upvotes, so I'm going to close it.