Repository navigation
Codex Desktop recents timestamp appears to use thread creation time instead of last active time #21960
Description
Summary
Codex Desktop appears to show a stale relative timestamp for an active/resumed thread. The visible recents/corner timestamp can read like the session was last run several days ago even while the thread is actively being used.
Observed behavior
- A Codex Desktop thread created several days earlier was resumed and actively used today.
- The local session storage for the thread was modified/accessed today.
- The UI still displayed a relative timestamp such as
3 days ago, which appears to match the thread creation age rather than last activity.
Expected behavior
The visible recents/corner timestamp should represent the thread's last active / last run time, not the original creation time.
If creation time is useful, it should be shown separately from activity time.
Possible fix
Use a last-activity field for the visible timestamp, for example:
displayAge = timeAgo(thread.lastActiveAt ?? thread.updatedAt ?? thread.createdAt)Suggested UI wording:
Created: <date>Last active: <relative time>
Why this matters
When a resumed thread is actively being used but still says something like 3 days ago, it makes the session look stale or inactive even though work is happening in it.
Activity
github-actions commentedon May 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
100yenadmin commentedon Jun 18, 2026
This older Desktop recents symptom looks related to a concrete
thread/readmetadata bug that was reproduced on currentmain: whenthread/read includeTurns=falsereplaces the SQLite-backed thread row with a rollout-derived preview, it can lose SQLiteupdated_atand fall back to rollout creation/summary metadata.Patch branch: https://github.com/openai/codex/compare/main...100yenadmin:codex/thread-read-updated-at?expand=1
Tracked in: #28870
The patch preserves SQLite authoritative
updated_at/recency_at/archived_atduring no-history preview merging and uses rollout file mtime as the direct-rollout fallback when no summaryupdated_atexists. I could not open an upstream PR directly because GitHub returnedGraphQL: 100yenadmin does not have the correct permissions to execute CreatePullRequest, but the compare branch is published.100yenadmin commentedon Jun 18, 2026
@tibo-openai