Projects Sort By Last updated only sorts tasks within project groups, not projects

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #30778

Powered by Codex Action

Additional confirmation from a current Codex desktop installation:

• Codex app version: 26.707.31123 (5042)
• The selected value is persisted correctly as updated_at, so the menu action itself is not being dropped.
• Inspecting the shipped renderer bundle shows that the selected sort mode is passed to the task-sorting function for threads inside each project.
• Project groups are constructed separately using the persisted project-order list before that task sorting occurs.

So in Projects mode, “Last updated” changes task ordering within each project but does not change the order of the project groups themselves. When projects are collapsed—or contain only one visible task—the control appears to be a complete no-op.

This looks like an implementation/UX mismatch rather than corrupted local state. Possible fixes:

1. Apply the selected sort mode to project groups as well, using each project’s latest/created task timestamp; or
2. Relabel the control to “Sort tasks by” if it is intentionally scoped only to tasks within projects.

Thanks for digging into this. That matches the user-visible behavior I was seeing.

From a UX standpoint, I think option 1 is the expected behavior: in Projects mode, Sort By -> Last updated should sort the project groups themselves by the latest relevant timestamp among their visible/contained tasks, not only sort tasks inside each already-ordered group.

Suggested acceptance criteria:

• In Projects mode, selecting Last updated reorders project groups by each project's latest task/thread activity timestamp.
• Projects with one visible task or collapsed task lists still visibly move when their latest activity differs.
• Task ordering within each project may continue to use the selected sort mode, but group ordering should not remain pinned to persisted project-order when a global sort is selected.
• If product intent is actually task-only sorting, then the control should be relabeled to Sort tasks by to avoid implying project group sorting.

My preference is the first path because the control is exposed at the Projects-view level, so users reasonably expect it to affect project groups. Otherwise it reads as a no-op in the common collapsed/one-task case.

One important clarification: this appears to be a regression, not just a long-standing UX mismatch.

The reporter observed that Projects -> Sort By -> Last updated previously did reorder project groups by latest activity. That behavior was working before and appears to have stopped today.

So the expected behavior is not only inferred from the control label; it is also the behavior users had already been relying on.

Confirmed on the newly merged ChatGPT/Codex desktop app, and I was able to isolate the overriding state.

Environment

• macOS
• ChatGPT desktop 26.707.31428 (5059)
• Bundle identifier: com.openai.codex
• Reproduced on 2026-07-09, immediately after the ChatGPT/Codex desktop merge

Reproduction

1. Use Projects → Organize: By project.
2. Select Sort by: Last updated.
3. Update/create the newest task inside project B.
4. Project B remains below older project A.
5. Quit and reopen the app; the fixed project order remains.

The selected sort mode itself persists as updated_at, so this is not the same failure as #30778, where the selection reverts to manual order.

Root-cause evidence

Inspecting the shipped renderer shows this sequence:

1. Project groups compute a recency value from projectUpdatedAt and the maximum contained task recencyAt.
2. The groups are sorted descending by that value.
3. The result is then passed through the persisted project-order list.
4. Because project-order contains every active project ID, that stored order overrides the recency sort completely.

The selected Last updated mode is also passed to the task sorter, which explains why tasks can reorder within a project while the project headings remain fixed.

As a diagnostic proof, I replaced project-order through the app's own global-state API with one non-matching sentinel and invalidated the corresponding query cache. The project headings immediately reordered by their latest contained task activity, with the newest project moving to the top. That confirms the persisted manual project order is the overriding layer.

Clearing project-order to an empty array is not a durable workaround because the app repopulates it with all active project IDs on restart.

This is a regression from the prior Codex desktop behavior, where Last updated also reordered the project groups. A regression test should cover a populated persisted project-order, then switch to updated_at and assert that project B moves above project A when B contains the newest task.

Confirming this as a cross-platform regression in the newly merged ChatGPT/Codex desktop experience. This comment concerns the post-merge app; the older issues below are included only as regression history.

Additional environments

• Windows: installed Codex package OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
• macOS: reproduced on a separate machine with a separate account
• The two accounts also use different account/workspace configurations, which makes a machine-specific cache problem or a single-account rollout variant unlikely.

