[app] Activity view keeps stale ordering after chats receive new activity

Additional Windows reproduction: #37266 reproduces the same stale recency ordering in the normal project-grouped sidebar, without Activity view enabled.

In that reproduction, none of the affected threads were pinned, and read-only inspection showed that the state database had distinct created_at_ms, updated_at_ms, and recency_at_ms values. A fresh thread/list result using sortKey: "recency_at" returned the non-pinned threads in the correct descending order, while the rendered project sidebar retained a different, stale order.

This suggests that the backend data/listing is current and that an incremental client-side update may be updating existing rows without reinserting or re-sorting them. The affected environment was Codex App 26.730.8199.0 on Windows x64.

Additional Windows reproduction on Codex Desktop 26.803.5235.0 (bundled component 0.147.0), Windows x64 build 26200.8875:

• In the normal project-grouped sidebar, the visible order remained different from the fresh non-pinned recency order returned by the application thread-list API.
• The affected thread was not pinned.
• Manually dragging that thread changed its visible position immediately, confirming that the rendered row is movable and that the client is maintaining an ordering state separate from the fresh thread-list result.
• Background thread activity had previously left the project group in a stale or mixed order; manual dragging was only a workaround, not an automatic reconciliation with the current recency order.

This provides a useful distinction: the data source is current and manual reordering works, but incremental sidebar updates do not reliably rebuild or reconcile the visible project-group order. If manual ordering and recency ordering are both supported, the active mode should be explicit and deterministic.

No screenshots are attached because the original captures contain private project labels and account UI. A fully redacted reproduction can be provided if needed.

Additional macOS reproduction on ChatGPT Desktop 26.803.61601 (build 6396), in the normal project-grouped sidebar (not relying on Activity view):

• projectSortMode was priority.
• Newly created/active threads were rendered below older completed/idle threads.
• The affected threads were unpinned, unarchived, unsectioned, and top-level.
• At the same time, the backend list_threads result had the new active threads in the correct recency order and reported the older threads as idle.
• The persisted unread set contained none of the affected project threads, so this does not appear to be the false-unread-after-restart behavior described in #37033.

This points to a stale Priority-mode project-sidebar re-render/reconciliation issue rather than pinning or unread state. No list-refresh or sort-toggle workaround was tested in this reproduction.

Expected: the rendered project sidebar should re-rank when newly created threads become active or their recency/state changes; active threads should not remain below older idle threads.

@nornagon-openai, you authored the server-side recencyAt work in #27910 and linked the paired Codex Apps PR, so you seem like the most relevant public contact. Apologies if this belongs with another Apps/sidebar owner—could you please route it to the right person and consider prioritizing it?

This is extremely frustrating in everyday multi-thread use and creates a poor user experience: actively running work can remain buried below completed threads, so the sidebar is not dependable for monitoring tasks a user just started.

I did read-only static analysis of the packaged renderer from macOS build 26.803.61601 and the current public app-server. The findings are more specific than a generic stale-sort hypothesis:

• The Priority comparator is explicitly waiting → unread → active → idle, then recency. So unread is not above waiting, but it is intentionally above active. If running work is expected to stay at the top, the current rank itself conflicts with that expectation.
• More importantly, an already-read idle thread can retain an invisible unread sorting rank. When an unread thread is opened, the renderer snapshots its recency just before marking it read. The normal sidebar later augments the real unread set with entries whose captured recency still matches, so the unread badge disappears while that idle row continues to sort as unread above active work. This survives until recency changes or the sidebar/sort state is rebuilt, which explains the intermittent nature.
• Activity/Priority-filter mode has a separate incremental-ordering defect: it merges the previous cached order before the freshly priority-sorted order, then deduplicates by ID while preserving the first occurrence. Existing rows therefore keep stale positions when status or recency changes; toggling the view forces a rebuild and temporarily fixes it.
• The public app-server already advances recencyAt on turn start, emits thread/status/changed, and returns correctly ordered results from thread/list(sortKey: "recency_at"). The public repository does not contain the desktop renderer that owns the comparator and cache.

A focused client-side fix would be:

1. Stop representing post-read position stabilization by coercing already-read idle rows back to unread for sorting. Keep that concern separate from real attention state, or expire the captured state once the read transition is reconciled.
2. If the product invariant is that running work remains visible above ordinary unread work, change the rank to waiting → active → unread → idle (or provide a persistently visible active section). Even if unread-over-active remains intentional, the invisible-unread behavior above is still a bug.
3. In Activity mode, make the freshly sorted collection authoritative or re-run the comparator over the full affected collection whenever effective attention state or recency changes.
4. Add regressions for: read idle vs. active ordering after opening an unread thread; idle → active movement without toggling the view; recency changes for existing Activity items; and waiting precedence.

The relevant desktop renderer is not in the public repository, so I have not opened a PR.

Follow-up after updating macOS from 26.803.61601 (build 6396) to 26.810.52044 (build 6662):

The practical symptom appears improved in the normal project sidebar. Running/resumed tasks are showing up where I expect under the current default ordering.

A read-only comparison of the packaged renderer suggests the main reason is that the default chat and project sort modes changed from priority to updated_at (“Last updated”). For the normal multi-task workflow, that is a sensible and effective mitigation because starting or resuming a task advances its recency and moves it upward.

I would not yet treat this as confirmation that the underlying Activity/Priority issue is fully fixed:

• The explicit Priority comparator remains waiting → unread → active → idle.
• The Activity watcher still appears to preserve cached item positions ahead of the freshly sorted collection.
• Its captured recency map still only seeds entries that are missing rather than replacing existing values.

So build 26.810.52044 is materially better in the default Last updated workflow, and I am no longer reproducing the original practical problem there. The explicit Priority/Activity path may still need separate validation or a focused fix.

Additional Android Remote / Realtime Voice reproduction on a Windows host:

1. Connected from the official ChatGPT Android app to Codex Remote on Windows.
2. Started a Realtime Voice session and requested one task inside an existing project.
3. Host logs record one thread/start from client_name="codex_chatgpt_android_remote" for the resulting task.
4. The task was created successfully but appeared at the bottom of the normal By project list. No pin/unpin action was involved.
5. The persisted sidebar mode was project with chat sort priority.
6. Read-only evidence: the task was unpinned, unarchived, and not unread; its creation/update/recency timestamps were current; a fresh app task-list response returned the correct project association and canonical recency position; but the persisted project-sidebar order placed the same task at position 68 of 68.
7. threadSource was null for this Android-created task, but the canonical list still recognized the correct project, so the available evidence does not establish the null source as causal.
8. No desktop-created or Android typed-text control was performed in this investigation.

Current host: Codex App 26.814.5517.0, bundled core/CLI 0.148.0-alpha.15; the affected rollout records 0.147.0-alpha.6.6. Windows 11 Pro 25H2, build 26200.9168, x64. Subscription: ChatGPT Pro. Android app and OS versions were not available from the Windows host.

No local state was modified. Private paths, project names, prompts/transcripts, account data, and complete thread IDs are omitted.