Codex desktop sidebar shows the same relative timestamp for all local threads

Summary

In Codex Desktop on macOS, the left sidebar can show the same relative timestamp for every visible local thread, even when the local state database has distinct per-thread timestamps. For example, after a sidebar refresh/reload, many pinned and project rows all displayed 6 min at the same time, including threads whose actual activity timestamps differ by hours, days, or weeks.

This makes it look as if many unrelated projects were all modified at the same time, and makes recent-work recovery unreliable.

Environment

• Product: Codex Desktop app on macOS
• Bundled CLI reported version: codex-cli 0.142.0-alpha.1
• UI language: Chinese
• Workspace contains many local threads grouped in a project sidebar

Expected behavior

Each local thread row should display that thread's own real activity/recency timestamp. Sidebar sorting and displayed relative time should preferably use recencyAt / recency_at for local conversations, or otherwise a per-thread timestamp that is not overwritten by a global refresh time.

Actual behavior

After refresh/reload/activity, all visible local thread rows in the sidebar displayed the same relative time, e.g. all rows showed 6 min, despite the underlying local state database containing different values per thread.

Local verification performed

The local state database did not appear to be corrupted:

SELECT COUNT(*) FROM threads WHERE archived=0 AND updated_at > recency_at + 120;
-- 0

SELECT COUNT(*) FROM threads WHERE archived=0 AND recency_at > updated_at + 120;
-- 0

Example active rows in the local DB had varied timestamps:

2026-06-20 13:01:46
2026-06-20 13:00:50
2026-06-20 12:16:58
2026-06-20 10:58:39
2026-06-19 09:19:48
2026-06-18 23:37:47
2026-06-17 ...
2026-06-05 ...
2026-05-31 ...

A periodic local repair LaunchAgent was also disabled and the issue still reproduced after reload, so this does not appear to be caused by a background script repeatedly touching every thread row.

Bundle/code observations from the installed app

From the installed app bundle, the behavior appears consistent with the sidebar row display using a live conversation signal / conversation.updatedAt before falling back to summary data, while another sidebar path supports recency_at sorting but may be forced to updated_at under a feature-flag path.

Relevant observed patterns:

// row display path appears to prefer live signal / updatedAt before fallback
ue = i(S, n) ?? A?.updatedAt ?? le

// conversation sorting supports recency_at
case `recency_at`: return (t.recencyAt ?? t.updatedAt) - (e.recencyAt ?? e.updatedAt)

However, the persisted thread-sort-key = recency_at setting did not stick after app reload in this installation.

Reproduction outline

1. Open Codex Desktop on macOS with many existing local conversations.
2. Have pinned threads and/or a project group visible in the left sidebar.
3. Reload/refresh the app or perform activity in one thread.
4. Observe that many unrelated visible local rows show the same relative time, such as all 6 min.
5. Check the local state DB and confirm the underlying thread timestamps are distinct.

Request

Please investigate the Codex Desktop sidebar timestamp source for local conversations. The likely bug is that a sidebar live refresh timestamp or updatedAt signal is being applied across many local rows, instead of each row's own recencyAt / DB-backed timestamp. It would also help if the persisted thread-sort-key setting either worked reliably or the feature-flag path did not force updated_at in cases where recency_at is available.