Observed behavior

The Projects menu now offers three ordering modes: Priority, Last updated, and Manual order. Switching among all three produces no visible change in the project-group order. The list remained in the same unintuitive order immediately after the product merge/update.

On macOS, I also created new chats/tasks inside a project that was lower in the list. Even with Last updated selected, activity in that project did not move it toward the top.

This matches the implementation evidence already documented in this issue: a populated persisted project-order appears to override the selected global sort mode. It also connects directly to two older reports:

• #23462, my May report about the project sidebar becoming scrambled and the ordering preference changing after authentication transitions
• #22487, “Recent projects no longer move to the top,” which was closed as completed on June 15

The recurrence after the ChatGPT/Codex merge strongly suggests a regression rather than isolated local state. It is concerning that a project-navigation problem that was previously reported—and, in the closely related case, apparently fixed—could ship again in a major product merge.

User impact

For accounts with many projects, this makes recent work difficult to find and forces repeated scrolling through an order that the controls cannot change. It is also poor onboarding: a new user is presented with three explicit sort choices, but every choice appears broken.

Please treat this as a release regression and add end-to-end coverage for the actual project headings, not only the tasks inside each heading. At minimum, a regression test should:

1. Start with several projects and a populated persisted manual project-order.
2. Select each of Priority, Last updated, and Manual order, and assert the expected project-group order.
3. Create or update a task in a lower project and assert that Last updated moves that project to the top.
4. Verify the selected behavior after restart and sign-out/sign-in.
5. Exercise the upgrade path on both Windows and macOS.

This should be caught before rollout because the failure is visible through ordinary use of the primary Projects navigation.

@etraut-openai, could you please route this post-merge regression to the current Projects/sidebar owner? You publicly triaged #22487 as an app regression in May; that report was later closed as fixed, but the same core behavior—recently active projects not moving to the top—has returned in the merged 26.707 app, now alongside three ordering controls that appear ineffective.

The cross-platform evidence and implementation analysis above make this more than a preference-persistence problem. A populated manual project-order overrides Last updated, so ordinary activity cannot move a project to the top. This is visible on both Windows and macOS immediately after the merge and needs an actual project-group sorting regression test.

What I found is that some projects actually can change to the top. Incidentally, those were the projects already being in the first one or two positions, whereas other projects much further down did not go to the top. And even though one selected sorting by latest update. The manual sorting is working and I can move entries around, which is maybe a temporary fix for now to just manually keep track of this, but this is still not really good because important things can get buried under a lot of other old projects.

@claell or quit + run a script + open
https://github.com/openai/codex/issues/32166#issuecomment-4936705327

Crazy that this regression already happen like 5 times so far in Codex app 😂

Crazier that this still hasn’t been fixed. The core problem this app is designed to solve cannot be addressed while this bug exists.

Still reproducible on ChatGPT/Codex for macOS 26.707.41301 (build 5103).

With Projects → By project → Last updated, project headings continue to follow the persisted project-order, while conversations inside each project sort correctly by recency. “In one list” produces the correct chronological order.

I submitted in-app feedback with session and browser logs attached.
Feedback ID: 019f47fd-477a-7703-93ea-34e2b7fd45a3

I have the same problem!

Same issue. please fix. slows down workflow immensely

I found a specific reproducible pattern that may help narrow down the cause.

<img width="384" height="474" alt="Image" src="https://github.com/user-attachments/assets/590ddb2d-3c6b-42e4-a8b8-bb201889c849" />

With Organize → By project and Sort by → Last updated, projects whose names end with -1 and -2 do not move to the top after activity inside them.

Steps:

1. Create or use a project ending in -1, such as example-1.
2. Select By project and Last updated.
3. Create or update a task inside that project.
4. Observe that the project remains in its previous position.

Expected: The project moves to the top because it contains the most recently updated task.

Still have the same issue in the latest version macOS 26.707.72221

Still reproducible on macOS with ChatGPT/Codex 26.707.72221 (build 5307).

I also tested the temporary script from #32166 after fully quitting the ChatGPT app and its app-server process.

