Codex CLI 0.155.0: Resuming an old session updates its timestamp and moves it to the top

What version of Codex CLI is running?

codex-cli 0.155.0

What subscription do you have?

N/A — Codex CLI is configured with a custom model provider.

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What terminal emulator and version are you using (if applicable)?

Windows Terminal with Windows PowerShell 5.1.19041.6456. No terminal multiplexer.

Codex doctor report

What issue are you seeing?

After upgrading Codex CLI from 0.154.0 to 0.155.0, merely opening an old session through codex resume changes that
session's update timestamp.

If I select an old session and exit without sending a new prompt, the session moves to the top of the resume picker
and is displayed as now or 1s ago.

Repeating this while browsing several historical sessions makes the chronological ordering unreliable because every
viewed session is treated as recently updated.

There is no visible error message.

Local inspection shows that resuming the session appends only this event:

event_msg / thread_settings_applied

There is no new user message or assistant message. However, the event updates:

- threads.updated_at
- threads.updated_at_ms
- the rollout file modification time

The existing threads.recency_at and threads.recency_at_ms values remain unchanged and still contain the actual
previous conversation activity time.

The resume picker defaults to Sort:[Updated], so the metadata-only update causes the historical session to move to the
top.

### What steps can reproduce the bug?

1. Use Codex CLI 0.155.0 with several saved sessions from different dates.
2. Run:

   ```shell
   codex resume

3. Select and open an old session.
4. Do not send a new prompt.
5. Exit the resumed session with Ctrl+C.
6. Run codex resume again.
7. Observe that the old session has moved to the top and is displayed as now or 1s ago.
8. Repeat the same process with another old session.

The issue reproduced with 3 out of 3 historical sessions on my machine.

No specific thread ID is required because the problem reproduces across multiple sessions.

### What is the expected behavior?

Opening or viewing an existing session without adding new conversation content should not change its user-visible
activity timestamp or reorder it as if a new message had been added.

A metadata-only `thread_settings_applied` event should not advance the timestamp used by the resume picker's `Updated`
ordering.

Alternatively, the resume picker could use `recency_at_ms`, which already preserves the last actual conversation
activity time.

### Additional information

- I first observed this immediately after upgrading from Codex CLI 0.154.0 to 0.155.0.
- I did not observe this behavior on 0.154.0.
- The current latest stable npm version is 0.155.0.
- Switching the picker from `Sort:[Updated]` to `Sort:[Created]` provides a temporary workaround.
- The selected sort mode is not persisted, so the picker returns to `Sort:[Updated]` the next time it is opened.
- Existing conversation content and creation timestamps are not lost. The incorrect behavior affects the update
timestamp and default ordering.
- The `codex doctor` report contains an unrelated custom-provider `/models` reachability warning/failure. Normal
inference works, and this resume-picker issue concerns local session metadata and reproduces without making a model
request.
- Installation method: global npm installation.
- Reproduction rate: 3/3 historical sessions.

Start at the codex resume flow and inspect how the thread_settings_applied event updates session metadata and how the picker uses Updated ordering. Verify the behavior with several historical sessions, then add or update coverage so viewing a session without new conversation content does not change its user-visible activity timestamp or ordering.