Make Codex aware of elapsed time between user turns and resumed threads

What feature would you like to see?

Codex should be able to understand when meaningful time has passed between user messages, especially when a thread is resumed after several hours or days.

Today, Codex can receive the current date/time and the local thread store records timestamps, but the model-visible conversation history does not reliably communicate the elapsed time between user turns. As a result, a message sent two days later can be interpreted as an immediate continuation of the previous exchange.

Example

A user says:

Deploy this and check the logs tomorrow.

They resume the same thread two days later and say:

Check them now.

Codex should know that two days have passed without requiring the user to restate the timeline.

Proposed behaviour

At the start of each new user turn, Codex should calculate and expose a compact temporal context containing, where available:

• the current date and time;
• the timestamp of the previous real user message;
• the elapsed time since that message;
• the timestamp when the thread was last active;
• whether the thread has just been resumed after a meaningful period of inactivity.

For example:

<temporal_context>
  <current_time>2026-08-03T10:35:00+01:00</current_time>
  <previous_user_message_at>2026-08-01T18:14:00+01:00</previous_user_message_at>
  <elapsed_since_previous_user_message>1 day 16 hours</elapsed_since_previous_user_message>
  <thread_resumed_after_inactivity>true</thread_resumed_after_inactivity>
</temporal_context>

The exact representation can be determined by the maintainers.

Scope and safeguards

• Calculate elapsed time from real user turns, not tool calls, internal messages, reminders, or subagent chatter.
• Preserve original timestamps when a thread is forked or an earlier prompt is edited.
• Refresh the temporal context after resume, compaction, rollback, or fork.
• Use the user's configured or system timezone while also retaining an unambiguous absolute timestamp.
• Handle clock changes or timestamps in the future defensively rather than presenting incorrect elapsed time as fact.
• Avoid attaching a timestamp to every historical message if a compact per-turn summary is sufficient.
• Cross-thread temporal awareness should be opt-in or limited to explicitly related threads, such as forks or threads selected by the user. The MVP can remain entirely within one thread.

Why this is useful

Time materially changes the meaning of many development tasks, including:

• checking deployments, logs, monitoring, or scheduled jobs later;
• retrying after rate limits, propagation delays, cache expiry, or DNS changes;
• understanding whether files, dependencies, branches, or external services may have changed;
• continuing project work after days or weeks without pretending the previous state is still current;
• interpreting phrases such as “tomorrow”, “later”, “after an hour”, or “check again next week”.

This would make long-running Codex threads behave more like persistent project agents rather than stateless conversations that assume every turn happened immediately after the previous one.

Implementation notes

The public codebase already appears to contain relevant building blocks:

• thread metadata includes creation and update timestamps;
• turns include start/completion timestamps and duration;
• rollout records have timestamps;
• turn context already carries the current date and timezone;
• the under-development current_time_reminder feature can inject updated time information into model-visible context.

A possible implementation would extend the current temporal context path to include the previous user-turn timestamp and a calculated elapsed duration. Model-context reconstruction should preserve or separately extract the relevant rollout timestamp instead of discarding it when converting a timestamped rollout line into only its item.

Because this changes model-visible prompt content, it should be implemented with prompt-caching and token overhead in mind. A compact append-only temporal block at the new-turn boundary may be preferable to rewriting all historical messages.

Suggested acceptance criteria

• Resuming the same thread after a simulated multi-hour or multi-day gap makes the elapsed time available to the model.
• Immediate consecutive messages are not incorrectly presented as a long resume gap.
• Tool-only activity does not replace the previous-user-message timestamp.
• Compaction does not remove temporal awareness.
• Forked threads retain the original chronology of inherited messages.
• Timezone and daylight-saving transitions are handled correctly.
• The feature works consistently across CLI, Desktop, VS Code, and app-server clients that provide an external clock.