Before reopening, the state file was correct:

project-order was sorted using the latest recency_at_ms from state_5.sqlite.

projectSortMode was set to updated_at.

Immediately after reopening the app, it restored the previous manual project-order and changed projectSortMode back to priority, while the UI continued to show Last updated as selected.

Therefore, the script workaround is not durable on this build. In one list is the only mode that currently provides correct chronological ordering; By project → Last updated remains broken.

Adding another confirmation: this is still reproducible on macOS with ChatGPT/Codex 26.707.72221 (build 5307).

With Projects → By project → Last updated, new activity inside a lower project does not move that project to the top. Conversations may sort within each project, but the project groups remain effectively pinned. With many projects, this makes active work difficult to find and adds significant friction to the core workflow.

Please prioritize this regression and ensure that Last updated sorts the project groups themselves by their latest contained activity, not only the conversations inside each group.

Same issue. Windows 11. This broken feature has significantly reduced my productivity.

Still reproducible for us on Codex desktop 149.0.7827.197 on macOS 26.5.1 (build 25F80), Apple Silicon (arm64).

In Projects view, selecting Sort by → Last updated does not move recently active projects to the top; the project order remains unchanged. This makes it difficult to find current work in a larger project list.

Confirming that this is still impacting daily use and would appreciate prioritization.

Still reproducible on the newer merged ChatGPT/Codex desktop app:

• App version: 26.715.21425 (build 5488)
• macOS: 26.5.1 (build 25F80)
• Platform: Darwin 25.5.0 arm64 arm

With Projects → By project → Last updated, pinned projects remain pinned (which is expected), but all unpinned top-level project groups continue to follow the saved static order instead of the latest activity of their contained tasks/threads.

I verified this by comparing the projects' latest thread activity timestamps: less-recent projects remained above more-recent projects, and restarting the app did not correct the order. A one-time offline recomputation of the saved project order immediately changed the visible sidebar order, confirming that the thread recency data exists but is not being applied dynamically to top-level project groups.

Expected behavior: keep pinned projects first, then sort all unpinned project groups in descending order by the latest activity of their contained task/thread.

Verified on Codex App 26.715.21425 on macOS 26.5.2 arm64.

I reproduced this with a project that was not first in the sidebar:

1. Send a new message in a thread under that project.
2. The thread's activity timestamp (recency_at_ms in the local thread database) updates correctly.
3. The persisted project-level project-order remains unchanged, so the project does not move to the top.
4. Updating project-order through Codex's own set-global-state request path causes the sidebar to reorder immediately.

This suggests that the task/thread recency path is working, but the app is not recomputing the project-level ordering when activity changes. The behavior also persists across an ordinary app restart.

I initially noticed it after changing the configured model provider, but the provider does not appear to be causal: the sidebar behavior is controlled by the persisted project ordering, while message routing and thread activity continue to work normally.

As an external validation, continuously recomputing each project's maximum thread recency and updating project-order restored the expected behavior; a deliberately incorrect order was corrected in about 239 ms. No DOM reordering was required.

Confirming this regression is still reproducible on a newer unified ChatGPT/Codex desktop build:

• App version: 26.715.52143 (build 5591)
• Platform: macOS, Apple Silicon
• Sidebar: Projects → By project

Reproduction

1. Select Sort by → Last updated.
2. Send a new message or create new activity inside a project that is lower in the sidebar.
3. The chat/thread activity updates, but the top-level project folder does not move upward.
4. Switching between Priority and Last updated does not change the project-folder order.
5. Switching to In one list does show the chats in the expected chronological order.

Read-only local verification

The selected sort preference is persisted correctly, so the menu selection is not being lost. However, the visible top-level project order exactly follows the persisted static project-order list. A project with newer contained activity remains below a project with older activity.

This worked in the earlier Codex desktop experience, where new activity inside a project moved that project toward the top. The regression appeared after moving to the unified ChatGPT/Codex desktop app.

Expected behavior: with Last updated, keep pinned projects first and dynamically order all unpinned top-level project groups by the latest activity of their contained chats/tasks.

i hope they can fix it as soon as possiable